Чому сервер DNS не може вирішити жоден домен, що закінчується .io?


10

У мене є два контролери домену Windows.

10.10.10.10 Первинний (виграш 2008 р2)
10.10.10.20 Репліка (виграш 2012 р2)

Другий налаштований як репліка першого.

Приблизно раз на тиждень первинний DC негативно кешуватиме більшість .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 немає прямих або зворотних зон пошуку
  • Переконайтесь, що у файлі хостів немає нічого, що блокує домен .io
  • Порівняйте вихід ipconfig /displaydnsна всіх контролерах домену

Чи є ще щось, що я можу дослідити, щоб дізнатись, чому кеш-пам'ять dns так швидко передбачується? Чи є налаштування windows dns, яке може примусово промивати кеш, виконуючи зони transer

Оновлення
Я звузив це до того, що я часто переключаюся з дротового на бездротове перед початком зустрічі в середу. У бездротовій мережі є 1 сервер Windows 2008 dns і 1 сервер Windows 2012 dns. Коли сервер 2008 обраний як основний, проблема повертається. Вирішення цього завдання полягає в тому, щоб виконати це dnscmd /clearcache. Оскільки сервер 2008 року відходить, я впевнений, що ця проблема вирішиться сама.


Це жахливо специфічно. Це схоже на те, що дані сервера імен для ioTLD стають клоберованими, або пристрій мережевого пристрою вище, який не використовується спільним вторинним постійним струмом, перетворюється на мережу через глибоку політику перевірки пакетів. Переконайтесь, що на первинному постійному струмі немає жодних зон, які могли б заважати серверам імен вище за поточним TLD. ( ., io, net, ac, uk, co.uk, ns13.net, nic.io, nic.ac, icb.co.uk, communitydns.net) Звучить безглуздо, але люди іноді роблять дуже Braindead речі при спробі використовувати їх DC в якості рішення DNS брандмауера.
Андрій Б

Інша справа - перевірити, як ваші DNS-сервери роблять нелокальні пошуки. Для кожного з ваших серверів DNS перевірте параметри для форвардерів та підказок Root. Якщо один використовує відфільтрований форвардер, а інший - це не проблема. Крім того, якщо у вас є лише один пересилаючий та неповний набір кореневих підказок, у вас можуть виникнути проблеми з цього питання.
Марк

1
Що ще у вашій системі відбувається в середу об 11 годині ранку, що може призвести до того, що сервер не зможе шукати ці домени (і кешувати помилку)?
Calle Dybedahl

тож проблема стоїть на клієнті, деякі * .io домени взагалі не вирішені, поки ви не очистите кеш? Якщо ви переходите на консоль DNS, чи показує GUI консолі правильні IP-адреси для цих імен у кеші?
strongline

Чи налаштований ваш DNS-сервер для використання експедиторів?
Майк Марселья

Відповіді:


1

Спробуйте оновити файл root.hints. Можливо, це вказує на деякі старі сервери імен кореня, які (чомусь) не повертають домени .io.

Можливо, у вас є проблема з маршрутизацією, яка перешкоджає доступу до них (тобто: ви чорно затуляєте діапазон IP, на якому вони працюють), що заважає шукати домени всередині нього. Це моє питання - можливо, у вас є правило брандмауера щодо країни або блоку IP. Скористайтеся моїми результатами нижче, щоб перевірити брандмауер або виконати копання / 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 зворотної адреси, але це недоступно, коли ви переключитесь на з'єднання.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.