DNS wird unter Mac OS X nicht aufgelöst

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

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

Anscheinend existiert mDNSResponder nicht in Yosemite (OS X 10.10). Sie können stattdessen descoveryd 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 . Verwenden Sie also den ersten, der wieder funktioniert.

Eigentlich denke ich, dass Sie vielleicht verwenden möchten

scutil --dns

scutil -r hostname

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

man scutil   # or

scutil --help  

Ich habe das gleiche Problem erlebt ... Und während der Neustart von mDNSResponder zu "funktionieren" scheint, ist es ziemlich scheiße, ihn ein paar Mal pro Stunde neu zu starten.

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

• Erstellen Sie dnsmasq (laden Sie 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 (Achtung: nicht /etc/resolv.conf ):

  nameserver 8.8.8.8
  nameserver 4.2.2.1
  nameserver 4.2.2.2
  

• dnsmasqMit laufen sudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf. Die Ausgabe sollte in etwa 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 Optionen --no-daemonund ausführen --log-queries, sodass es im Hintergrund gestartet wird und Sie kein Terminalfenster geöffnet halten müssen.

Die Namensauflösung unter OSX (und UNIX im Allgemeinen) wird von den IP-Adressen der DNSs in der Datei in /etc/resolv.conf übernommen (die OS X automatisch generiert, 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 lautet/sind die IP-Adresse(n) der DNS(s), 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 Hosts anpingen?

Schließlich besteht ein normalerweise guter Test darin, einen leeren Benutzer zu erstellen und zu sehen, ob dieser neue Benutzer das gleiche Problem aufweist. Wenn dies nicht der Fall ist, können Sie damit beginnen, herauszufinden, was Ihr aktueller Benutzer hat, der das Problem verursachen könnte. Wenn es auch fehlschlägt, wissen Sie, dass dies eher mit dem "System" zu tun hat.

Schauen Sie sich auch in der Konsole um, um zu sehen, ob Sie etwas finden können, das möglicherweise verwandt ist (und das Sie hier einfügen möchten).

Zu guter Letzt verfügt Ihr Mac über zwei wichtige DNS-Befehle nslookupund dig.

Um also www.apple.com mit dem Google-Server aufzulösen, würden Sie Folgendes eingeben:

nslookup "Aufzulösender Host" "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 und durch DIG ersetzt werden sollte, aber seine einfach zu verwendende Syntax war zu gut, um sie zu töten, denke ich.), sein "Ersatz" ist dig, ein viel mächtigerer Befehl, dessen Syntax ist verrückter.

Um dieselbe Abfrage auszuführen, würden Sie Folgendes eingeben:

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 können, ist dig viel "ausführlicher" (was gut ist, um zu debuggen, was zum Teufel vor sich geht). Die Stärke von dig ergibt sich aus der Tatsache, dass Sie angeben können, welche Art von Abfrage Sie durchführen möchten (unter anderem).

Teilen Sie uns in jedem Fall die genauen Ausgaben dieser Befehle mit.

Ich hatte genau die gleichen Symptome (und verbrachte eine Weile mit der Fehlersuche), aber ich konnte es lösen, als ich merkte, dass ich herumgespielt /System/Library/LaunchDaemons/com.apple.mDNSResponder.plisthatte und das, was ich tat, irgendwie als fehlerhaft interpretiert wurde. Ich habe von einer Sicherung wiederhergestellt und die Maschine konnte Hostnamen wieder auflösen.

Bevor ich zur Lösung kam, stellte ich auch fest, dass ich im Internet surfen konnte, wenn ich einen SOCKS5-Proxy durch verwendete ssh -Dund DNS-Lookups durch den Tunnel versuchte.

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) funktionierte einwandfrei.

Das Leeren und Neustarten von mDNSResponder wie erwähnt hat eine Weile funktioniert. Während es weiter funktionierte, wenn der iMac in den Ruhemodus versetzt wurde, schlug es nach dem Neustart immer fehl.

Als der Spülvorgang/Neustart nicht mehr funktionierte, suchte ich nach anderen Gründen/Lösungen und fand heraus, dass es mit meiner Firewall zusammenhängt. Ich weiß nicht, was in meinen (OS X) Firewall-Einstellungen es verursacht hat, aber wenn ich die Firewall-Einstellung wiederhergestellt habe, hat es funktioniert.

So stellen Sie die von mir verwendeten 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 teilen, da es mir seit Monaten immer wieder Kummer bereitet und dieser Beitrag die beste Sammlung möglicher Lösungen im Netz ist!

Ich bin auf dieses Problem auf Yosemite (10.10) gestoßen. Es stellte sich heraus, dass ein wichtiger Daemon, discoveryd, beendet wurde, 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 dazu, dass es neu gestartet wurde.

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. Der erste Besuch in einem Apple Store führte zu einer Systemwiederherstellung. Aber danach brach DNS wieder zusammen, während ich im Ausland war und keine System-DVD dabei hatte. Damals habe ich diesen Thread gefunden und /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistper @freezedpeanuts und @Tom Thorogood gelöscht.

Es hat das Problem behoben, aber erstaunlicherweise brach DNS ein paar Tage später zum dritten Mal zusammen. Ich habe ein Systemabbild von 10.6.3 gejagt und:

1. Aus dem Systemabbild /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistkopiert.
2. sudo chown root /System/Library/LaunchDaemons/com.apple.mDNS*
3. Neustart

Das hat das Problem behoben.

Es bricht jetzt regelmäßig für mich zusammen (einmal im Monat oder so), und das Wiederherstellungsverfahren ist auf die obigen Schritte beschränkt, außer dass Sie anstelle eines Neustarts Folgendes tun können:

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

Bitte beachten Sie für alle, die weiterhin Probleme haben, dass Sie möglicherweise alle öffentlichen DNS-Server entfernen müssen, bis der Cache geleert ist.

Ich hatte anscheinend das gleiche Problem wie der OP. Mit dem Tool networksetup habe ich festgestellt, dass für den angegebenen Netzwerknamen ein falscher DNS konfiguriert wurde:

networksetup -getdnsservers <networkname>

192.168.0.1 als DNS aufgeführt. Mit scutil --dns habe ich vergleichbare Ergebnisse erhalten und aufgelistet, dass Resolver Nr. 2 nameserver[0] verwendet: 192.168.0.1.

Verwenden des Befehls

networksetup -setdnsservers <networkname> 192.168.188.1 8.8.8.8

Ich konnte das DNS für das angegebene Netzwerk neu konfigurieren und die Namen lokaler und globaler Maschinen auflösen, wenn ich mit dem VPN verbunden war.

WLAN aus- und wieder einschalten hat geholfen.

^{MacBook Pro mit 10.9.1}

Vor allem, wenn du das WLAN ausschaltest und dann neu startest. Die zusätzliche Verzögerung und das Starten ohne IP-/Netzwerkverbindung stellen sicher, dass die Anfrage zum erneuten Beitritt zum Netzwerk bessere Erfolgschancen hat.

Dies wird wahrscheinlich niemandem helfen, aber falls ich vor einiger Zeit versehentlich eine Datei in dem Ordner erstellt habe, als ein DNS für eine bestimmte Domain ausgefallen ist:

/etc/resolver/

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

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

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

Ich habe es erst bemerkt, als die Maschine langsamer wurde, aber es liefen viele identische Prozesse . sensu-client, speziell.

Wir haben 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>

Das -bFlag to sensu-clientbringt es in den Hintergrund und fungiert als Daemon. Alles, was Sie launchdsehen, ist jedoch, dass der ursprüngliche Prozess beendet wurde, sodass er ihn (gemäß dem KeepAliveFlag) neu startet. Dies lässt Tausende von gegabelten Prozessen im Hintergrund zurück, und selbst dann wird launchd nicht klüger sein, dass es läuft.

Ich glaube, dass diese mehreren tausend Prozesse (alle sensu-client, die Software, für die wir eine launchd-Konfiguration geschrieben hatten) gleichzeitig Anfragen an mDNSResponder gestellt haben, was effektiv zu einem lokalen Denial-of-Service des DNS-Cache geführt hat . Das Beenden dieser Prozesse und das Reparieren der an launchd übergebenen plist löste schließlich das Problem.

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

Hier sind einige erweiterte Befehle, die bei der Behebung des DNS-Problems helfen können:

• Ausführen dig, um die Root-Nameserver aufzulisten.
• Ausführen dig example.com, um die DNS-Suche für die example.comDomäne auszuführen.
• Listen Sie Ihre Hardwareports auf nach: networksetup -listallhardwareports.
• Überprüfen Sie die Ausgabe des DHCP/BOOTP-Pakets, das der Client vom DHCP/BOOTP-Server akzeptiert hat, durch: ipconfig getpacket en0.
• Überprüfen Sie Ihre DNS-Konfiguration wie folgt: scutil --dns.
• Überprüfen Sie, ob der mDNSResponderProzess ausgeführt wird, indem Sie: ps wuax | grep mDNSResponder.
• ARP-Übersetzungseinträge leeren durch: arp -ad(Run man arpfor help). ^Quelle

Um den Prozess zu debuggen mDNSResponder, 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 Debugging-Details in die Protokollausgabe ausgibt, die gelesen und analysiert werden kann.

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 zu schlagen ... etwas, irgendwie, irgendwo ... entfernte die /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistDatei und war der Grund, warum ich dieses Problem hatte.

Dies 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>

DNSResponder neu starten / DNS-Cache löschen in macOS Mojave:

sudo killall -HUP mDNSResponder

Keine Probleme mit System Integrity Protection, im Gegensatz zum Neuladen der Konfigurationsdateien.

In meinem Fall war die Hauptursache, dass das DoS-Schutzsystem meines WLAN-Heimrouters fälschlicherweise die MAC-Adresse meines macOS-Geräts zur Blacklist hinzugefügt hat. Nach dem manuellen Löschen der Blacklist und dem Ausführen sudo killall -HUP mDNSRespondervon , funktionieren die Befehle dig, ping und traceroute alle gut.

Unter Mac OS Mojave 10.14.6 habe ich vor kurzem angefangen, häufige Fehler bei der DNS-Suche zu sehen. Ich habe diese Funktion in meiner .bashrc:

function resetdns() {
     dscacheutil -flushcache;
     sudo killall -HUP mDNSResponder
     sudo killall -9 mDNSResponder mDNSResponderHelper
     sudo launchctl stop homebrew.mxcl.dnsmasq 
     sudo launchctl start homebrew.mxcl.dnsmasq
}

Beim Laufen

$ resetdns

DNS-Lookups funktionierten wieder einwandfrei.

Wie sich herausstellt, müssen Sie zur Lösung des Problems eine Suchdomäne konfigurieren und sie dem Suchdomänenfeld unter Systemeinstellungen DNS-Konfiguration hinzufügen. Grundsätzlich funktioniert die Suchdomäne ähnlich wie .local, aber stattdessen wird es .

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

Ich habe ein ähnliches Problem mit dem Finden des Host-Servers. Wir haben 21 iMacs auf dem Server (El Capitan, kürzlich aktualisiert) und nur einer wird nicht gebunden. Die Lösung ist normalerweise ziemlich einfach über Benutzer und Gruppen in SysPref. Löschen des Hostservers und erneutes Binden, Suchen des verfügbaren Servers in der Dropdown-Option, aber aus irgendeinem unbekannten Grund wird der Server als aufgelistet unkown-00-00-12-34-56-78.home, was ich gefunden habe, ist die MAC-Adresse des Servers. Ich habe das 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

zurückgekehrt, um in SysPref an den Server zu binden, und die Option für den korrekten Servernamen erschien kurz und änderte sich dann direkt vor meinen Augen wieder in "unknown-00-00-12-34-56-78.home"!

In meinem Fall hatte ich in der Vergangenheit OpenDNS installiert und es wurde nicht sauber entfernt. Es wurden mehrere DNS-bezogene Prozesse ausgeführt, z. B. DNSdnscrypt-proxy. Ich konnte das Beenden im Aktivitätsmonitor nicht erzwingen, aber ich konnte verhindern, dass sie beim Neustart gestartet wurden, 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 im nächsten Bildschirm auf „Übernehmen“. Lassen Sie sich nicht täuschen, dass die von Ihnen vorgenommene Änderung signifikant 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

Durch die Deinstallation des Umbrella Roaming Client funktionierten DNS-Lookups für mich unter Mac OS Mojave einwandfrei.

Führen Sie die Anwendung aus

Applications > OpenDNS Roaming Client  > Umbrella Roaming Client Uninstaller.

Läuft unter MacOS Mojave 10.14.6. Meistens die gleichen Probleme wie OP und andere. Alles funktioniert einwandfrei, dann plötzlich kein Zugriff auf Internet oder lokale Adressen. Ich kann über die IP-Adresse zugreifen, aber nicht über DNS. Weder WLAN noch Kabelverbindung. Ganz klar ein DNS-Problem. Ich kann korrekte DNS-Einträge in den Netzwerkeinstellungen...Erweitert...DNS sehen. Bisher war die Lösung nur ein Neustart. Würde dann ein paar Tage gut funktionieren, dann würde es wieder passieren.

Was für mich funktioniert hat, wurde oben von @ user674669 bereitgestellt

function resetdns() {
 dscacheutil -flushcache;
 sudo killall -HUP mDNSResponder
 sudo killall -9 mDNSResponder mDNSResponderHelper
 sudo launchctl stop homebrew.mxcl.dnsmasq 
 sudo launchctl start homebrew.mxcl.dnsmasq

}

Beim Laufen

$ resetdns

Ich habe jede Zeile in der Funktion einzeln ausgeführt. Ich werde jetzt sehen, ob ich es schreiben kann, da ich mir ziemlich sicher bin, dass ich es wieder brauchen werde.

Ok, ich habe eine Lösung, aber die Hauptfrage ist, warum passiert das? Zuvor hatte ich "sudo killall -HUP mDNSResponder" vergeblich versucht, aber ich hatte die anderen Befehle nicht ausgeführt. Ich kann nur die ersten drei ausprobieren und sehen, ob das das Problem löst. Wenn es die beiden Befehle erfordert, die auf Homebrew verweisen, könnte Homebrew das Problem sein?

Ich bin mir sicher, dass ich eine andere Gelegenheit haben werde, dies weiter zu überprüfen.

Nochmals vielen Dank an @user674669!

Aktualisierung 26.08.2021:

Problem erneut aufgetreten. Nur die ersten drei Befehle ausgeführt:

 dscacheutil -flushcache;
 sudo killall -HUP mDNSResponder
 sudo killall -9 mDNSResponder mDNSResponderHelper

...getestete Verbindung nach jedem. Scheint alle drei zu erfordern, löst das Problem nicht vollständig, stellt nur die DNS-Funktionalität wieder her, bis es erneut auftritt.
Das eigentliche Problem bleibt immer noch ... warum passiert das?

Und sorry, ich bin hier vielleicht ein Neuling, aber ich bin auch Analytiker und das schon seit Jahren. Ich glaube, dass meine geposteten Antworten für dieses Thema relevant sind. Niemand hier hat eine definitive schlüssige Lösung für dieses Problem gefunden. Und ich verweise auf eine andere (aber auch gleiche) Antwort in Bezug auf die Person (@user674669), die die Schritte bereitgestellt hat, mit denen ich teilweise helfen konnte (da das Problem zu einem späteren Zeitpunkt erneut auftritt), das Problem zu lösen. Und mit diesem Update habe ich festgestellt, dass nicht alle von @user674669 geposteten Schritte erforderlich sind (zumindest in meinem Fall), um die DNS-Funktionalität wiederherzustellen. Ich glaube, meine Kommentare sind hilfreich für andere, die das gleiche Problem haben.

LThibx

2022 und habe dieses Problem.

nslookup & dig gab die korrekten DNS-Werte zurück, aber ping und ssh an das beabsichtigte Gerät gaben nur die öffentliche IP meiner Domain zurück.

In meinem Fall musste ich mein DNS-Profil und "die Verfolgung der IP-Adresse beschränken" im Pref-Fenster der Netzwerkeinstellungen deaktivieren.

Jetzt funktioniert alles richtig und Suchdomains funktionieren richtig.

Nach dem Upgrade von Snow Leopard auf einem alten Mac Book auf Mountain Lion konnte das System DNS nicht auflösen. Spülen, neu starten, nichts half. Das Wechseln von WiFi zu einem anderen Zugangspunkt (mein 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. Wenn Sie es leer ließen, kam nichts durch, obwohl die WLAN-Verbindung scheinbar erfolgreich war.