У меня два контроллера домена Windows.
10.10.10.10 Primary (победа 2008 r2)
10.10.10.20 Реплика (win 2012 r2)
Второй настроен как реплика первого.
Примерно раз в неделю основной DC будет отрицательно кэшировать большинство .io домены. Благодаря этому никто в компании не может получить доступ к таким сайтам, как:
chef.io
packer.io
yahoo.io
github.io
Как ни странно, я все еще могу получить доступ к некоторым страницам .io, например, на github.io
Решение - подключить RDP к DNS-серверу и запустить dnscmd /clearcache. Это решает проблему на 7-10 дней.
Дальнейшие симптомы
Я не очень знаком с окнами, но вот что я пробовал
8:15AM
The DNS server wrote version 4638 of zone 254.10.in-addr.arpa to file 254.10.in-addr.arpa.dns..in-addr.arpa to file 254.10.in-addr.arpa.dns.
8:16AM
A more recent version, version 4639 of zone 254.10.in-addr.arpa was found at the DNS server at 10.254.40.51. Zone transfer is in progress.ic replication between domain controllers in a common domain or forest. By installing multiple domain controllers in a domain running DNS Server, you can ensure that DNS will continue to work when a domain co
ipconfig /displaydns на всех контроллерах доменаМогу ли я еще что-нибудь исследовать, чтобы выяснить, почему кеш DNS так предсказуемо портится? Есть ли параметр Windows dns, который может принудительно очистить кеш при выполнении зонного трансфера?
Обновить
Я сузил это до того факта, что я часто переключаюсь с проводного на беспроводной прямо перед собранием в среду. Беспроводная сеть имеет 1 DNS-сервер Windows 2008 и 1 DNS-сервер Windows 2012. Когда сервер 2008 выбран в качестве основного, проблема возвращается. Обходной путь - запустить это dnscmd /clearcache. Поскольку сервер 2008 года уходит, я уверен, что эта проблема исчезнет сама собой.
Рассмотрите возможность обновления файла root.hints. Возможно, это указывает на какие-то старые корневые серверы имен, которые (по какой-то причине) не возвращают домены .io.
Возможно, у вас есть проблема с маршрутизацией, которая не позволяет получить к ним доступ (например, вы закрываете черный диапазон IP-адресов, на которых они работают) что предотвращает поиск доменов внутри него. Я уверен, что у вас есть правило брандмауэра против блокировки страны или IP-адреса. Используйте мои результаты ниже, чтобы проверить свой брандмауэр или выполнить dig / nslookup для серверов TLD .io (вы можете загрузить двоичный файл для Windows из http://www.isc.org/downloads/
# dig +trace +identify git.io
...
io. 172800 IN NS b0.nic.io.
io. 172800 IN NS a0.nic.io.
io. 172800 IN NS a2.nic.io.
io. 172800 IN NS ns-a1.io.
io. 172800 IN NS ns-a3.io.
io. 172800 IN NS c0.nic.io.
...
Можете ли вы напрямую связаться со всеми этими DNS-серверами? Например, ваш DNS-сервер может многократно использовать первый в списке. Имейте в виду, что этот список актуален (прямо сейчас) и меняется, но он должен дать вам начальную точку, чтобы увидеть, сможете ли вы связаться с корневыми серверами имен .io.
# for i in b0.nic.io a0.nic.io a2.nic.io ns-a1.io ns-a3.io c0.nic.io; do host $i; done
b0.nic.io has address 65.22.161.17
b0.nic.io has IPv6 address 2a01:8840:9f::17
a0.nic.io has address 65.22.160.17
a0.nic.io has IPv6 address 2a01:8840:9e::17
a2.nic.io has address 65.22.163.17
a2.nic.io has IPv6 address 2a01:8840:a1::17
ns-a1.io has address 194.0.1.1
ns-a1.io has IPv6 address 2001:678:4::1
ns-a3.io has address 74.116.178.1
c0.nic.io has address 65.22.162.17
c0.nic.io has IPv6 address 2a01:8840:a0::17
Если вы используете серверы пересылки, протестируйте nslookup напрямую на этих серверах пересылки. Если он не возвращается, обратитесь к тому, кто их запускает (к вашему интернет-провайдеру).
==== Обновление: учитывая ваше обновление, где вы отмечаете, что это происходит при смене провайдера, я предполагаю, что одно из ваших подключений использует IPv6, а другое поддерживает только IPv4? Возможно, это кеширующий обратный адрес IPv6, но он недоступен при переключении соединения.