Поиск DNS завершается с ошибкой, например, с `ping`, но работает с `host`

Почему они сделали это изменение, я не знаю, но какое-то время это сводило меня с ума.

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

Рекурсивный преобразователь Apple — mDNSResponder. По какой-то причине версия mDNSResponder в Lion нуждается в параметре командной строки «-AlwaysAppendSearchDomains», чтобы вести себя так же, как в Snow Leopard (по крайней мере).

Вот быстрый способ исправить это:

sudo sed -i .orig '/ProgramArguments/,/<\/array>/ {
s/\(<string>-launchd<\/string>\)/\1\
                <string>-AlwaysAppendSearchDomains<\/string>/
}' /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

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

Это добавит аргумент «-AlwaysAppendSearchDomains» в plist-файл запуска mDNSResponder (и сохранит резервную копию), но, поскольку это контролируется launchd, этой системе необходимо указать перезапустить mDNSResponder.

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

Теперь, если вы проверите запущенный процесс mDNSResponder, вы увидите, что он работает с вашим новым аргументом:

ps auxww | grep mDNSResponder

(Реквизиты для http://www.makingitscale.com/2011/fix-for-broken-search-domain-resolution-in-osx-lion.html и http://kavassalis.com/2011/07/wtf-bug -in-os-x-10-7/ , где я нашел ответы на эту проблему.)

Со страницы руководства хоста (1):

ОС Mac X УВЕДОМЛЕНИЕ

Команда host не использует разрешение имени хоста и адреса или механизмы маршрутизации запросов DNS, используемые другими процессами, работающими в Mac OS X. Результаты запросов имени или адреса, напечатанные хостом, могут отличаться от результатов, найденных другими процессами, использующими Mac OS X. Собственные механизмы разрешения имен и адресов OS X. Результаты запросов DNS также могут отличаться от результатов запросов, использующих библиотеку маршрутизации DNS Mac OS X.

К сожалению, нет информации о том, как именно команда host разрешает имена хостов. Такое поведение делает его несколько бесполезным для отладки, ИМХО.

Основная история... nslookup была командой, но у нее была собственная реализация всех подпрограмм распознавателя. Что стало происходить, так это то, что системные распознаватели на разных платформах работали иначе, чем nslookup. Иногда это приводило к несколько иным результатам.

Команды host и dig были созданы как «перезапись» для nslookup. Они статически связываются с функциями системного преобразователя. Системный преобразователь — это набор функций из стандартной библиотеки C UNIX или UNIX-подобной системы (в Mac OS X эти функции являются частью библиотеки netdb). Делая это, команды host и dig всегда работают так же, как системный преобразователь для любой ОС, для которой они созданы, но они не полагаются на него. Таким образом, они являются отличными диагностическими инструментами в случаях, когда системный преобразователь неисправен.

ПРИМЕЧАНИЕ. Host и dig читают список серверов имен из /etc/resolv.conf, если им не дан конкретный сервер имен для связи. Только команда host использует список поиска в файле /etc/resolv.conf; dig нет, поэтому всегда нужно указывать полное доменное имя dig для разрешения чего-либо. В остальном обе команды полностью самодостаточны; например, файл /etc/resolv.conf — это единственное, чего нет в двоичном файле, который они используют.

mDNSresponder — Bonjour. Я не копался в этом слишком глубоко, но подозреваю, что этот параметр конфигурации не исправляет это или, по крайней мере, не напрямую. Я только что столкнулся с этой же проблемой в Mac OS X 10.9.1, и простой перезапуск mDNSresponder устранил ее для меня. Я никогда раньше не видел этой проблемы на 10.5 -> 10.8/10.9 в любой другой системе. Кроме того, это не затронуло приложения с графическим интерфейсом, сломались только инструменты командной строки, такие как ping и ssh.

Если я найду время еще немного покопаться в библиотеке, я посмотрю, смогу ли я найти более полное объяснение.

Я собрал сценарий оболочки для автоматизации исправления (и деинсталлятора, если он вам понадобится позже), здесь:

https://github.com/michthom/AlwaysAppendSearchDomains

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

.local зарезервирован для многоадресной рассылки. mDNS и DNS-серверы в одной сети с использованием .local могут быть проблематичными.

Хост добавляет суффикс .local dns. Пинг нет. Если вас это смущает, вы можете добавить .local в качестве суффикса по умолчанию в настройках сетевой системы, и система добавит его при попытке разрешить имена хостов.

Если вы попробовали все вышеперечисленное и ничего не получилось, вы можете добавить свои серверы имен и пути поиска вSystem Preferences>Network>Advance(bottom right of the window)>DNS tab

Это обновляет /etc/resolv.conf , и теперь ping должен работать. Обновление пути поиска путем редактирования /etc/resolv.conf на самом деле не работает, но по какой-то причине это работает.

ОБНОВИТЬ:

Редактирование /etc/resolv.conf не работает, потому что ОС перезаписывает файл на основе настроек панели «Системные настройки».

У меня недостаточно репутации, чтобы комментировать пост Ламонта Петерсона . Перезапуск mDNSresponder работал у меня в Mac OS X 10.7 (Lion). В отличие от Ламонта Петерсона, эта проблема вызвала у меня проблемы с одним приложением с графическим интерфейсом — Safari не мог разрешить общедоступные или частные имена хостов. Вот конкретные шаги, которые я сделал и которые, как я подозреваю, сделал и Ламонт Петерсон:

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

mDNSresponder unloadвыключается и loadснова запускается.

Это немедленно решило проблему; перезагрузка не требуется.

Вы можете проверить, что он успешно перезапустился, используя listкоманду:

$ sudo launchctl list | grep '^PID\|mDNSResponder'
PID     Status  Label
708     -       com.apple.mDNSResponder
-       0       com.apple.mDNSResponderHelper

Наличие идентификатора процесса (PID) означает, что он запущен. 708будет варьироваться в зависимости от назначения ОС. Если статус показывает что-то отличное от дефиса или нуля, что-то пошло не так.

я не знаю, как mDNSResponderHelperвзаимодействует с mDNSResponder; Я только когда-либо должен был перезапустить mDNSResponder.

В одной строке:

sudo kill $(ps ax | grep mDNSResponder | grep -v grep | grep -v Helper | awk '{ print $1 }')

пожалуйста, обратите внимание на имена OSX могут быть нестандартными, поэтому для полноты:

• Полное доменное имя доступно для проверки связи
• имена в файлах hosts доступны для проверки связи

Имена Mac НЕ являются общими: необходимо сделать два исправления: а) заменить пробелы на «-» б) добавить .local

так, например, мой Mac: MacBook Pro от ingconti

будет пинговаться по адресу: ingcontis-MacBook-Pro.local

И открыв настройки, вы можете увидеть: