Сбои поиска имени хоста, сервер имен, настроенный правильно
У нас есть небольшая сеть с основным сервером (размещающий наш собственный сайт и функционирующий как сервер имен) и некоторыми серверами веб-хостинга. Так как вчера у нас есть проблема с доменом нашего клиента, который мы размещаем в нашей сети.
Веб-сервер настраивается правильно, сервер имен также (и оба хорошо работают для других доменов), но домен недостижим, потому что поиск имени хоста перестал работать. 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 своих окон PC и загружаю этот домен от 149.210.185.13 непосредственно, работы веб-сайта, заключение состоит в том, что также веб-сервер работает правильно. Когда я поиск данные WHOIS, все серверы имен и данные правильно. Вчера я обновил детали сервера имен через нашего регистратора, но это не помогло.
Вы знаете то, что могло бы быть проблемой здесь? Я никогда не видел что-то вроде этого прежде. Домены, используемые здесь, являются фактическими доменами, таким образом, Вы видите для себя.
Получил ответ от моего регистратора. Оказывается, ICANN отправляет электронное письмо с подтверждением при изменении адреса электронной почты владельца домена. Они делают это для всех своих TLD уже пару месяцев. Они дают вам одну-две недели, чтобы щелкнуть ссылку в этом электронном письме, или ваш домен будет заблокирован.
В этом случае статус регистратора в данных WHOIS должен быть clientHold . По иронии судьбы это письмо часто исчезает в ящике для спама получателя. Было бы неплохо, если бы они сначала отправили предупреждение техническому контакту (или хотя бы другому адресу электронной почты, зарегистрированному в этом домене).
Надеюсь, это поможет другим людям.
Лучше всего думать о 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. Попробуйте найти что-нибудь в веб-интерфейсе регистратора, что могло бы дать подсказку относительно того, почему это происходит. Если не считать этого, вам нужно будет обсудить этот вопрос напрямую со своим регистратором, поскольку он единственные, кто может дать вам прямой ответ о том, в чем проблема.