Сеть нашей компании использует 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?
AAAA
записей ответов для записей, когда они (в зависимости от того, что вы говорите) не тратят столько времени, чтобы отвечать наA
запросы самых одни и те же доменные имена. Вы, кажется, находитесь на классической территории RFC 4074, где проблема в том, что серверы сломаны . Также обратите внимание, что вы столкнулись с одной из нескольких хорошо известных и долго обсуждаемых причин, по которым вы не используетеlocal.
службу DNS с разделением горизонта. Это тоже лучше исправить.local.
- плохая идея, но ИТ-отдел сказал мне, что они считают, что использоватьlocal.companyname.
- это прекрасно, и я ничего не могу с этим поделать.Ответы:
Остановите ваш ИТ-отдел от злоупотреблений
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..local
search_order 1
Сжимая руку ...
... это просто постепенно усложняющиеся тела, чтобы приспособиться к ошибочности. По словам Марка Крочмаля из Apple, «всегда будет какая-то проблема», когда люди злоупотребляют
local.
тем, что делает ваша компания. Известно, что с неправильной головой (быстрый поиск подсказывает мне) 2002, если не раньше. Просто не делай этого .дальнейшее чтение
источник
/etc/resolver/companyname.local
кажется, игнорируется в Lion.Я не знаю, Mac не может помочь, но я пришел с умной обходной идеей: если вы настроите где-нибудь в Интернете,
"somedomain.com DNAME companyname.local"
- он поймает DNAME на шаге 2. Теперь я не уверен, что произойдет затем, будет ли он все еще возвращаться к Bonjour, или, поскольку он уже находится в середине некоторого процесса DNS, возможно, он будет придерживаться DNS.источник