DNS wird unter Mac OS X nicht aufgelöst


101

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

Passiert auch für mich am Löwen.
Dkagedal

Passiert für mich auf Mavericks, 10.9.4
greg7gkb

Dies scheint ein historisches Problem zu sein, das das Leben von Benutzern und Netzwerkadministratoren von Leopard bis Yosemite ruiniert hat. Wenn dieses Problem weiterhin auftritt, melden Sie dies bitte deutlich, wenn Sie mehr als eine aktive Schnittstelle haben und außerdem deren Konf. Erhalten. von einem DHCP-Server (von verschiedenen Seiten). Warum? Ich habe auf keinem anderen Unix und keinem meiner Macs (ich habe viele) ein solches Problem gesehen, aber keiner von ihnen hat mehr als eine Schnittstelle, die mit einer DNS-Informationsquelle kommuniziert.
Dan

Versuchen Sie, Ihre DNS-Konfiguration zu ändern (Reihenfolge ändern oder Einträge entfernen), um das gleiche Problem für mich zu
beheben

Antworten:


91

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.


5
Dies ist jedoch keine wirklich zufriedenstellende Antwort. Ich muss wissen, wie ich das verhindern kann.
dkagedal

1
@dkagedal Dies ist eigentlich eine so gute Antwort, wie wir sie erhalten werden. Dies geschieht, weil Ihr Mac die DNS-Einträge zwischenspeichert, um zu vermeiden, dass Ihr DNS-Server (wahrscheinlich Ihr Router) bei jeder DNS-Suche verletzt wird - was häufig vorkommt. Dieser Cache ist notwendig und gut, aber es wäre schön, wenn es ein besseres Verhalten gäbe, wenn ein Eintrag nicht gefunden würde (ich halte dies für einen Fehler). In jedem Fall ist eine Zeitüberschreitung im Cache aufgetreten. Als ich ungefähr 10 Minuten auf meinem Computer gewartet habe, hat sich diese Situation von selbst gelöst. Für die Mehrheit der Benutzer ist das vorhandene Verhalten in Ordnung, sodass es wahrscheinlich nicht so bald von Apple geändert wird.
Matt,

2
Das ist natürlich nicht so gut wie es nur geht. Kein anderes Betriebssystem hat dieses Problem. Es ist nichts falsch mit dem DNS, der Eintrag für www.google.com ist nicht verloren gegangen, es ist nur der MacOS-Cache, der ihn irgendwie verloren hat und nicht erneut abruft. Und das ist ein Fehler, der behoben werden muss.
dkagedal

1
Habe dieses Problem auf 10.9 und die Lösung hat einwandfrei funktioniert. In meinem Fall wurde DNS für vollständige Namen aufgelöst, aber nicht für kurze.
Sorin

1
@ Matteo Möglicherweise muss die Datei nicht vorhanden sein, oder die Antwort muss für Yosemite aktualisiert werden. Haben Sie dieses Problem? Behebt das Ausführen dieser Befehle das Problem?
CajunLuke

10

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  

3
Sie erklären nicht, warum diese Befehle bei diesem Problem helfen würden. Sogar? Oder bedeutete dies als Kommentar zu einer der anderen Antworten oder so?
dkagedal

Ein möglicher Vorteil von scutil ist, dass es möglicherweise funktioniert, unabhängig davon, ob der Computer Discoveryd oder mDNSResponder hat. Es stammt aus der Zeit vor ihrer Einführung.
DA Vincent

1
Diese Befehle lösen das Problem nicht
Radu Simionescu

7

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.


Siehe meine Bearbeitung zu der Frage.
CajunLuke

@CajunLuke hmmmm interessant ... Ich habe etwas dagegen, die Ausgabe von: cat /etc/resolv.conf zu Ihrer Frage hinzuzufügen?
Martin Marconcini

Bearbeitet (Polsterung, damit der Kommentar passt.)
CajunLuke

@ CajunLuke Ich bin verwirrt. Kehren wir zu den Wurzeln zurück. Dies geschieht nur auf diesem Computer, und nur unter OSX sind die VMs in Ordnung. Ich beginne zu vermuten, dass Parallels oder VMware Probleme verursachen könnten. Welche Art von Netzwerk verwenden diese VMs? Überbrückt? Geteilt?
Martin Marconcini

1
Oder wenn Sie wirklich kurz wollen, können Sie immer ... dig + short a apple.com ...
Pryftan

7

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 möchte nur darauf hinweisen, dass dies die einzige Lösung ist, die ich nach 16 Stunden Durchsuchen des Internets gefunden habe. Mit beiden kann ich interne Firmennamen auflösen UND Split-Netzwerke können ordnungsgemäß funktionieren. Vielen Dank für diesen Kommentar.
Ron Thompson

Ich möchte auch darauf hinweisen, dass ich unter OS X El Capitan, um dieses Skript einzurichten, meinen openconnectBefehl zusammen mit Befehlen wie networksetup -setdnsservers 127.0.0.1und in ein Python-Skript eingebunden habe networksetup -setsearchdomains "$COMPANY_NAME".com. Fügen Sie in Ihrem dnsmasqBefehl und es ist alles eingestellt! Dank dieses Kommentars habe ich endlich eine stabile VPN-Lösung.
Ron Thompson

Für zukünftige Leser war es am einfachsten, bei der Arbeit einfach in meine Box zu sshen, festzustellen, welche IP-Adressen für Nameserver vorhanden waren, und diese IP-Adressen dann in meine resolv.conf unter 8.8.8.8 (googles DNS-Server) festzukodieren. Auf diese Weise können alle Nicht-Firmennamen ordnungsgemäß aufgelöst werden, ohne dass Firmenserver durchsucht werden müssen. Dies ist aus Gründen des Datenschutzes und der Geschwindigkeit hilfreich. Was die Hardcodierung angeht, werden sich diese IP-Adressen in Kürze nicht mehr ändern. In diesem Fall bin ich nicht der einzige Betroffene, und es sollte trivial sein, zwei Zeilen zu bearbeiten.
Ron Thompson

Es heißt, dass die Adresse 127.0.0.1 bereits verwendet wird, wenn ich versuche, dnsmasq zu starten. Was muss ich tun? High Sierra
IceFire

@IceFire Ich weiß, dass dies alt ist, aber das bedeutet, dass an diesem Port bereits ein Dienst gebunden ist (53). Technisch bedeutet das, dass der Fehler EADDRINUSE angezeigt wird, aber ich werde nicht hingehen :) Was diese Antwort betrifft , finde ich sie faszinierend. Ich habe ein ähnliches Problem, aber ich denke (hoffe), dass die andere Antwort es nur lösen wird, dass ich es zumindest für mein Heimnetzwerk nicht aktivieren muss, da ich meine eigenen autorisierenden DNS-Server habe (und einer davon ist zufällig) lokal und was ich benutze). Otoh als langjähriger Unix-Benutzer ist die Tatsache, dass ich /etc/resolv.conf verwenden könnte, ansprechend, aber ich werde es zuerst mit dem anderen versuchen.
Pryftan

6

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.


1
Mein Unternehmen hat dieses Problem seit Monaten und Monaten und brachte Macs jedes Mal in die "Genius Bar", deren einzige Lösung darin bestand, die Festplatten zu löschen und von vorne zu beginnen. Ich habe Ihren Beitrag gesehen und com.apple.mDNSResponder.plist gelöscht, neu gestartet und das Problem wurde behoben. Ich wünschte, ich könnte dich eine Milliarde Mal unterstützen.
Thomas Thorogood

1
Merke Löschen com.apple.mDNSResponder.plist! Ich habe es getan, wie @TomThorogood vorgeschlagen hat. Es fällt mir schwer, wiederzukommen. Obwohl ich die Datei zurückgesetzt und neu gestartet habe, konnte ich keine Antwort vom Internet erhalten. Das hat dann sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistgeholfen.
Pavel Binar

5

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!


4

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.


1
Dies war die Lösung für mich auch auf Yosemite. Einige Details: Host, Dig und Chrome funktionierten einwandfrei, aber Ping, Telnet, SSH, Firefox und Safari konnten Hostnamen nicht auflösen. Diese Lösung hat mein Problem behoben.
Ryan Hoegg

Ärgerlich, das passiert mir die ganze Zeit. Müssen Sie den Dienst neu starten.
Callum Rogers

2

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


2

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


1
Vielleicht sollten wir support.apple.com/de-au/HT203244 erwähnen .
DA Vincent

@DAVincent Ein paar Jahre zu spät, aber dieser Link ist enttäuschend. Es ist eindeutig ein Apple-Fehler, aber sie führen ihn auf einen Benutzerfehler zurück.
weberc2

2

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.


2

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.


2

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.


1

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.


1
Obwohl die Frage möglicherweise etwas bearbeitet werden muss, heißt es (zum Zeitpunkt des Schreibens dieses Kommentars) immer noch, dass die Mitarbeiter bereits versucht haben, WLAN aus- und wieder einzuschalten. Vielleicht könnten wir diese Antwort zurückziehen?
DA Vincent

Ich habe nicht genug Reputation, um einem Post einen Kommentar zum Ein- und Ausschalten von WLAN hinzuzufügen, aber das hat bei mir funktioniert. Die Antwort zurückzuziehen wäre dumm.

+1 für den Vorschlag, es erneut zu versuchen. Mehrere Antworten helfen vielen Menschen, und jeder Router hat unterschiedliche Timeouts und Verhaltensweisen.
bmike

1

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.


Vielen Dank, das war mein Problem. Ich habe stundenlang das Debuggen, und wenn ich in sah / etc / Resolver ich natürlich finde eine Datei „Test“ genannt, mit den falsch empfangenen IP - Adressen ...
keyser

1

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>

0

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.


0

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!


0

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/


0

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.


0

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

0

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

Systemeinstellungen → Netzwerk → Erweitert ... → DNS


-1

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.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.