Mac OSX Lion DNS-Suchreihenfolge [geschlossen]

Nach dem Upgrade auf Mac OSX Lion habe ich festgestellt, dass / etc / hosts nicht mehr an erster Stelle nach Namensauflösung gesucht wird. Dies führt zu einigen Nebenwirkungen wie:

1. Einträge in / etc / hosts werden schmerzhaft langsam aufgelöst
2. Sie können vorhandene Domains nicht überschreiben, z. B. 127.0.0.1 www.google.com
3. Wenn Sie Suchdomäneneinträge von DHCP erhalten, sagen wir .lan, und ein lustiger Typ hat localhost.lan für etwas anderes als 127.0.0.1 im lokalen DNS konfiguriert. Sie können Ihren localhost nicht mehr erreichen.

Ist dieses Verhalten beabsichtigt? Macht es irgendeinen Sinn? Und vor allem, wie kann ich zum alten Verhalten zurückkehren?

Ich denke, es ist wichtig, dass Lion .local TLD anders behandelt, da es für einige Multicast-DNS-Funktionen (von Bonjour verwendet) reserviert ist. Die einzige Möglichkeit, dieses Problem zu lösen, besteht darin, eine andere TLD für Entwicklungshosts zu verwenden (dh: .dev). Es funktioniert gut für mich, hoffe es wird anderen helfen!

In Bezug auf das Überschreiben von Domänen in der Hosts-Datei habe ich festgestellt, dass Lion unter bestimmten Umständen die IPv6-Adresse für eine Domäne abfragt, wenn festgestellt wird, dass eine Domäne über das IPv4-Netzwerk nicht erreichbar ist.

Ich entdeckte dies, als ich einige Anzeigen bemerkte, die ich noch nie zuvor auf Snow Leopard gesehen hatte, weil ich die Anzeigendomains auf umgeleitet hatte 127.0.0.1. Ich habe Wireshark gestartet und AAAAnach den IPv4- AAbfragen (IPv4) Abfragen ( IPv6-DNS-Einträge) festgestellt . Die Ad-Server haben in der Tat IPv6-Adressen und konnten mir ihre Inhalte bereitstellen.

Die Lösung hierfür ist a

::1 mydomain.com

Eintrag für jeden

127.0.0.1 mydomain.com

Eintrag in Ihrer Hosts-Datei.

Interessanterweise wird 127.0.0.1:80keine AAAAAbfrage ausgegeben , wenn zufällig ein lokaler Webserver ausgeführt wird und Ihr Browser eine Antwort vom Webserver erhält (Fehler oder auf andere Weise) , da davon ausgegangen zu sein scheint, dass zumindest eine TCP-Verbindung möglich war.

Wenn Sie die Hosts-Datei (für Adblocking, lokale Webentwicklung usw.) stark nutzen, sollten Sie einen eigenen lokalen DNS-Resolver verwenden. Es gibt einen beträchtlichen Festplatten- / CPU-Treffer, wenn Sie /etc/hostsjede Anforderung lesen müssen. Es liegt daher in Ihrem Interesse, diese Datei sehr leicht zu halten.

Ein Vorteil der dnsmasqlokalen Ausführung (neben der erheblichen Leistungssteigerung) besteht darin, dass Sie ganze Domänen der obersten Ebene zurück auf Ihren lokalen Computer umleiten können. Auf diese Weise können Sie den gesamten * .dev-Namespace für die Entwicklung (zum Beispiel) verwenden, ohne jede Domäne, in die Sie lokal aufgelöst werden möchten, einzeln eingeben zu müssen/etc/hosts

Das Problem war, dass ich die Datei / etc / hosts verknüpft habe. Wenn / etc / hosts eine einfache Datei ist, ist alles in Ordnung.

Update (2): OSX 10.10.5 bringt die Rückkehr von mDNSResponder.

Update: OSX 10.10 Yosemite hat mDNSResponder durch "removeyd" ersetzt. Ich habe kein Upgrade durchgeführt, daher bin ich mir nicht sicher, wie sich das DNS mit DNS-Suchvorgängen und -Entdeckungen verhält/etc/hosts .

Der System-DNS-Resolver auf Lion ist der mDNSResponder Prozess.

Sie denken vielleicht "aber mDNSResponder ist der Multicast-DNS-Responder." Du hast recht; Dafür war es ursprünglich gedacht und erfüllt diese Funktion immer noch. In neueren MacOS-Versionen werden jedoch auch Standard-Host-Lookups durchgeführt.

In Lion scheint es nicht automatisch neu zu lesen, /etc/hostswenn es sich ändert, zumindest nicht immer. Das Beenden mDNSResponder(und das automatische Neustarten) scheint das Problem zu beheben.

sudo killall mDNSResponder

sollte den Trick machen.

Unten ist meine ursprüngliche Antwort für die Nachwelt. Ich nehme an, dass es in einigen Fällen immer noch ein Problem sein könnte.

Stellen Sie sicher, dass es sich bei Ihrer /etc/hostsDatei um eine Textdatei im Unix-Stil handelt, bei der Zeilenvorschübe als Ende und nicht als Cr-Dateien verwendet werden.

Beim Bearbeiten mit TextWrangler oder einem Unix-Texteditor sollte die Datei erhalten bleiben.

Wenn Ihre Datei bereits durcheinander ist, versuchen Sie dies zu beheben

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

Gutschrift für dieses Update an:

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

Ich hatte dieses Problem für eine Weile, da ich in einem Team von Entwicklern arbeitete, wurde es notwendig, tatsächlich .local anstelle von .dev oder .localhost zu verwenden. Ich fand diesen Artikel sehr nützlich.

iTand.me - Lion lokale Domains und etc Hosts ..

Zusammenfassend;

Wenn Sie jedoch .local verwenden müssen, ist das Dienstprogramm dscl die eleganteste Lösung, die ich gefunden habe. Die Verwendung ist sehr einfach. Gehen Sie folgendermaßen vor, um einen Host mit dem Namen mydev.local hinzuzufügen und auf den lokalen Host zu verweisen:

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

Anzeigen aller aktuell definierten Hosts und ihrer IPs

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

Und um einen Host zu entfernen:

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

Insgesamt ziemlich unkompliziert und funktioniert gut. Ich würde es immer noch vorziehen, stattdessen / etc / hosts zu bearbeiten, aber dies ist eine bessere Alternative, um alle unsere .local-Server umbenennen zu müssen.

Bevor ich von Snow Leopard zu Lion wechselte, hatte ich einige app-spezifische Einträge in /etc/hosts:

127.0.0.1 foo.bar.local

Nach dem Update war das Laden meiner lokalen Apps SEHR langsam. Ich habe festgestellt, dass die Verzögerung aufgetreten ist, bevor die Anforderung in der Protokolldatei angezeigt wurde, und dass die App selbst so schnell wie gewöhnlich war.

Jetzt habe ich zwei Zeilen pro App, so:

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

... und alles ist wieder schnell.

Anscheinend fügt dies IPv6-Adressen hinzu? Ich verstehe es nicht ganz, aber es funktioniert.

Meine Situation war ähnlich, aber die Verzögerungen von genau 5 Sekunden traten nur bei URLs auf, die mit '.local' endeten. Beim Anzeigen von Websites, die mit '.dev' endeten, gab es keine Verzögerung.

Einige der anderen Entwickler in meinem Büro hatten dieses Problem, einige nicht. Ich hatte auf eine einfache Lösung gehofft und wollte die Site aufgrund anderer Abhängigkeiten nicht in ".local" umbenennen.

Ich habe den folgenden Befehl in Terminal ausgeführt und meine Ausgabe mit einigen anderen Benutzern im Büro geteilt.

scutil --dns

Dieser Abschnitt war der einzige Unterschied:

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

Mein Mac war mit meinem iCloud-Konto verknüpft und Back To My Mac war aktiviert. Nachdem ich Back To My Mac deaktiviert hatte, verschwand der zusätzliche Resolver und die Verzögerung von 5 Sekunden verschwand.

Wow, was für ein Albtraum. Ich habe absolut alles zu diesem Thema gelesen und alles, was bisher vorgeschlagen wurde, war verlockend nah an dem, was ich erlebte, aber keine der Lösungen hat für mich funktioniert.

Und ich habe herausgefunden warum.

Im Gegensatz zu anderen habe ich / etc / hosts nicht zum Einrichten lokaler Domänen verwendet. Meine Datei / etc / hosts war auf Lager und enthielt nur die Einträge, die für die Loopback-Schnittstelle und den Broadcast-Host benötigt wurden. Außerdem war es eine korrekt codierte Unix-Datei, da ich die Art von Person bin, die diese nur über die Befehlszeile mit Emacs bearbeiten würde. Und Gott sei Dank musste ich nicht auf meinen eigenen DNS-Server wie DNSmasq zurückgreifen, um das Problem zu umgehen.

(Um es klar auszudrücken, das Symptom, das mich hierher zu diesem Problem gebracht hat, war, dass der Start von Emacs ungefähr 10 Sekunden dauerte, aber nur, wenn ich über WLAN verfügte. Wenn ich WLAN ausschaltete, wurden Emacs sofort wie erwartet gestartet.)

Meine Lösung: Mein Laptop hat den Namen "Terminator". (Ja, sein glänzendes Aluminiumgehäuse ließ mich an den Arnold Schwarzenegger-Charakter denken.) Ich musste nur Einträge zu / etc / hosts hinzufügen, um den Namen der Maschine selbst zu erhalten:

127.0.0.1   terminator
::1         terminator

Ich habe den Namen meines Hosts gefunden, indem ich einen einfachen Befehl im Terminal ausgeführt habe:

hostname

... was mit dem Ausgang "terminator" zurückkam. Nachdem / etc / hosts geändert wurde, um diese beiden Einträge zu enthalten, kann emacs jetzt den Namen meines Laptops schnell auflösen.

Ich hoffe das hilft jemandem.

Ich hatte Geschwindigkeitsprobleme mit OSX Lion als Webentwicklungsbox ... Mit einer Kombination von Vorschlägen habe ich das IPv6-Netzwerk deaktiviert und IPv6 an localhost6 weitergeleitet ... die Dinge haben sich ziemlich beschleunigt ...

sudo networksetup -setv6off Ethernet

/ etc / hosts ...

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

Ich denke, es gab einige Fehlerbehebungen. Ich habe viele erwähnte Probleme gesehen, und keines davon scheint derzeit zuzutreffen (zum Beispiel funktioniert es jetzt gut, mehrere Aliase in eine einzelne Zeile zu setzen).

Auf jeden Fall scheint Apple mit Lion einige drastische Änderungen an mDNSResponder vorgenommen zu haben, der alle DNS-Lookups und (zumindest mit Lion) auch das Cacheing von / etc / hosts verwaltet. Für mich funktionieren Forward Lookups jetzt auch. Reverse Lookups (z. B. Nachschlagen von 1.2.3.4 anstelle von google.com) funktionieren jedoch nicht.

Nach vielen Schmerzen sieht es so aus, als ob mDNSResponder diese Suche in 4.3.2.1.in-addr.arpa konvertiert und eine Namenssuche durchführt. So funktioniert DNS zwar am liebsten, funktioniert aber mit / etc / hosts überhaupt nicht.

Es sei denn, Sie fügen für jeden Host einen Alias ​​von 4.3.2.1.in-addr.arpa hinzu, wobei 4.3.2.1 die IP-Adresse in der entgegengesetzten Reihenfolge ist, von der aus Sie sie gewohnt sind. Das behebt alles für mich. Hier ist ein Beispieleintrag für / etc / hosts:

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