DNS не разрешается в Mac OS X

Некоторые из моих коллег испытывают проблемы на своих Mac - разрешение DNS не работает под Mac OS X. Они работают под управлением Snow Leopard 10.6.8. Они могут использовать DNS на виртуальной машине Windows 7 (VMware Fusion 3.1.3), работающей под OS X. Компьютеры - это 15-дюймовый MacBook Pro, модель начала 2011 года.

То, что они пробовали, не сработало:

• включение / выключение аэропорта
• перезагрузка
• используя проводное соединение вместо Wi-Fi
• удаление учетных данных подключения и добавление их снова
• отключение брандмауэра Mac
• используя фиксированный статический IP
• настройка DNS-серверов вручную
• перезапуск mDNSResponder
• исправления из этого другого вопроса

РЕДАКТИРОВАТЬ ответ Мартин ответ:

• Можете ли вы пропинговать DNS, который хотите использовать?

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

• Какой IP-адрес (а) DNS (а) вы хотите использовать?

Это DNS-сервер компании, который предоставляется с DHCP, он хорошо работает для других людей. Я также попробовал Google 8.8.4.4 и 205.171.3.65 (который я нашел из DNS Benchmark GRC, чтобы быть самым быстрым).

• Вы пытались использовать 8.8.8.8 (Google) или любой из OpenDNS 208.67.222.222 или 208.67.220.220?

Это не работает, смотрите вывод Google Chrome:

Не удается найти сервер на сайте www.apple.com, поскольку поиск DNS не удался. DNS - это сетевая служба, которая переводит имя веб-сайта в его интернет-адрес. Эта ошибка чаще всего вызвана отсутствием подключения к Интернету или неправильно настроенной сетью. Это также может быть вызвано не отвечающим DNS-сервером или брандмауэром, препятствующим доступу Google Chrome к сети.

• Можете ли вы пинговать этих хостов?

$ 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

• создание пустого пользователя

Учетная запись гостя была создана, проблема DNS все еще существовала при использовании гостевой учетной записи.

• nslookup и копать оба работают нормально

$ 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

• также была выполнена очистка кеша DNS, но это не помогло

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

РЕДАКТИРОВАТЬ 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

Оказывается, решение было отказов mDNSResponder:

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

Это было получено другим коллегой из этого вопроса о сбое сервера .

OS X 10.10.0 - 10.10.3, Йосемити

По-видимому , mDNSResponder не существует в Yosemite (OS X 10.10). Вместо этого вы можете перезапустить descoveryd, чтобы устранить эти проблемы.

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+, Йосемити

В OSX 10.10.4 mDNSResponder был вновь введен . Так что использование первого снова будет работать.

На самом деле, я думаю, что вы можете использовать

scutil --dns

scutil -r hostname

Эти команды используют динамическое хранилище в configd, в отличие от плоских файлов в / etc, которые часто читаются только в однопользовательском режиме и для не сетевых систем.

man scutil   # or

scutil --help  

Я столкнулся с той же проблемой ... И хотя перезапуск mDNSResponder, похоже, "работает", перезапускать его пару раз в час - это отстой.

Итак, на данный момент я «решил» проблему, запустив dnsmasq локально. Для этого:

• Сборка dnsmasq (скачать тгз и makeили brew install dnsmasq)

• Поместите это в dnsmasq.confфайл:

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

• Поместите это в resolv.confфайл, который находится в том же каталоге, что и dnsmasq.confфайл (nb: not /etc/resolv.conf ):

  nameserver 8.8.8.8
  nameserver 4.2.2.1
  nameserver 4.2.2.2
  

• Беги dnsmasqс sudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf. Вывод должен выглядеть примерно так:

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

• Откройте «Сетевые настройки» и убедитесь, что 127.0.0.1это единственный DNS-сервер (сетевые настройки -> «Дополнительно» -> DNS -> добавить 127.0.0.1).

Все должно начать работать снова хорошо.

После того, как все заработает, вы можете работать dnsmasqбез параметров --no-daemonи --log-queries, поэтому он будет запускаться в фоновом режиме, и вам не нужно держать окно терминала открытым.

Разрешение имен в OSX (и UNIX в целом) берется из IP-адресов DNS в файле, расположенном в /etc/resolv.conf (который OS X генерирует автоматически, насколько я помню).

Поскольку вы попробовали практически все, что приходит мне в голову, я хотел бы спросить вас:

• Можете ли вы пропинговать DNS, который хотите использовать?
• Какой IP-адрес (а) DNS (а) вы хотите использовать?
• Вы пытались использовать 8.8.8.8 (Google) или любой из OpenDNS 208.67.222.222 или 208.67.220.220?
• Можете ли вы пинговать этих хостов?

Наконец, обычно хороший тест состоит в создании пустого пользователя и проверке того, имеет ли этот новый пользователь ту же проблему. Если это не так, то вы можете начать копать то, что у вашего текущего пользователя может быть причиной проблемы; если это также не помогает, то вы знаете, что это нечто более «системное».

Также осмотрите консоль, чтобы увидеть, можете ли вы найти что-то, что может быть связано (и хотели бы вставить сюда).

И последнее, но не менее важное: ваш Mac поставляется с двумя важными командами DNS nslookupи dig.

Таким образом, чтобы разрешить www.apple.com с помощью сервера Google, вы должны набрать:

nslookup "хост для разрешения" "DNS-сервер для использования". Например:

$ 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 - старая команда (которая должна была быть устаревшей несколько лет назад и заменена на DIG, но ее простой в использовании синтаксис был слишком хорош, чтобы ее убивать, я думаю), ее «замена» - digгораздо более мощная команда, синтаксис которой более сумасшедший

Чтобы выполнить тот же запрос, вы должны набрать:

копать 8.8.8.8 www.apple.com

И вот вывод:

$ 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

Как вы можете видеть, dig гораздо более "многословен" (что хорошо для отладки того, что происходит, черт возьми). Сила копания заключается в том, что вы можете указать, какой тип запроса вы хотите выполнить (среди прочего).

В любом случае, дайте нам знать точные результаты этих команд.

У меня были те же самые симптомы (и я потратил некоторое время на устранение неисправностей), но я смог их устранить, когда понял, что я испортил /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistи то, что я сделал, было как-то интерпретировано как неправильно сформированное. Я восстановился из резервной копии, и машина снова смогла разрешить имена хостов.

Прежде чем перейти к решению, я также понял, что смогу просматривать Интернет, если использовал прокси-сервер SOCKS5 ssh -Dи пробовал поиск DNS через туннель.

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

Мой пользователь не смог разрешить ни одного имени (локальное NAS, Google и т. Д.), Но гостевой пользователь на том же iMac (OS X 10.7.4) работал нормально.

Промывка и перезапуск mDNSResponder, как уже упоминалось, работали некоторое время. Хотя он будет работать, когда iMac переведен в спящий режим, он всегда будет выходить из строя после перезагрузки.

Когда сброс / перезапуск перестал работать, я искал другие причины / решения и обнаружил, что это связано с моим брандмауэром. Я не знаю, что в моих настройках брандмауэра (OS X) вызывало это, но если я восстановил настройки брандмауэра, это сработало.

Для восстановления настроек по умолчанию я использовал:

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

Очевидно, что любые пользовательские правила будут удалены с этим восстановлением.

Я хотел поделиться своей версией этой проблемы, так как она месяцами вызывает у меня горе и эта публикация - лучшая коллекция возможных решений в сети!

Я столкнулся с этой проблемой на Йосемити (10.10). Оказывается, что ключевой демон, discoverydбыл убит, поскольку он потреблял слишком много ресурсов процессора.

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 

Как ни странно, перезагрузка не привела к перезапуску.

Я вручную перезапустил сервис с:

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

и сейчас все хорошо.

У меня такая же проблема с 10.6.8. Первая поездка в Apple Store привела к восстановлению системы. Но после этого DNS снова сломался, когда я был за границей, и у меня не было системного DVD. В то время я нашел эту /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistветку и удалил по @freezedpeanuts и @Tom Thorogood.

Это решило проблему, но, что удивительно, DNS сломался в третий раз пару дней спустя. Я нашел системный образ 10.6.3 и:

1. Скопировано /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistиз образа системы.
2. sudo chown root /System/Library/LaunchDaemons/com.apple.mDNS*
3. Rebooted

Это решило проблему.

Сейчас он периодически выходит из строя (раз в месяц или около того), и процедура восстановления идет до описанных выше шагов, за исключением того, что вместо перезагрузки вы можете:

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

Обратите внимание, что всем, у кого все еще есть проблемы, возможно, придется удалить все публичные DNS-серверы, пока кэш не будет очищен.

У меня была такая же проблема, как у ОП. Используя инструмент networksetup, я обнаружил, что для заданного имени сети был настроен неправильный DNS:

networksetup -getdnsservers <networkname>

перечислил 192.168.0.1 как DNS. Используя scutil --dns, я получил сравнимые результаты, перечислив, что распознаватель # 2 использовал nameserver [0]: 192.168.0.1.

Используя команду

networksetup -setdnsservers <networkname> 192.168.188.1 8.8.8.8

Мне удалось перенастроить DNS для данной сети и разрешить имена локальных и глобальных машин при подключении к VPN.

Это, вероятно, никому не поможет, но на случай, если я случайно некоторое время назад создал файл в папке, когда DNS не работал для определенного домена:

/ И т.д. / резольвера /

и это препятствовало тому, чтобы определенное имя когда-либо было решено, два года спустя.

В моем случае все остальное было в порядке: mDNSResponder работал и работал host/ nslookupработал, /etc/resolv.confи networksetupсообщал о правильных DNS-серверах и т. Д. Несмотря на все это, разрешение DNS в целом (например, с ping) неизбежно перестало работать в какой-то момент через несколько часов после загрузки.

Эта конкретная проблема может быть несколько маловероятной, но я все равно опишу ее здесь как ответ.

Я заметил только, когда машина начала замедляться, но было запущено много одинаковых процессов . sensu-clientконкретно.

Мы запустили его в launchd с этим файлом plist:

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

-bФлаг sensu-clientделает его раскошелиться на задний план, действующий в качестве демона. Однако все launchdвидят, что исходный процесс завершен, поэтому (в соответствии с KeepAliveфлагом) он перезапускает его. Это оставляет тысячи разветвленных процессов в фоновом режиме, и даже тогда launchd не будет мудрее того факта, что он запущен.

Я полагаю, что эти несколько тысяч процессов (все sensu-client, программное обеспечение, для которого мы написали конфигурацию launchd), возможно, одновременно делали запросы к mDNSResponder, эффективно приводя к локальному отказу в обслуживании кэша DNS . Уничтожение этих процессов и исправление списка, предоставленного launchd, в конечном итоге решили проблему.

Исправление -bplist заключалось в удалении флага (background / daemonise) из вызова sensu-client. Обратите внимание, что это не вина Сенсу; этот список был написан бывшим системным администратором в этой компании.

Вот несколько расширенных команд, которые могут помочь решить проблему DNS:

• Запустите digсписок корневых серверов имен.
• Запустите dig example.comдля запуска поиска DNS для example.comдомена.
• Перечислите ваши аппаратные порты на: networksetup -listallhardwareports.
• Проверьте выход DHCP / BOOTP пакета, клиент принятого от сервера DHCP / BOOTP по: ipconfig getpacket en0.
• Проверьте конфигурацию DNS с помощью: scutil --dns.
• Убедитесь в том, что mDNSResponderпроцесс запущен с помощью: ps wuax | grep mDNSResponder.
• Очистите записи перевода ARP: arp -ad(запустите man arpдля помощи). ^{источник}

Для отладки mDNSResponderпроцесса может помочь следующая команда:

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

Приведенная выше команда отправит SIGINFOсигнал процессу, который выведет подробности отладки в вывод журнала, который можно прочитать и проанализировать.

Помогло выключение и повторное включение Wi-Fi.

^{MacBook Pro с 10.9.1}

Особенно, если вы выключите Wi-Fi, а затем перезагрузите компьютер. Дополнительная задержка и запуск без подключения к IP / сети гарантируют, что запрос на повторное подключение к сети имеет больше шансов на успех.

К сожалению, ничего из этого не помогло мне, и оказалось, что после часа попыток понять это и ударить меня головой о журнальный столик ... что-то, как-то, где-то ... удалило /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistфайл, и это было причиной, по которой у меня возникла эта проблема.

Понял это, когда увидел это сообщение об ошибке: /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist: No such file or directory

Вот копия версии от El Capitan: https://gist.github.com/tripflex/e7147690d1768dc74b1dd626614573c0

Вот код из этой сущности:

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

Как выясняется, для решения проблемы необходимо настроить поисковый домен и добавить его в поле поискового домена в разделе «Системные настройки». По сути, поисковый домен будет работать так же, как и .local, но вместо этого будет.

Вы должны настроить свой поисковый домен в качестве главной зоны на вашем DNS-сервере, чтобы это работало.

У меня похожая проблема с поиском хост-сервера. У нас есть 21 iMac, запущенных с Сервера (El Capitan, недавно обновленный), и только один не будет связываться. Исправление обычно довольно просто с помощью пользователей и групп в SysPref. Удаление хост-сервера и повторная привязка, поиск доступного сервера в раскрывающемся списке, но по неизвестной причине сервер указан в списке unkown-00-00-12-34-56-78.home, который, как я обнаружил, является MAC-адресом сервера. Я запустил это в терминале:

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

а также

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

вернулся к привязке к серверу в SysPref, и на короткое время появилась правильная опция имени сервера, а затем изменилась обратно на «unkown-00-00-12-34-56-78.home» прямо на моих глазах!

При выполнении следующих команд из принятого ответа:

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

Вы можете столкнуться с предупреждением:

Операция не разрешена, когда включена защита целостности системы

Вы должны выключить его. Вся инструкция здесь: https://www.howtogeek.com/230424/how-to-disable-system-integrity-protection-on-a-mac-and-why-you-shouldnt/

В моем случае в прошлом у меня был установлен OpenDNS, и он не был удален чисто. Было запущено несколько связанных с DNS процессов, таких как DNSdnscrypt-proxy. Я не смог принудительно закрыть их в Activity Monitor, но я смог остановить их запуск при перезапуске, удалив файл .plist в Library / LaunchDaemons.

Зайдите в Настройки -> Сеть -> Дополнительно -> DNS. Затем внесите буквально любые изменения в DNS (измените порядок записей DNS, например). Затем нажмите «ОК», затем «Применить» на следующем экране. Не думайте, что внесенные вами изменения были значительными; это магия кнопки «Применить».

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

Для меня сработало удаление всех записей сервера с DNS-серверов и поисковых доменов из:

Системные настройки → Сеть → Дополнительно ... → DNS

После обновления со Snow Leopard на старой Mac Book до Mountain Lion система не смогла разрешить DNS. Промывка, перезагрузка, ничего не помогло. Помогло переключение WiFi на другую точку доступа (мой телефон).

Mountain Lion добавляет новое поле клиента в настройки сети DHCP. Заполнение этого поля, казалось, сделало точку доступа Wi-Fi счастливой. Если оставить это поле пустым, значит ничего не получится, хотя подключение к Wi-Fi, похоже, будет успешным.