Problembehandlung bei DNS

Ich habe ein seltsames Problem, bei dem die systemweite DNS-Auflösung nicht funktioniert, aber ich weiß nicht, wie ich das beheben oder sogar ein Protokoll finden kann (von Linux). Ich habe 8.8.8.8, 8.8.4.4 manuell als DNS-Server in der GUI konfiguriert, was genommen zu haben scheint:

$ scutil --dns
DNS configuration

resolver #1
  search domain[0] : Home
  nameserver[0] : 8.8.8.8
  nameserver[1] : 8.8.4.4
  flags    : Request A records
  reach    : Reachable

DNS configuration (for scoped queries)

resolver #1
  search domain[0] : Home
  nameserver[0] : 8.8.8.8
  nameserver[1] : 8.8.4.4
  if_index : 4 (en0)
  flags    : Scoped, Request A records
  reach    : Reachable

Wenn das System jedoch versucht, einen Namen aufzulösen, schlägt dies mit einer Zeitüberschreitung fehl. Nur einige Programme, z. B. Chrome, das den Systemauflöser nicht verwendet, sind davon nicht betroffen:

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

$ scutil -r google.com
Not Reachable

Sie können manuell abgefragt werden:

$ nslookup google.com
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:   google.com
Address: 2.127.237.183
...

$ dig google.com
google.com.     50  IN  A   2.127.237.183
;; Query time: 226 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)

Und die Ergebnisse sind gültig:

$ ping 2.127.237.183
64 bytes from 2.127.237.183: icmp_seq=0 ttl=60 time=37.086 ms

$ scutil -r 2.127.237.183
Reachable

Meine hosts-Datei enthält nichts Überraschendes:

$ cat /etc/hosts
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1   localhost
255.255.255.255 broadcasthost
::1             localhost

Das Anfordern einer neuen DHCP-Lease hat ebenfalls nichts bewirkt. Das Zurücksetzen der Server ändert nichts:

$ networksetup -getinfo Wi-Fi
DHCP Configuration
IP address: 192.168.0.2
Subnet mask: 255.255.255.0
Router: 192.168.0.1
Client ID:
IPv6: Automatic
IPv6 IP address: none
IPv6 Router: none

$ networksetup -setdnsservers Wi-Fi Empty

$ scutil --dns
DNS configuration

resolver #1
  search domain[0] : Home
  nameserver[0] : 192.168.0.1
  if_index : 4 (en0)
  flags    : Request A records
  reach    : Reachable,Directly Reachable Address

DNS configuration (for scoped queries)

resolver #1
  search domain[0] : Home
  nameserver[0] : 192.168.0.1
  if_index : 4 (en0)
  flags    : Scoped, Request A records
  reach    : Reachable,Directly Reachable Address

$ scutil -r google.com
Not Reachable

Die in Console.app verfügbaren Protokolle zeigen hauptsächlich Apps, die sich über Zeitüberschreitungen beschweren (ich finde das besonders seltsam: Die Auflösung schlägt nicht sofort fehl, da kein Server verfügbar ist, aber sie schlägt immer mit einer Zeitüberschreitung fehl, als würde sie versucht, diese zu erreichen, aber kippen?)

Im Gegensatz zu Linux scheint dig / nslookup nicht den System-Resolver zu verwenden, den alle anderen Apps / Dienste verwenden. Gibt es ein Tool, das den System-Resolver verwendet und über einige Optionen verfügt, mit denen ich feststellen kann, was nicht stimmt?

Ich weiß nicht, was ein solches Problem verursachen könnte, aber ich kann Ihnen einige Hinweise zur Fehlerbehebung geben.

• Versuchen Sie zunächst, eine manuelle Abfrage für 8.8.4.4 ( dig google.com @8.8.4.4) - dig, durchzuführen nslookup, und hostalle scheinen den ersten aufgelisteten Server zu verwenden, aber der System-Resolver verwendet ein seltsames Round-Robin-System, das zeitweise fehlschlägt, wenn einige der konfigurierten Server fehlerhaft sind DNS-Server funktionieren nicht richtig. Ebenso könnten Sie versuchen, das Betriebssystem so zu konfigurieren, dass es nur 8.8.8.8 verwendet, und prüfen, ob sich dadurch etwas ändert.

• Apropos System-Resolver, es ist möglich, dass es in einen seltsamen Zustand geraten ist, so dass ein Neustart das Problem beheben kann. Eigentlich würde ich sowohl zurücksetzen opendirectoryd(was alle Arten von Lookups auslöst) als auch mDNSResponder(was tatsächlich den DNS-Teil erledigt), nur für den Fall. sudo killall opendirectoryd mDNSResolversollte den Trick machen. Beachten Sie, dass beide Daemons automatisch neu gestartet werden.

• Sie können mehr Informationen heraus erhalten, mDNSResponderindem Sie es Signale senden. Am nützlichsten ist wahrscheinlich die Paketprotokollierungsfunktion, mit der jedes an /var/log/system.log gesendete und empfangene DNS-Paket protokolliert wird. Sie können es mit ein- und ausschalten sudo killall -USR2 mDNSResponder. Die Protokolleinträge sollten ungefähr so ​​aussehen (für eine erfolgreiche Suche also):

  -- Sent UDP DNS Query (flags 0100) RCODE: NoErr (0) RD ID: 28215 25 bytes from port 61186 to 172.20.0.1:53 --
   1 Questions
   0 scanme.insecure.net. Addr
   0 Answers
   0 Authorities
   0 Additionals
  --------------
  -- Received UDP DNS Response (flags 8180) RCODE: NoErr (0) RD RA ID: 28215 272 bytes from 172.20.0.1:53 to 172.20.6.67:61186 --
   1 Questions
   0 scanme.insecure.net. Addr
   1 Answers
   0 TTL    3600    4 scanme.insecure.net. Addr 5.45.96.131
   4 Authorities
   0 TTL   86400   17 insecure.net. NS ns3.eurodns.com.
   1 TTL   86400   17 insecure.net. NS ns2.eurodns.com.
   2 TTL   86400   17 insecure.net. NS ns4.eurodns.com.
   3 TTL   86400   17 insecure.net. NS ns1.eurodns.com.
   7 Additionals
   0 TTL    3600    4 ns1.eurodns.com. Addr 80.92.65.2
   1 TTL    3600   16 ns1.eurodns.com. AAAA 2001:0B20:1001:0004:0000:0000:0000:0002
   2 TTL    3600    4 ns2.eurodns.com. Addr 80.92.89.242
   3 TTL    3600   16 ns2.eurodns.com. AAAA 2001:0B20:1001:0011:0000:0000:0000:0242
   4 TTL     600    4 ns3.eurodns.com. Addr 80.92.95.42
   5 TTL    3600    4 ns4.eurodns.com. Addr 192.174.68.100
   6 TTL    3600   16 ns4.eurodns.com. AAAA 2001:067C:01BC:0000:0000:0000:0000:0100
  --------------
  

  Sie können ihm auch ein USR1Signal senden , um die Debug-Protokollierung zu aktivieren (was anscheinend erfordert, dass Sie viel über die Interna von mDNSResponder wissen, um einen Sinn daraus zu ziehen), und das INFOSignal veranlasst ihn, seinen internen Status in das Systemprotokoll zu schreiben (wahrscheinlich informativ, aber sehr umfangreich) Informationen zum Durchsuchen).