DNS не може вирішити ім'я хоста; nslookup може

У мене є користувач в ОС Windows 7, який намагається отримати доступ до локального сервера з іменем DNS windows.cs. У нас є два внутрішніх сервери DNS. Сервер DHCP призначає користувачам два внутрішніх DNS-сервери як основний та вторинний, а потім наші DNS-провайдери як третій DNS-сервер.

Час від часу користувач не може отримати доступ до веб-сайту за адресою windows.cs. Якщо я вкажу його в текст, він говорить, що він не може вирішити ім'я хоста. Я очищаю кеш DNS, і тоді, коли я показую кеш dns, він має таке:

windows.cs - ім'я не існує

Але якщо я використовую nslookup, який за замовчуванням запитує основний DNS-сервер (наш внутрішній) і запитую windows.cs, він повертає правильну IP-адресу.

То чому Windows не може вирішити ім'я хоста за допомогою ping, але це може під час використання інструменту nslookup? І як це виправити?

Як видно з того, що ви говорите, запит на windows.cs знову і знову надходить на DNS-сервер провайдерів. Результат nxdomain потім кешується клієнтом DNS Windows і, таким чином, використовується для будь-яких спроб за допомогою веб-браузера, ping тощо. Очищення кешу (ipconfig / flushdns) повинно змусити клієнта DNS Windows повторно здійснити запит, але немає гарантії на це більше не перейде на DNS-сервер провайдера.

Причина ping не може вирішити ім'я хоста, але може бути nslookup, тому що nslookup інструмент низького рівня, який обходить клієнт DNS Windows. Він використовує будь-який сервер DNS, про який ви їм повідомляєте (перший за замовчуванням), і запит виконує з льоту. Ви можете змінити DNS-сервер, який він запитує, ввівши server <host>з підказки nslookup, де хостом є IP або FQDN.

Однак клієнт DNS Windows виконуватиме запити лише для записів, які не знаходяться в його кеші (або минули). В іншому випадку він повертає кешований результат.

Не відразу зрозуміло, чому клієнт Windows використовує DNS-сервер ISP. Можливо, він нещодавно не міг вирішити локальний сервер (через те, що він знаходився в іншій мережі), можливо, локальний сервер повертав помилки. Або, можливо, він не впорядкований правильно у розділі Розширені настройки TCP / IP> DNS.

Особисто я вважаю за краще використовувати лише локальні адреси сервера DNS на робочих станціях (поширюються DHCP), щоб спростити конфігурацію та уникнути подібних проблем. Мені буде цікаво знати обґрунтування встановлення DNS-сервера провайдерів на настільних комп’ютерах. Я не можу собі уявити, що існують вагомі причини ефективності, і, якщо надмірність триває, у більшості мереж достатньо двох (якщо не додати третю).

Результати nslookupвідрізняються від результатів pingчерез nslookupідіосинкратії та помилок . Однак вони не мають відношення до вашої основної проблеми, яка полягає в тому, що ви порушили правило про те, що ваші резервні проксі-сервери DNS повинні надавати такий самий вигляд простору імен DNS, як і ваш основний . Проксі-сервер DNS вашого провайдера не забезпечує такий самий вигляд простору імен DNS, як ваші власні проксі-сервери DNS у вашій локальній мережі.

Здавалося б, ще один системний адміністратор збився з надання мого провайдера і документує його, тому я мушу його використовувати. помилковість. ☺

Версія TL; DR: IPv6 викликав проблему запиту DNS в моєму випадку, дезактивація вирішила проблему запиту DNS.

У мене була така ж проблема на моїй машині розвитку. Щоразу, коли я входив у мережу нашої компанії, я не зміг вирішити внутрішні імена хостів, усі зовнішні імена хостів / URI могли бути вирішені. Я перевірив DNS-сервери, які були призначені на VPN-з'єднання, і вони показали, що сервери DNS компанії були налаштовані як первинні та вторинні. Я також міг використовувати, nslookupале довелося вручну змінити сервер через, server X.X.X.Xщоб отримати дозвіл DNS.

Врешті-решт я виявив, що IPv6 викликає проблеми з роздільною здатністю імені: у кожному запиті DNS запитувався DNS IPv6, а не DNS-сервери компанії IPv4. Після деактивації IPv6 вам доведеться, ipconfig /flushdnsінакше раніше запитувані адреси все-таки не вирішені.

Мені вдалося вирішити проблему просто, видаливши запис DNS і запустивши команди flushdns і registerdns, і це виправить. причина, чому саме агенін на самому DNS. DNS не видалив запис після закінчення терміну оренди і не поновився, що не змогло вирішити ім'я, оскільки воно продано для нього. Я сподіваюся, що допоможе вам вирішити свої проблеми.