Поиск имени хоста не удался, сервер имен настроен правильно

Поиск имени хоста не удался, сервер имен настроен правильно

У нас есть небольшая сеть с главным сервером (хостинг нашего собственного веб-сайта и работающим как сервер имен) и несколькими серверами веб-хостинга. Со вчерашнего дня у нас возникла проблема с доменом нашего клиента, который мы размещаем в нашей сети.

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

Когда я запускаю dig directgeslaagd.comкоманду, я получаю только раздел полномочий, говорящий, com 600 IN SOA a.gtld-...что это для TLD. Когда я запускаю dig @ns1.webwhales.nl directgeslaagd.comкоманду, я получаю правильные результаты ( directgeslaagd.com. 86400 IN A 149.210.185.13). Это происходит как внутри, так и снаружи нашей серверной сети. Итак, я делаю вывод, что мой сервер имен работает правильно, верно?

Когда я настраиваю файл hosts моего ПК с Windows и загружаю этот домен с 149.210.185.13 напрямую, веб-сайт работает, вывод в том, что веб-сервер также работает правильно. Когда я просматриваю данные WHOIS, все серверы имен и данные верны. Вчера я обновил данные сервера имен через нашего регистратора, но это не помогло.

Знаете, в чем здесь может быть проблема? Я никогда не видел ничего подобного. Домены, используемые здесь, являются реальными доменами, так что вы можете убедиться сами.

решение1

Получил ответ от своего регистратора. Оказывается, ICANN отправляет письмо с подтверждением, когда меняется адрес электронной почты владельца домена. Они делают это для всех своих TLD уже пару месяцев. Они дают вам одну-две недели, чтобы нажать на ссылку в этом письме, иначе ваш домен будет заблокирован.

В этом случае статус регистратора в данных WHOIS должен бытьклиентHold. По иронии судьбы это письмо часто исчезает в папке со спамом получателя. Было бы неплохо, если бы они сначала отправили оповещение техническому контакту (или хотя бы другому адресу электронной почты, зарегистрированному в этом домене).

Надеюсь, это поможет другим людям.

решение2

Лучше всего думать о WHOIS как об информационном инструменте "лучшего усилия" для людей. Информация, которую он предоставляет, не всегда актуальна или точна, и в любом случае это не то, к чему DNS когда-либо обращается.

dig +trace +additional example.comваш друг; он помогает вам визуализировать проблемы и покажет вам то, чего WHOIS никогда не покажет. Это запускает трассировку на корневых серверах имен и отслеживает делегирование серверов имен.

В вашем конкретном случае это все, до чего доходит трассировка:

com.                    900     IN      SOA     a.gtld-servers.net. nstld.verisign-grs.com. 1425204658 1800 900 604800 86400
;; Received 112 bytes from 192.33.14.30#53(192.33.14.30) in 11 ms

Это должно вас насторожить: это очень похоже на то, что вы видели в своих предыдущих раскопках. (раздел полномочий для com.и его запись SOA). Проблема в том, что серверы имен TLD для com.не выполняют делегирование другим серверам имен.

Вот тут-то информация из WHOIS и становится полезной: directgeslaagd.com.срок действия не истек (действителен до декабря 2016 года) ипредположительнонастроено три сервера имен... но это не является верным отражением того, что на самом деле обслуживают серверы имен TLD, когда получают запрос.

Проблема где-то между веб-интерфейсом вашего регистратора и серверами имен TLD. Попробуйте найти что-то внутри веб-интерфейса регистратора, что может дать подсказку о том, почему это происходит. Если этого не произойдет, вам нужно будет обратиться к вашему регистратору напрямую, так как только они могут дать вам прямой ответ о том, в чем проблема.

Связанный контент