Windows 2012 не може перевірити форвардерів без кореневої зони?

(Відмова: Я не адміністратор DNS Windows. У мене є пристойний досвід роботи з DNS під моїм поясом, і це не має жодного сенсу. Я тісно співпрацюю з адміністраторами, відповідальними за ці пристрої, і можу отримати тести як потрібні.)

У нас виникла проблема, коли ми не можемо додати умовних пересилачів, які вказують на сервери імен BIND під Windows Server 2012. Додавання IP-адреси сервера призводить до помилки перевірки: An unknown error occurred while validating the server.

відмова експедитора. :(

Дивлячись на журнал запитів на сервері BIND, ми знайшли щось досить цікаве: сервер Windows DNS запитував . IN SOA, тобто запис SOA для кореневих серверів імен. Жодного запиту немає example.com. IN SOA. Він намагається здійснити запит на root root і не продовжується, коли отримає відповідь REFUSED.

client 192.168.203.20#59067 (.): query: . IN SOA - (192.168.208.201)
client 192.168.203.20#50553 (.): query: . IN SOA - (192.168.208.201)
client 192.168.203.20#55468 (.): query: . IN SOA - (192.168.208.201)

Божевілля. Для того, щоб озвучити це, ми відтворили цю проблему в лабораторії. Я завантажив копію кореневої зони та налаштував .зону (коментуючи свої підказки для кореня), і ось, ось ця помилка більше не виникає.

Я справді цього не розумію. Я надаю авторитетного сервера імен, на який не повинно бути відповідей . SOA, і, як теперішні справи, мені доведеться додати цю зону до всіх наших виробничих серверів, щоб чудово грати з Windows 2012. На мій досвід, експедитор повинен перейматися лише тим, чи є цільовим сервер імен авторитетним для відповідної зони.

Чому це відбувається?

Якщо ми намагаємось ігнорувати помилку (все одно натискаючи кнопку ОК), ми отримуємо наступне діалогове вікно помилок:

більше відхилення експедитора. :(

Журнал запитів все ще показує, що сервер висхідного потоку лише запитує . IN SOA. Ніколи не намагаються зрозуміти, чи є сервер авторитетним example.com..

— Андрій Б
джерело

Перевірка не вдається, але чи працює умовний експедитор незалежно? (Я маю на увазі, чи можете ви просто проігнорувати помилку?)

— Райан Райс

@Ryan Я оновив питання в діалоговому вікні помилки, яке з'являється, коли адміністратори намагаються додати пересилателя все одно.

— Андрій Б

@AndrewB Я намагався відтворити це і в 2012, і в 2012R2, але не вдалося. Показується початкова помилка перевірки (і я бачу дивний запит . IN SOA), але натискання кнопки "ОК" працює, як і далі (помилки більше не відображаються). Можливо, друге повідомлення про помилку, яке ви отримуєте, не пов'язане з дивною поведінкою перевірки? Чи працює Add-DnsServerConditionalForwarderZone(повноваження) чи видає корисніше повідомлення про помилку?

— Хокан Ліндквіст

@ Håkan Перше попередження про непов’язаність звучить ймовірно, і ми зупинимося на другому.

— Андрій Б

@ Håkan Частина плутанини полягала в тому, що вони, мабуть, намагалися додати експедитора, використовуючи ім'я сервера під час першої спроби, що робить поле OK і заважає їм продовжувати. (на відміну від скріншоту, наведеного вище) Залишилася проблема не пов’язана з цим питанням, і я збираюся закрити питання і відповіді. Будь ласка, конвертуйте свій коментар про заплутану поведінку валідації у відповідь, щоб я міг дати вам подяку.

— Андрій Б

Я намагався відтворити це на Windows 2012 та Windows 2012 R2, але не зміг отримати однаковий кінцевий результат.

Я можу підтвердити початкову помилку перевірки ( під час перевірки сервера сталася невідома помилка ), і я бачу дивний запит . IN SOA, але натискання кнопки «ОК» у цій точці, здається, працює (більше ніяких помилок не відображається, і зона переадресації - додано).

Здається, що друге повідомлення про помилку, з яким ви зіткнулися ( Виникла проблема під час спроби додати умовного експедитора. Виникла проблема з конфігурацією зони. ), Може не мати відношення до дивної поведінки перевірки.

Я не можу сказати, чому він робить свою перевірку на основі запиту, . IN SOAале, здається, це здебільшого косметична проблема, оскільки вам не заважають продовжувати процес, незважаючи на помилку перевірки.

— Хокан Ліндквіст
джерело

-1

я зіткнувся з тією ж проблемою і висловив подяку богу. Проблема, яка була в роді IP DNS на картці NIC у первинному домені, повинна бути у кращому (IP первинного домену), а альтернативою є (вторинний DC) для всіх вторинних: у кращому (IP домену seconder) і альтернативою є (Первинний постійний струм). спробуйте це рішення та надішліть відгуки. Спасибі.

— Айман Халил
джерело