Ordine di ricerca DNS per Mac OSX Lion [chiuso]

Dopo l'aggiornamento a Mac OSX Lion, ho scoperto che / etc / hosts non viene più cercato al primo posto per la risoluzione dei nomi. Questo porta ad alcuni effetti collaterali come:

1. Le voci in / etc / hosts vengono risolte in modo estremamente lento
2. Non puoi non sovrascrivere i domini esistenti, ad esempio 127.0.0.1 www.google.com
3. Se ottieni voci di dominio di ricerca da DHCP, diciamo .lan, e qualche ragazzo divertente ha configurato localhost.lan in qualcos'altro, quindi 127.0.0.1 nel DNS locale, non puoi più raggiungere il tuo localhost.

Questo comportamento è inteso? Ha senso? E, cosa più importante, come posso tornare al vecchio comportamento.

Penso che sia importante se Lion gestisce il TLD .local in modo diverso perché è riservato ad alcune funzionalità DNS multicast (utilizzate da Bonjour). L'unico modo che ho trovato per risolvere questo problema è utilizzare un TLD diverso per gli host di sviluppo (ad esempio: .dev). Funziona bene per me, spero possa essere utile agli altri!

Per quanto riguarda l'override dei domini nel file hosts, ho scoperto che in alcune circostanze Lion interroga l'indirizzo IPv6 per un dominio se rileva che un dominio non è raggiungibile sulla rete IPv4.

L'ho scoperto quando ho notato alcuni annunci che non avevo mai visto prima su Snow Leopard perché avevo reindirizzato i domini degli annunci a 127.0.0.1. Ho attivato WireShark e ho notato AAAA(record DNS IPv6) query in seguito alle Aquery IPv4 (IPv4). Gli ad server infatti hanno indirizzi IPv6 e sono stati in grado di fornirmi il loro contenuto.

La soluzione a questo è avere un file

::1 mydomain.com

ingresso per ogni

127.0.0.1 mydomain.com

voce nel file hosts.

È interessante notare che, se ti capita di avere un server web locale in esecuzione 127.0.0.1:80e il tuo browser riceve una risposta dal server web (errore o altro), non AAAAviene eseguita alcuna query, poiché sembra essere soddisfatto che una connessione TCP fosse almeno possibile.

In una nota correlata, se si fa un uso intensivo del file hosts (per il blocco degli annunci, lo sviluppo web locale, ecc.), È possibile che si desideri eseguire il proprio risolutore DNS locale. C'è un considerevole /etc/hostsproblema del disco / CPU dovuto alla lettura a ogni richiesta, quindi è nel tuo interesse mantenere quel file molto leggero.

Un vantaggio di eseguire qualcosa di simile in dnsmasqlocale (oltre al significativo aumento delle prestazioni) è che puoi reindirizzare interi domini di primo livello alla tua macchina locale. Ciò consente di avere l'intero spazio dei nomi * .dev per lo sviluppo (ad esempio), senza dover inserire individualmente ogni dominio in cui si desidera risolvere localmente/etc/hosts

Il problema era che ho creato un link simbolico al file / etc / hosts. Se / etc / hosts è un file semplice, va tutto bene.

Aggiornamento (2): OSX 10.10.5 porta il ritorno di mDNSResponder.

Aggiornamento: OSX 10.10 Yosemite ha sostituito mDNSResponder con "discoveryd". Non ho aggiornato quindi non sono sicuro del comportamento discoveryd con ricerche DNS r / t e /etc/hosts.

Il risolutore DNS di sistema su Lion è il mDNSResponderprocesso.

Potresti pensare "ma mDNSResponder è il risponditore DNS multicast". Hai ragione; questo è ciò a cui era originariamente utilizzato e adempie ancora a questa funzione. Tuttavia, nelle versioni più recenti di MacOS esegue anche ricerche host standard.

In Lion, non sembra rileggere automaticamente /etc/hostsquando cambia, almeno non sempre. Uccidere mDNSResponder(e consentire il riavvio automatico) sembra risolvere il problema.

sudo killall mDNSResponder

dovrebbe fare il trucco.

di seguito è la mia risposta originale per i posteri. Suppongo che in alcuni casi potrebbe essere ancora un problema.

Assicurati che il tuo /etc/hosts file sia un file di testo in stile unix, con gli avanzamenti di riga come finale anziché cr.

La modifica con TextWrangler o un editor di testo unix dovrebbe preservare il file.

Se il tuo file è già incasinato, prova a risolverlo

tr '\015' '\012' < /etc/hosts > /tmp/hosts.$$
mv /etc/hosts /etc/hosts.bad
mv /tmp/hosts.$$ /etc/hosts
# fix up permissions while we are at it
chown root:wheel /etc/hosts
chmod 644 /etc/hosts

credito per questa correzione a:

http://techpatio.com/2011/guides-how-to/fixed-mac-osx-lion-etc-hosts-bugs-dns

Ho avuto questo problema per un po ', poiché lavoravo con un team di sviluppatori è diventato necessario utilizzare effettivamente .local piuttosto che .dev o .localhost, ho trovato questo articolo molto utile.

iTand.me: domini locali Lion e host ecc.

In sintesi;

Ma se devi usare .local, la soluzione più elegante che ho trovato è l'utilità dscl. Il suo utilizzo è molto semplice. Per aggiungere un host chiamato mydev.local e indirizzarlo al localhost, basta fare questo:

sudo dscl localhost -create /Local/Default/Hosts/mydev.local IPAddress 127.0.0.1

Per vedere tutti gli host attualmente definiti e i loro IP

sudo dscl localhost -list /Local/Default/Hosts IPAddress

E per rimuovere un host:

sudo dscl localhost -delete /Local/Default/Hosts/mydev.local

Nel complesso, abbastanza semplice e funziona bene. Preferirei comunque essere in grado di modificare / etc / hosts, ma questa è un'alternativa migliore al dover rinominare tutti i nostri server .local.

Prima di passare da Snow Leopard a Lion, avevo diverse voci specifiche per app /etc/hosts, come questa:

127.0.0.1 foo.bar.local

Dopo l'aggiornamento, il caricamento delle mie app locali è stato MOLTO lento. Ho notato che il ritardo si è verificato prima che la richiesta venisse visualizzata nel file di registro e che, una volta fatto, l'app stessa era veloce come al solito.

Ora ho due righe per app, in questo modo:

127.0.0.1 foo.bar.local
::1       foo.bar.local

... e tutto è di nuovo veloce.

Apparentemente questo aggiunge indirizzi IPv6? Non lo capisco proprio, davvero, ma funziona.

La mia situazione era simile, ma i ritardi, di esattamente 5 secondi, si sono verificati solo per gli URL che terminano con ".local". Durante la visualizzazione di siti che terminavano con ".dev", non ci sono stati ritardi.

Alcuni degli altri sviluppatori nel mio ufficio avevano questo problema, mentre alcuni no. Speravo in una soluzione semplice e non volevo rinominare il sito in ".local" a causa di altre dipendenze.

Ho eseguito il seguente comando in Terminal e ho diffuso il mio output con alcuni altri utenti in ufficio.

scutil --dns

Questa sezione era l'unica differenza:

resolver #2
  domain   : 00000000.members.btmm.icloud.com
  options  : pdns
  timeout  : 5
  order    : 150000

Il mio Mac era collegato al mio account iCloud e avevo abilitato Torna al mio Mac. Una volta disabilitato Back To My Mac, il resolver aggiuntivo è andato via e il ritardo di 5 secondi è scomparso.

Wow, che incubo. Ho letto assolutamente tutto su questo argomento e tutto ciò che è stato suggerito finora era praticamente vicino a quello che stavo vivendo, ma nessuna delle soluzioni ha funzionato per me.

E ho capito perché.

A differenza di altri, non stavo usando / etc / hosts per configurare domini locali. Il mio file / etc / hosts era disponibile, contenente solo le voci necessarie per l'interfaccia di loopback e l'host di trasmissione. Inoltre, era un file unix codificato correttamente, poiché sono il tipo di persona che lo modifica solo dalla riga di comando usando emacs. E, grazie a Dio, non ho dovuto ricorrere al mio server DNS come DNSmasq per aggirare il problema.

(Per essere chiari, il sintomo che mi ha portato qui a questo problema è stato che emacs ha impiegato circa 10 secondi per avviarsi, ma solo quando ero in wifi. Se avessi spento il wifi, emacs si avvierebbe immediatamente come previsto.)

La mia soluzione: il mio laptop ha un nome, "terminator". (Sì, il suo esterno in alluminio lucido mi ha fatto pensare al personaggio di Arnold Schwarzenegger.) Avevo solo bisogno di aggiungere voci a / etc / hosts per il nome della macchina stessa:

127.0.0.1   terminator
::1         terminator

Ho trovato il nome del mio host eseguendo un semplice comando nel terminale:

hostname

... che è tornato con l'output: "terminator". Dopo aver modificato / etc / hosts per contenere queste due voci, emacs può ora risolvere rapidamente il nome del mio laptop.

Spero che questo aiuti qualcuno.

Ho avuto problemi di velocità usando OSX Lion come box di sviluppo web ... Usando una combinazione di suggerimenti ho fatto ricorso alla disabilitazione della rete ipv6 e all'instradamento di ipv6 a localhost6 ... le cose si sono velocizzate un po '...

sudo networksetup -setv6off Ethernet

/ etc / hosts ...

127.0.0.1    localhost
127.0.0.1    dev.aliasdomain.com
... 
::1          localhost6 

Penso che ci siano state alcune correzioni di bug. Ho visto molti problemi menzionati e nessuno di questi sembra essere applicabile al momento (ad esempio, mettere più alias su una singola riga ora funziona bene per me).

In ogni caso sembra che con Lion, Apple abbia apportato alcune modifiche drastiche a mDNSResponder che gestisce tutte le ricerche DNS e (almeno con Lion) gestisce anche / etc / hosts cache. Per me anche le ricerche in avanti ora funzionano. Ma le ricerche inverse (ad esempio, cercare 1.2.3.4 invece di google.com) non funzionano.

Dopo un sacco di problemi, sembra che mDNSResponder converta questa ricerca in 4.3.2.1.in-addr.arpa e fa una ricerca del nome. Questo potrebbe essere il modo in cui il DNS preferisce operare, ma non funziona affatto con / etc / hosts.

A meno che, ovviamente, non si aggiunga un alias di 4.3.2.1.in-addr.arpa per ogni host, dove 4.3.2.1 è l'indirizzo ip nell'ordine opposto a quello in cui si è abituati a vederlo. Questo risolve tutto per me. Ecco un esempio di voce / etc / hosts:

1.2.3.4 foo foo.example.com alias.example.com 4.3.2.1.in-addr.arpa