Устранение неполадок DNS

У меня странная проблема, когда общесистемное разрешение DNS не работает, но я не знаю, как мне это исправить или даже найти журнал (исходящий из Linux). Я вручную настроил 8.8.8.8, 8.8.4.4 как DNS-серверы в графическом интерфейсе, который, кажется, принял:

$ 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

Однако, когда система пытается разрешить имя, она терпит неудачу по таймауту, это не влияет только на какое-то программное обеспечение, например Chrome, которое не использует системный преобразователь:

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

$ scutil -r google.com
Not Reachable

Они могут быть запрошены вручную:

$ 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)

И результаты действительны:

$ 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

Мой файл hosts не содержит ничего удивительного:

$ 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

Запрос новой аренды DHCP тоже ничего не сделал. Сброс серверов ничего не меняет:

$ 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

Журналы, доступные в Console.app, в основном показывают приложения, жалующиеся на тайм-ауты (я думаю, что это особенно странно: разрешение не сразу сбой, потому что нет доступного сервера, но всегда происходит сбой с тайм-аутом, как будто он пытается достичь их, но не может?)

В отличие от Linux, dig / nslookup не использует системный преобразователь, который используют все другие приложения / службы. Есть ли инструмент, который использует системный преобразователь и имеет несколько опций, чтобы сказать мне, что не так?

Я не знаю, что может вызвать такую ​​проблему, но я могу дать вам несколько советов по устранению неполадок.

• Во-первых, попробуйте выполнить ручной запрос к 8.8.4.4 ( dig google.com @8.8.4.4) - dig, nslookupи hostвсе, кажется, используют первый перечисленный сервер, но системный распознаватель использует странную систему циклического перебора, которая будет прерываться периодически, если некоторые из настроенных DNS-серверы не работают правильно. Точно так же вы можете попробовать настроить ОС на использование только 8.8.8.8 и посмотреть, изменит ли это что-нибудь.

• Говоря о преобразователе системы, возможно, он попал в какое-то странное состояние, поэтому его перезапуск может решить проблему. На самом деле, я бы сбросил оба opendirectoryd(который отправляет все виды поиска) и mDNSResponder(который на самом деле делает часть DNS), на всякий случай. sudo killall opendirectoryd mDNSResolverдолжен сделать свое дело. Обратите внимание, что оба демона будут перезапущены автоматически.

• Вы можете получить больше информации, mDNSResponderотправив ему сигналы. Вероятно, наиболее полезной является функция регистрации пакетов, которая позволяет регистрировать каждый DNS-пакет, отправленный и полученный в /var/log/system.log. Вы можете включить и выключить его с помощью sudo killall -USR2 mDNSResponder. Записи в журнале должны выглядеть примерно так (для успешного поиска):

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

  Вы также можете послать ему USR1сигнал, чтобы включить ведение журнала отладки (что, кажется, требует, чтобы вы знали много о внутренностях mDNSResponder, чтобы иметь смысл), и INFOсигнал заставляет его сбросить свое внутреннее состояние в системный журнал (вероятно, информативный, но много информации для сортировки).