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

Оказывается, решение заключалось в отказе 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 (скачайте tgz и makeили brew install dnsmasq)

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

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

• Поместите это в resolv.confфайл, который находится в том же каталоге, что и dnsmasq.confфайл (примечание: не /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 гораздо более «многословен» (что хорошо для отладки того, что, черт возьми, происходит). Сила 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

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

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

Я столкнулся с этой проблемой на Yosemite (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. Перезагрузка

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

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

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 использовал сервер имен [0]: 192.168.0.1.

С помощью команды

networksetup -setdnsservers <networkname> 192.168.188.1 8.8.8.8

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

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

^{Макбук Про с 10.9.1}

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

Это, наверное, никому не поможет, но на случай, если я случайно некоторое время назад создал файл в папке, когда 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>

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

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

Исправление plist заключалось в том, чтобы просто удалить -bфлаг (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сигнал процессу, который выведет детали отладки в вывод журнала, который можно прочитать и проанализировать.

К сожалению ничего из этого мне не помогло, и оказалось после часа попыток разобраться и биться головой об журнальный столик.. что-то, как-то, где-то... удалил /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>

Перезапуск DNSResponder/очистка кеша DNS в macOS Mojave:

sudo killall -HUP mDNSResponder

Никаких проблем с защитой целостности системы, в отличие от перезагрузки файлов конфигурации.

В моем случае основная причина заключалась в том, что система защиты от DoS-атак моего домашнего WiFi-роутера ошибочно добавила MAC-адрес моего устройства macOS в черный список. После ручной очистки черного списка и выполнения sudo killall -HUP mDNSResponderкоманд dig, ping и traceroute все работает хорошо.

В Mac OS Mojave 10.14.6 я недавно начал наблюдать частые сбои поиска DNS. У меня есть эта функция в моем .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
}

При запуске

$ resetdns

Поиск DNS снова начал работать нормально.

Как оказалось, для решения проблемы вам нужно настроить поисковый домен и добавить его в поле поискового домена в Системных настройках DNS. По сути, поисковый домен будет работать примерно так же, как .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, и на короткое время появилась правильная опция имени сервера, а затем изменилась обратно на «unown-00-00-12-34-56-78.home» прямо на моих глазах!

В моем случае у меня был установлен OpenDNS в прошлом, и он не был удален полностью. Было запущено несколько процессов, связанных с DNS, таких как DNSdnscrypt-proxy. Я не мог принудительно закрыть их в мониторе активности, но я смог остановить их запуск при перезагрузке, удалив файл .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

Удаление Umbrella Roaming Client заставило поиск DNS работать нормально для меня в Mac OS Mojave.

Запустите приложение в

Applications > OpenDNS Roaming Client  > Umbrella Roaming Client Uninstaller.

Работает на MacOS Мохаве 10.14.6. В основном те же проблемы, что и у OP и других. Все работает нормально, а затем внезапно нет доступа к Интернету или локальным адресам. Я могу получить доступ по IP-адресу, но не по DNS. Ни Wi-Fi, ни проводное соединение. Явно проблема с DNS. Я вижу правильные записи DNS в настройках сети...Дополнительно...DNS. До сих пор единственным решением была перезагрузка. Потом несколько дней работал нормально, а потом опять.

То, что сработало для меня, было предоставлено выше пользователем @user674669.

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

}

При запуске

$ resetdns

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

Итак, у меня есть решение, но главный вопрос в том, почему это происходит? Раньше я безрезультатно пробовал «sudo killall -HUP mDNSResponder», но не запускал другие команды. Я могу попробовать только первые три и посмотреть, решит ли это проблему. Если для этого требуются две команды, которые ссылаются на хоумбрю, может ли хоумбрю быть проблемой?

Я уверен, что у меня будет еще одна возможность проверить это дальше.

Еще раз большое спасибо @user674669!

Обновление от 26.08.2021:

Проблема повторилась. Выполнил только первые три команды:

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

...проверенное соединение после каждого. Казалось, что требуются все три, проблема не решается полностью, а только восстанавливается функциональность DNS до тех пор, пока она не повторится.
Настоящая проблема все еще остается ... почему это происходит.

И извините, я может быть здесь новичок, но я также аналитик, и уже много лет. Я считаю, что мои ответы в том виде, в котором они опубликованы, имеют отношение к этой теме. Никто здесь не пришел к определенному окончательному решению этого вопроса. И я ссылаюсь на другой (но такой же) ответ в отношении человека (@user674669), который предоставил шаги, которые я смог использовать, чтобы помочь частично (поскольку проблема возвращается позже) решить проблему. И с этим обновлением я определил, что не все шаги, опубликованные @user674669, необходимы (по крайней мере, в моем случае) для восстановления функциональности DNS. Я считаю, что мои комментарии полезны для других, имеющих ту же проблему.

LThibx

2022 и с этой проблемой.

nslookup и dig вернули правильные значения DNS, но ping и ssh для предполагаемого устройства просто вернули общедоступный IP-адрес моего домена.

в моем случае мне пришлось отключить свой профиль DNS и «ограничить отслеживание IP-адресов» в панели настроек сети.

теперь все работает корректно и поисковые домены работают корректно.

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

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