Почему DNS-сервер не может разрешить домен, заканчивающийся на .io?

У меня есть два контроллера домена Windows.

10.10.10.10 Первичная (победа 2008 р2)
10.10.10.20 Реплика (победа 2012 р2)

Второй настроен как точная копия первого.

Примерно раз в неделю основной контроллер домена будет кешировать большинство .io доменов. Это делает так, что никто в компании не может получить доступ к таким сайтам, как:

chef.io
packer.io
yahoo.io
github.io

Странно, но я все еще могу получить доступ к некоторым страницам .io, например, к github.io.

spuder.github.io/

Решение состоит в том, чтобы RDP в DNS-сервер и запустить dnscmd /clearcache. Это решает проблему в течение 7-10 дней.

Другие симптомы

• Влияет только на первичный контроллер домена (вторичный и другие контроллеры домена могут разрешить эти сайты просто отлично)
• Google DNS-серверы также работают
• Обычно происходит около 11 утра по средам.

Я не очень знаком с окнами, но вот что я пробовал

• Посмотрите логи, я вижу только следующие строки, которые выглядят интересными

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

• Убедитесь, что для домена .io нет зон прямого или обратного просмотра.
• Убедитесь, что в файле hosts нет ничего, что блокирует домен .io
• Сравните вывод ipconfig /displaydnsна всех контроллерах домена

Есть ли что-то еще, что я могу исследовать, чтобы выяснить, почему DNS-кэш продолжает повреждаться так предсказуемо? Есть ли настройка windows dns, которая может принудительно очищать кеш при выполнении зоны пересылки

Обновление
Я сузил это до того факта, что я часто переключаюсь с проводного на беспроводное прямо перед встречей в среду. Беспроводной имеет 1 Windows 2008 DNS-сервер и 1 Windows 2012 DNS-сервер. Когда сервер 2008 выбран в качестве основного, проблема возвращается. Обходной путь должен выполнить это dnscmd /clearcache. Поскольку сервер 2008 уходит, я уверен, что эта проблема решится сама собой.

Попробуйте обновить файл root.hints. Возможно, он указывает на некоторые старые корневые серверы имен, которые (по некоторым причинам) не возвращают домены .io.

Возможно, у вас есть проблема с маршрутизацией, которая препятствует доступу к ним (т. Е. Вы полностью скрываете диапазон IP-адресов, на котором они работают), что не позволяет искать домены внутри него. Это моя ставка - возможно, у вас есть правило брандмауэра против страны или блока IP. Используйте мои результаты ниже, чтобы проверить ваш брандмауэр или выполнить dig / nslookup для серверов .io TLD (вы можете загрузить двоичный файл для 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, но он недоступен после переключения соединений.