DNS wird unter Mac OS X nicht aufgelöst

Einige meiner Kollegen haben Probleme auf ihren Macs - Die DNS-Auflösung funktioniert unter Mac OS X nicht. Auf ihnen wird Snow Leopard 10.6.8 ausgeführt. Sie können DNS in einer virtuellen Windows 7-Maschine (VMware Fusion 3.1.3) verwenden, die unter OS X ausgeführt wird. Bei den Computern handelt es sich um 15-Zoll-MacBook Pros, Modell von Anfang 2011.

Dinge, die sie ausprobiert haben und die nicht funktioniert haben:

• Flughafen ein- / ausschalten
• Neustart
• Verwenden Sie stattdessen eine Kabelverbindung über WLAN
• Verbindungsdaten löschen und erneut hinzufügen
• Deaktivieren Sie die Mac-Firewall
• mit festen statischen IP
• Manuelles Einstellen von DNS-Servern
• Neustart von mDNSResponder
• die Korrekturen aus dieser anderen Frage

BEARBEITEN Antwort von Martín:

• Können Sie das DNS, das Sie verwenden möchten, anpingen?

$ ping apple.com
ping: cannot resolve apple.com: Unknown host

• Wie lauten die IP-Adressen der DNS, die Sie verwenden möchten?

Dies ist ein Firmen-DNS-Server, der über DHCP bereitgestellt wird. Er funktioniert auch für andere Personen. Ich habe auch Googles 8.8.4.4 und 205.171.3.65 ausprobiert (was ich aus dem DNS-Benchmark von GRC als das schnellste herausgefunden habe).

• Haben Sie versucht, 8.8.8.8 (google) oder eine der OpenDNS-Versionen 208.67.222.222 oder 208.67.220.220 zu verwenden?

Es funktioniert nicht, siehe Google Chrome-Ausgabe:

Der Server unter www.apple.com kann nicht gefunden werden, da die DNS-Suche fehlgeschlagen ist. DNS ist der Netzwerkdienst, der den Namen einer Website in ihre Internetadresse übersetzt. Dieser Fehler wird meistens dadurch verursacht, dass keine Verbindung zum Internet oder zu einem falsch konfigurierten Netzwerk besteht. Dies kann auch durch einen nicht reagierenden DNS-Server oder eine Firewall verursacht werden, die Google Chrome am Zugriff auf das Netzwerk hindert.

• Können Sie diese Hosts anpingen?

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from
8.8.8.8: icmp_seq=0 ttl=58 time=3.925 ms

• Erstellen eines leeren Benutzers

Es wurde ein Gastbenutzerkonto erstellt, bei Verwendung des Gastkontos war das DNS-Problem noch vorhanden.

• nslookup und dig funktionieren problemlos

$ nslookup www.apple.com 8.8.8.8
Server:  8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
www.apple.com canonical name = www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net canonical name = www.apple.com.edgekey.net.
www.apple.com.edgekey.net canonical name = e3191.c.akamaiedge.net.
Name: e3191.c.akamaiedge.net
Address: 184.24.141.15

$ dig @8.8.8.8 www.apple.com
; <<>> DiG 9.6.0-APPLE-P2 <<>> @8.8.8.8 www.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11298
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION: ;www.apple.com.   IN A
;; ANSWER SECTION:
www.apple.com.  1041 IN CNAME www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net. 38 IN CNAME www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 8794 IN CNAME e3191.c.akamaiedge.net.
e3191.c.akamaiedge.net. 17 IN A 184.24.141.15
;; Query time: 4 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Oct 4 09:25:28 2011
;; MSG SIZE  rcvd: 158

• Auch das Leeren des DNS-Cache wurde durchgeführt, hat aber nicht geholfen

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

EDIT 2 :

$ cat /etc/resolv.conf
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
domain {redacted}.com
nameserver 8.8.8.8
nameserver 208.67.222.222

Es stellte sich heraus, dass die Lösung darin bestand, mDNSResponder zu bouncen:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

Dies wurde von einem anderen Mitarbeiter aus dieser Serverfehlerfrage erhalten .

OS X 10.10.0 - 10.10.3, Yosemite

Offensichtlich gibt es mDNSResponder in Yosemite (OS X 10.10) nicht. Sie können descoveryd stattdessen neu starten, um diese Probleme zu beheben.

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist

OS X 10.10.4+, Yosemite

In OSX 10.10.4 wurde der mDNSResponder wieder eingeführt . Also benutze den ersten, der wieder funktioniert.

Eigentlich denke ich, dass Sie verwenden möchten

scutil --dns

scutil -r hostname

Diese Befehle verwenden den dynamischen Speicher in configd im Gegensatz zu den Flatfiles in / etc, die häufig nur im Einzelbenutzermodus und für nicht vernetzte Systeme gelesen werden.

man scutil   # or

scutil --help  

Die Namensauflösung unter OSX (und UNIX im Allgemeinen) erfolgt anhand der IP-Adressen der DNSs in der Datei /etc/resolv.conf (die von OS X automatisch generiert wird, soweit ich mich erinnern kann).

Da Sie praktisch alles ausprobiert haben, was mir in den Sinn kommt, möchte ich Sie fragen:

• Können Sie den DNS, den Sie verwenden möchten, anpingen?
• Wie lauten die IP-Adressen der DNS, die Sie verwenden möchten?
• Haben Sie versucht, 8.8.8.8 (google) oder eines der OpenDNS 208.67.222.222 oder 208.67.220.220 zu verwenden?
• Können Sie diese Gastgeber anpingen?

Schließlich besteht ein normalerweise guter Test darin, einen leeren Benutzer zu erstellen und zu prüfen, ob dieser neue Benutzer das gleiche Problem aufweist. Wenn dies nicht der Fall ist, können Sie nach dem suchen, was Ihr aktueller Benutzer hat, was das Problem verursachen könnte. Wenn dies auch fehlschlägt, wissen Sie, dass dies eher mit dem System zusammenhängt.

Schauen Sie sich auch in der Konsole um, um zu sehen, ob Sie etwas finden, das in Beziehung steht (und hier einfügen möchten).

Last but not least verfügt Ihr Mac über zwei wichtige DNS-Befehle nslookupund dig.

Geben Sie zum Auflösen von www.apple.com mithilfe des Google-Servers Folgendes ein:

nslookup "host to resolve" "Zu verwendender DNS-Server". Z.B:

$ nslookup www.apple.com 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
www.apple.com   canonical name = www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net    canonical name = www.apple.com.edgekey.net.
www.apple.com.edgekey.net   canonical name = e3191.c.akamaiedge.net.
Name:   e3191.c.akamaiedge.net
Address: 184.24.141.15

NSLookup ist ein alter Befehl (der vor einigen Jahren veraltet sein sollte und durch DIG ersetzt wurde, aber seine benutzerfreundliche Syntax war meiner Meinung nach zu gut, um ihn zu töten.), Sein "Ersatz" ist digein viel mächtigerer Befehl, dessen Syntax ist verrückter.

Um dieselbe Abfrage auszuführen, geben Sie Folgendes ein:

dig @ 8.8.8.8 www.apple.com

Und hier ist die Ausgabe:

$ dig @8.8.8.8 www.apple.com

; <<>> DiG 9.7.3 <<>> @8.8.8.8 www.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17356
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.apple.com.         IN  A

;; ANSWER SECTION:
www.apple.com.      1782    IN  CNAME   www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net. 42 IN CNAME   www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 21581 IN CNAME   e3191.c.akamaiedge.net.
e3191.c.akamaiedge.net. 2   IN  A   184.24.141.15

;; Query time: 26 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Oct  3 21:21:49 2011
;; MSG SIZE  rcvd: 158

Wie Sie sehen, ist dig viel "ausführlicher" (was gut ist, um zu debuggen, was zum Teufel los ist). Die Stärke von dig beruht auf der Tatsache, dass Sie angeben können, welche Art von Abfrage Sie ausführen möchten (unter anderem).

In jedem Fall teilen Sie uns die genauen Ausgaben dieser Befehle mit.

Ich habe das gleiche Problem erlebt ... Und während mDNSResponder neu gestartet wird, scheint es zu "funktionieren", es ein paar Mal pro Stunde neu zu starten.

Daher habe ich das Problem "gelöst", indem ich dnsmasq lokal ausgeführt habe. Das zu tun:

• Erstelle dnsmasq (lade das tgz und makeoder herunter brew install dnsmasq)

• Fügen Sie dies in eine dnsmasq.confDatei ein:

  resolv-file=resolv.conf
  user=nobody
  group=nobody
  interface=lo0
  cache-size=1024
  

• Fügen Sie dies in eine resolv.confDatei ein, die sich im selben Verzeichnis wie die dnsmasq.confDatei befindet (nb: not /etc/resolv.conf ):

  nameserver 8.8.8.8
  nameserver 4.2.2.1
  nameserver 4.2.2.2
  

• Laufen Sie dnsmasqmit sudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf. Die Ausgabe sollte ungefähr so ​​aussehen:

  ...
  dnsmasq: reading resolv.conf
  dnsmasq: using nameserver 4.2.2.1#53
  dnsmasq: using nameserver 4.2.2.2#53
  dnsmasq: using nameserver 8.8.8.8#53
  dnsmasq: read /etc/hosts - 6 addresses
  

• Öffnen Sie die Netzwerkeinstellungen und stellen Sie sicher, dass dies 127.0.0.1der einzige DNS-Server ist (Netzwerkeinstellungen -> Erweitert -> DNS -> 127.0.0.1 hinzufügen).

Die Dinge sollten wieder gut funktionieren.

Sobald die Dinge funktionieren, können Sie dnsmasqohne die --no-daemonund --log-queries-Optionen laufen , so dass es im Hintergrund startet und Sie kein Terminalfenster mehr öffnen müssen.

Ich hatte die gleichen genau gleichen Symptome (und verbrachte eine Weile mit der Fehlerbehebung), aber ich konnte es beheben, als ich merkte, dass ich mich in Unordnung befand /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistund was ich tat, irgendwie als missgebildet interpretiert wurde. Ich habe von einem Backup wiederhergestellt und der Rechner konnte die Hostnamen wieder auflösen.

Bevor ich zu der Lösung kam, wurde mir auch klar, dass ich mit einem SOCKS5-Proxy im Internet surfen ssh -Dund DNS-Lookups durch den Tunnel versuchen konnte.

Ich hatte ein sehr, sehr ähnliches Problem, außer dass die Symptome etwas anders waren.

Mein Benutzer konnte keinen Namen auflösen (lokales NAS, Google usw.), aber ein Gastbenutzer auf demselben iMac (OS X 10.7.4) hat einwandfrei funktioniert.

Das Leeren und Neustarten von mDNSResponder hat eine Weile funktioniert. Wenn der iMac in den Energiesparmodus versetzt wurde, funktioniert er zwar weiterhin, schlägt jedoch nach einem Neustart immer fehl.

Als die Spülung / der Neustart nicht mehr funktionierten, habe ich nach anderen Gründen / Lösungen gesucht und festgestellt, dass dies mit meiner Firewall zusammenhängt. Ich weiß nicht, was in meinen (OS X) Firewall-Einstellungen dazu geführt hat, aber wenn ich die Firewall-Einstellungen wiederhergestellt habe, hat es funktioniert.

So stellen Sie die Standardeinstellungen wieder her:

sudo cp /usr/libexec/ApplicationFirewall/com.apple.alf.plist /Library/Preferences/com.apple.alf.plist

Offensichtlich wurden bei dieser Wiederherstellung alle benutzerdefinierten Regeln entfernt.

Ich wollte meine Version dieses Problems veröffentlichen, da es mir seit Monaten immer wieder Kummer bereitet. Dieser Beitrag ist die beste Sammlung möglicher Lösungen im Internet!

Ich habe dieses Problem mit Yosemite (10.10) gelöst. Es stellte sich heraus, dass ein Schlüsseldämon ausgeschaltet wurde discoveryd, da er zu viel CPU verbrauchte.

2014/10/22 3:50:07.000 PM kernel[0]: process discoveryd[49] thread 1251 caught burning CPU! It used more than 50% CPU (Actual recent usage: 68%) over 180 seconds. thread lifetime cpu usage 90.016372 seconds, (74.516637 user, 15.499735 system) ledger info: balance: 90007570271 credit: 90007570271 debit: 0 limit: 90000000000 (50%) period: 180000000000 time since last refill (ns): 131905306167 

Seltsamerweise führte ein Neustart nicht zum Neustart.

Ich habe den Dienst manuell neu gestartet mit:

sudo launchctl kickstart -k system/com.apple.networking.discoveryd

und jetzt ist alles gut.

Ich habe das gleiche Problem mit 10.6.8. Die erste Reise in einen Apple Store führte zur Systemwiederherstellung. Aber danach brach der DNS wieder zusammen, während ich im Ausland war und keine System-DVD bei mir hatte. Zu dieser Zeit fand ich diesen Thread und löschte /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistper @freezedpeanuts und @Tom Thorogood.

Es hat das Problem behoben, aber erstaunlicherweise ist DNS ein paar Tage später zum dritten Mal kaputt gegangen. Ich habe ein System-Image von 10.6.3 gefunden und:

1. /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistVom Systemimage kopiert .
2. sudo chown root /System/Library/LaunchDaemons/com.apple.mDNS*
3. Neu gestartet

Das hat das Problem behoben.

Es bricht jetzt in regelmäßigen Abständen ab (etwa einmal im Monat), und die Wiederherstellung erfolgt wie oben beschrieben. Anstatt einen Neustart durchzuführen, können Sie:

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

Bitte beachten Sie, dass Sie möglicherweise alle öffentlichen DNS-Server entfernen müssen, bis der Cache geleert ist.

Ich hatte anscheinend das gleiche Problem wie das OP. Unter Verwendung des Tools networksetup stellte ich fest, dass für den angegebenen Netzwerknamen ein falsches DNS konfiguriert wurde:

networksetup -getdnsservers <networkname>

eingetragen 192.168.0.1 als DNS. Unter Verwendung von scutil - dns habe ich vergleichbare Ergebnisse erhalten, in denen aufgelistet ist, dass der Resolver # 2 den Nameserver [0] verwendet: 192.168.0.1.

Befehl verwenden

networksetup -setdnsservers <networkname> 192.168.188.1 8.8.8.8

Ich konnte den DNS für das angegebene Netzwerk neu konfigurieren und die Namen lokaler und globaler Computer auflösen, wenn eine Verbindung zum VPN besteht.

In meinem Fall war alles andere in Ordnung: mDNSResponder lief und funktionierte, host/ nslookupfunktionierte, beides /etc/resolv.confund networksetupmeldete die korrekten DNS-Server usw. Trotzdem pingfunktionierte die DNS-Auflösung im Allgemeinen (z. B. mit ) einige Stunden später nicht mehr Stiefel.

Dieses spezielle Problem mag etwas unwahrscheinlich sein, aber ich werde es hier trotzdem als Antwort dokumentieren.

Ich bemerkte erst, als die Maschine langsamer wurde, aber viele identische Prozesse liefen . sensu-clientspeziell.

Wir hatten es in launchd mit dieser plist-Datei konfiguriert:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd>
<plist version="1.0">
  <dict>
  <key>KeepAlive</key>
  <true/>
  <key>RunAtLoad</key>
  <true/>
  <key>WorkingDirectory</key>
  <string>/etc/sensu</string>
  <key>UserName</key>
  <string>root</string>
  <key>Label</key><string>org.sensuapp.sensu-client</string>
    <key>ProgramArguments</key>
    <array>
      <string>/usr/bin/sensu-client</string>
      <string>-d/etc/sensu/conf.d/</string>
      <string>-b</string>
    </array>
  </dict>
</plist>

Die -bFlagge, sensu-clientdie es in den Hintergrund rücken lässt und als Dämon fungiert. Es launchdsieht jedoch nur so aus, dass der ursprüngliche Prozess beendet wurde und ihn (entsprechend dem KeepAliveFlag) neu startet. Dies lässt Tausende von gespaltenen Prozessen im Hintergrund, und selbst dann wird launchd die Tatsache, dass es ausgeführt wird, nicht klüger sehen.

Ich glaube, dass diese mehreren tausend Prozesse (allesamt sensu-clientdie Software, für die wir eine launchd-Konfiguration geschrieben hatten) gleichzeitig Anfragen an mDNSResponder stellten, was effektiv zu einer lokalen Dienstverweigerung des DNS-Cache führte . Das Beenden dieser Prozesse und das Reparieren der Liste, die zum Starten gegeben wurde, lösten schließlich das Problem.

Die Plist-Korrektur bestand nur darin, das -bFlag (background / daemonise) aus dem Aufruf von sensu-client zu entfernen . Beachten Sie, dass dies nicht Sensus Schuld ist. Diese Liste wurde von einem ehemaligen Systemadministrator dieser Firma verfasst.

Im Folgenden finden Sie einige erweiterte Befehle, mit denen Sie das DNS-Problem beheben können:

• Führen Sie aus, digum die Stammnamenserver aufzulisten.
• Ausführen dig example.com, um die DNS-Suche für die example.comDomäne auszuführen .
• Veröffentlichen Sie Ihr Hardware - Ports durch: networksetup -listallhardwareports.
• Überprüfen Sie die Ausgabe des DHCP / BOOTP-Pakets, das der Client vom DHCP / BOOTP-Server akzeptiert hat ipconfig getpacket en0.
• Überprüfen Sie Ihre DNS - Konfiguration durch: scutil --dns.
• Stellen Sie sicher , dass mDNSResponderProzess ausgeführt wird durch: ps wuax | grep mDNSResponder.
• ARP-Übersetzungseinträge leeren durch: arp -ad( man arpum Hilfe bitten). ^Quelle

Zum Debuggen des mDNSResponderProzesses kann der folgende Befehl hilfreich sein:

(sleep 1 && sudo killall -INFO mDNSResponder &); log stream | grep mDNSResponder

Der obige Befehl sendet ein SIGINFOSignal an den Prozess, der die Debugging-Details in die Protokollausgabe schreibt, die gelesen und analysiert werden kann.

Das Ein- und Ausschalten von WLAN hat geholfen.

^{MacBook Pro mit 10.9.1}

Vor allem, wenn Sie WLAN ausschalten und dann neu starten. Die zusätzliche Verzögerung und der Verzicht auf eine IP- / Netzwerkverbindung sorgen dafür, dass die Aufforderung, sich erneut dem Netzwerk anzuschließen, bessere Erfolgschancen hat.

Dies wird wahrscheinlich niemandem helfen, aber für den Fall, dass ich vor einiger Zeit versehentlich eine Datei in dem Ordner erstellt habe, als ein DNS für eine bestimmte Domain nicht verfügbar war:

/ etc / resolver /

und dies verhinderte zwei Jahre später, dass ein bestimmter Name jemals aufgelöst wurde.

Leider hat mir nichts davon geholfen und es stellte sich heraus, nachdem ich eine Stunde lang versucht hatte, es herauszufinden und meinen Kopf gegen den Kaffeetisch geschlagen hatte. Irgendetwas, irgendwie, irgendwo ... entfernte die /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistDatei und war der Grund, warum ich dieses Problem hatte.

Das wurde mir klar, als ich diese Fehlermeldung sah: /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist: No such file or directory

Hier ist eine Kopie einer Version von El Capitan: https://gist.github.com/tripflex/e7147690d1768dc74b1dd626614573c0

Hier ist der Code aus diesem Kern:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.apple.mDNSResponder.reloaded</string>
    <key>OnDemand</key>
    <false/>
    <key>InitGroups</key>
    <false/>
    <key>UserName</key>
    <string>_mdnsresponder</string>
    <key>GroupName</key>
    <string>_mdnsresponder</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/sbin/mDNSResponder</string>
    </array>
    <key>MachServices</key>
    <dict>
        <key>com.apple.mDNSResponder</key>
        <true/>
            <key>com.apple.mDNSResponder.dnsproxy</key>
            <true/>
    </dict>
    <key>Sockets</key>
    <dict>
        <key>Listeners</key>
        <dict>
            <key>SockFamily</key>
            <string>Unix</string>
            <key>SockPathName</key>
            <string>/var/run/mDNSResponder</string>
            <key>SockPathMode</key>
            <integer>438</integer>
        </dict>
    </dict>
    <key>POSIXSpawnType</key>
    <string>Interactive</string>
    <key>EnablePressuredExit</key>
    <false/>
</dict>
</plist>

Wie sich herausstellt, müssen Sie zur Behebung des Problems eine Suchdomäne konfigurieren und in das Feld "Suchdomäne" unter "DNS-Konfiguration in den Systemeinstellungen" einfügen. Grundsätzlich funktioniert die Suchdomäne so wie .local, aber stattdessen.

Sie müssen Ihre Suchdomäne als Masterzone auf Ihrem DNS-Server einrichten, damit dies funktioniert.

Ich habe ein ähnliches Problem mit der Suche nach dem Host-Server. Wir haben 21 iMacs auf dem Server (El Capitan, kürzlich aktualisiert) und nur einer wird nicht gebunden. Das Update ist normalerweise ziemlich einfach über Benutzer und Gruppen in SysPref. Löschen des Host-Servers und erneutes Binden, Suchen des verfügbaren Servers in der Dropdown-Option, aber aus einem unbekannten Grund wird der Server als aufgeführt. Dabei handelt es sich unkown-00-00-12-34-56-78.home, wie ich festgestellt habe, um die MAC-Adresse des Servers. Ich habe dies im Terminal ausgeführt:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

und

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

kehrte zurück, um in SysPref an den Server zu binden, und die richtige Servername-Option wurde kurz angezeigt und dann direkt vor meinen Augen wieder in "unbekannt-00-00-12-34-56-78.home" geändert!

Bei folgenden Befehlen aus akzeptierter Antwort:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

Sie könnten auf die Warnung stoßen:

Der Betrieb ist nicht zulässig, während der Systemintegritätsschutz aktiviert ist

Sie müssen es ausschalten. Eine vollständige Anleitung finden Sie hier: https://www.howtogeek.com/230424/wie-deaktiviert-Systemintegritätsschutz-auf-einem-Mac-und-Warum-Sie-sollten-nicht/

In meinem Fall hatte ich OpenDNS in der Vergangenheit installiert und es wurde nicht sauber entfernt. Es wurden mehrere DNS-bezogene Prozesse ausgeführt, z. B. DNSdnscrypt-proxy. Ich konnte das Beenden in Activity Monitor nicht erzwingen, aber ich konnte den Start beim Neustart verhindern, indem ich die .plist-Datei in Library / LaunchDaemons entfernte.

Gehen Sie zu Einstellungen -> Netzwerk -> Erweitert -> DNS. Nehmen Sie dann buchstäblich alle Änderungen an DNS vor (ordnen Sie beispielsweise Ihre DNS-Einträge neu an). Klicken Sie dann auf "OK" und anschließend auf "Übernehmen" im nächsten Bildschirm. Lassen Sie sich nicht davon täuschen, dass die von Ihnen vorgenommene Änderung von Bedeutung war. Es ist die Magie der Schaltfläche "Übernehmen".

~ $  time nslookup www.google.com
;; connection timed out; no servers could be reached


real    0m21.041s
user    0m0.006s
sys     0m0.010s

 ~ $  time nslookup www.google.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   www.google.com
Address: 172.217.5.4


real    0m0.079s
user    0m0.006s
sys     0m0.010s

Was für mich funktioniert hat, war das Entfernen aller Servereinträge von DNS-Servern und Suchdomänen von:

Systemeinstellungen → Netzwerk → Erweitert ... → DNS

Nach dem Upgrade von Snow Leopard auf ein altes MacBook auf Mountain Lion konnte das System DNS nicht auflösen. Spülen, neu starten, nichts hat geholfen. Das Wechseln von WiFi zu einem anderen Zugangspunkt (meinem Telefon) hat geholfen.

Mountain Lion fügt den DHCP-Netzwerkeinstellungen ein neues Client-Feld hinzu. Das Ausfüllen dieses Feldes schien den WLAN-Zugangspunkt glücklich zu machen. Leer zu lassen bedeutete, dass nichts durchging, obwohl die WLAN-Verbindung erfolgreich zu sein schien.