10 секундная задержка для .local TLD в Mac OS X Lion

Сеть нашей компании использует xxx.companyname.localдля всех серверов в нашей локальной сети. Всякий раз, когда я получаю доступ к одному из этих серверов на моем Mac, у меня задерживается 10 секунд. Я обнаружил, что эта задержка вызвана поиском DNS, потому что, по-видимому, Lion разрешает домены .local в следующем порядке:

проверить /etc/hostsадрес IPv6
проверьте DNS-сервер для записи AAAA (адрес IPv6)
проверка через MDNS (Bonjour) для записи AAAA
проверить /etc/hostsадрес IPv4
проверить DNS-сервер для записи A (адрес IPv4)
проверить MDNS для записи

Теперь проблема в том, что у нас нет сети IPv6. Все xxx.companyname.localсерверы в нашей сети имеют только IPv4-адреса, а DNS-сервер имеет только A-записи. Это означает, что адрес разрешен в шаге 5. Проблема в том, что шаг 3 занимает десять секунд, прежде чем истечет время ожидания! Каждый раз, когда я подключаюсь к нашей вики, серверу SVN, серверу Kerberos и т. Д., Задержка составляет 10 секунд.

Мне удалось обмануть Льва, добавив строки, подобные следующим /etc/hosts

::FFFF:10.99.99.99 xxx.companyname.local

Если я сделаю это, Lion подумает, что для домена существует IPv6-адрес, и остановится после шага 1. Однако этот обходной путь полностью обходит все полезные функции DNS. Я не хочу вручную отслеживать IP-адреса десятков внутренних доменов! Я мог бы также прекратить использовать имена хостов и просто вводить IP-адреса!

Итак: у кого-нибудь есть идея, как изменить этот порядок поиска? Или отключить поиск IPv6, так как у нас нет сети IPv6?

dns osx-lion bonjour

— Якоб Эггер
источник

Спасибо за вопрос - я отмечаю его как ссылку на разрешение Mac для Mac;)

— Alex

Вам лучше справиться с попыткой определить, почему вашим DNS-серверам требуется 10 секунд, чтобы отправить пустой набор AAAAзаписей ответов для записей, когда они (в зависимости от того, что вы говорите) не тратят столько времени, чтобы отвечать на Aзапросы самых одни и те же доменные имена. Вы, кажется, находитесь на классической территории RFC 4074, где проблема в том, что серверы сломаны . Также обратите внимание, что вы столкнулись с одной из нескольких хорошо известных и долго обсуждаемых причин, по которым вы не используете local.службу DNS с разделением горизонта. Это тоже лучше исправить.

— JdeBP

DNS-серверы на втором шаге мгновенно возвращают пустую запись AAAA. Проблема в шаге 3 - запрос MDNS / Bonjour / Zeroconf. Лев ждет 10 секунд после трансляции, прежде чем истечет время ожидания. Немного погуглив, я хорошо понимаю, что использование local.- плохая идея, но ИТ-отдел сказал мне, что они считают, что использовать local.companyname.- это прекрасно, и я ничего не могу с этим поделать.

— Якоб Эггер

Люди в вашем ИТ-отделе очень плохо информированы. Известно, что в кругах сетевого администрирования это не очень «идеально» в течение примерно полувека. Вы могли бы… поощрять… привлечение знаний людей из вашего отдела информационных технологий в XXI век. Вы могли бы… напомнить… им, что их работа не в том, чтобы организовывать такие дела, чтобы корпоративные компьютеры не работали должным образом. ☺

— JdeBP

@JdeBP И, тем не менее, Apple решила, что было бы неплохо использовать его ... Вы заметите, что Microsoft также использует его и рекомендует его в качестве лучшей практики. Итак ... Кто сказал, что это не так ?

— Основные

Ответы:

Остановите ваш ИТ-отдел от злоупотреблений `local.`.

Как уже говорилось, злоупотребление доменным именем, которое не принадлежит вашей компании и, следовательно, не должно предполагать, что оно может создавать корпоративные субдомены, является неправильным и составляет половину проблемы здесь. Если на компьютерах компании есть Macintoshes (или что-то еще, использующее DNSSD в этом отношении), то, безусловно, не думайте, что local.вы можете свободно так возиться с этим.

Обновите свой Macintosh.

MacOS 10.4 действительно будет работать так, xxx.companyname.local.как вы описываете. Но это изменилось в более поздних версиях операционной системы. MacOS 10.5 передает только двухкомпонентные имена в Multicast DNS. Имена с тремя метками, такие как xxx.companyname.local., не обрабатываются MDNS. MacOS 10.6 продвигается дальше и пытается определить, был ли DNS-сервер неправильно настроен на создание local. зоны и действовать соответствующим образом.

Как минимум, вы должны настроить свой Macintosh так, чтобы в нем был файл /etc/resolver/названия компании, в котором перечислены текущие IP-адреса вашего прокси-сервера DNS. Это не будет хорошо работать с IP-адресами DNS-сервера, назначенными DHCP, которые меняются, как говорит Apple..localsearch_order 1

Сжимая руку ...

... это просто постепенно усложняющиеся тела, чтобы приспособиться к ошибочности. По словам Марка Крочмаля из Apple, «всегда будет какая-то проблема», когда люди злоупотребляют local.тем, что делает ваша компания. Известно, что с неправильной головой (быстрый поиск подсказывает мне) 2002, если не раньше. Просто не делай этого .

дальнейшее чтение

dlove (2002-12-02). Проблемы с доменом .local и DNS . Macworld.
Apple Corporation (2010). Mac OS X v10.4, 10.5, 10.6: как искать «.local» имена хостов через Bonjour и стандартный DNS .
Стивен Хоффман (2010). Советы по DNS: Смешивание одноадресной и многоадресной DNS с .local . HoffmanLabs.
Apple Corporation (2008). Mac OS X 10.3: как искать «.local» имена хостов через Bonjour и стандартный DNS .

— JdeBP
источник

Ничто из этой информации не решает мои проблемы с разрешением DNS в Lion (Mac OS X 10.7). Кроме того, /etc/resolver/companyname.localкажется, игнорируется в Lion.

— Якоб Эггер

Я не знаю, Mac не может помочь, но я пришел с умной обходной идеей: если вы настроите где-нибудь в Интернете, "somedomain.com DNAME companyname.local"- он поймает DNAME на шаге 2. Теперь я не уверен, что произойдет затем, будет ли он все еще возвращаться к Bonjour, или, поскольку он уже находится в середине некоторого процесса DNS, возможно, он будет придерживаться DNS.

— Alex
источник

Я могу добровольно создать DNAME для вас, если хотите :)