2

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

DNS-записи моего Mac включают в себя:

  1. mydomain.com
  2. lab.mydomain.com
  3. lab.otherdomain.com
  4. othersubdomain.otherdomain.com

Я могу в полной мере разрешить полный «host.lab.mydomain.com», и когда у меня есть «lab.mydomain.com» в списке, я могу использовать только «host», так как он разрешается в «lab.mydomain.com». суффикс Но я не могу разрешить (в некоторых случаях - читать дальше) "host.lab".

Самое странное, что этот сбой происходит только с определенными командами (а именно с SSH и копанием). Использование nslookup работает нормально и правильно разрешает имя хоста. Однако использовать SSH или копать не удается. Я обычно, но не всегда, могу разрешить "host.lab" через Chrome.

Я запустил фильтрацию tcpdump на порту 53, чтобы попытаться самостоятельно диагностировать это, и результаты оказались интересными: после запуска «dscacheutil -flushcache; killall -HUP mDNSResponder» и попытки разрешить его с помощью различных команд я обнаружил, что "nslookup", конечно, выполнял правильный поиск на моем настроенном DNS-сервере, используя каждый суффикс по порядку, который обнаружил хост в коротком порядке. Однако ssh и dig, похоже, рассматривают «host.lab» как домен верхнего уровня и сразу переходят к root-servers.net, чтобы попытаться определить "host" как доменное имя в домене «.lab» - без когда-либо касаясь моего настроенного сервера DNS!

В чем дело? Почему эти определенные схемы разрешения имен на моем Mac закорачивают и рассматривают .lab как домен верхнего уровня вместо соблюдения моих суффиксов поиска DNS? Конечно, я могу обойти это, выбив полное доменное имя, но это действительно очень раздражает.

|источник

2 ответа2

2

Имейте в виду, что nslookup и dig являются инструментами отладки DNS. Они имеют собственный встроенный код распознавателя и не ведут себя так же, как системный преобразователь, используемый обычными приложениями. По умолчанию dig никогда не добавляет домены из списка поиска, чтобы попытаться полностью квалифицировать имя, даже если вы даете ему просто "host" (это будет восприниматься как домен верхнего уровня), но nslookup делает наоборот и всегда добавляет домены из списка поиска (чтобы попытаться "помочь" вам). Эти инструменты не могут быть лучше сопоставлены с инструментами отладки.

Большинство приложений командной строки (например, 'ssh') используют библиотеку BSD для поиска имен, а код распознавателя, полученный из BIND, обрабатывает любое имя с помощью "." в нем, как полностью квалифицированный домен, и он не будет добавлять домены из списка поиска. Существует долгая и дурная история о том, почему, но это лучше всего работает таким образом, чтобы избежать конфликтов и назвать "коллизии", которые случаются с добавлением списка поиска в общем смысле. Вы можете прочитать недавний анализ по этой теме.

Теперь, когда вы понимаете это, используйте "host" или «host.lab.mydomain.com» со своими приложениями. ;-)

|источник
0

Из справочной страницы dig :

Mac OS X NOTICE
       The dig command does not use the host name and address resolution or
       the DNS query routing mechanisms used by other processes running on Mac
       OS X.  The results of name or address queries printed by dig may differ
       from those found by other processes that use the Mac OS X native name
       and address resolution mechanisms.  The results of DNS queries may also
       differ from queries that use the Mac OS X DNS routing library.

При просмотре транзакций DNS через tcpdump как вы это сделали, я заметил, что dig отправлял полную квалификацию (имеет трейлинг). DNS-запрос, даже если он не был включен в командную строку:

192.168.2.122.61036 > 142.166.166.166.53: 51329+ A? www. (21)

Это, конечно, не удастся. Это поведение по умолчанию для этой компиляции dig ; добавление +search к своим аргументам заставит его вести себя более условно.

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

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .