У нас есть небольшая сеть с главным сервером (на котором размещается наш собственный веб-сайт и который функционирует как сервер имен) и несколькими серверами веб-хостинга. Со вчерашнего дня у нас возникла проблема с доменом нашего клиента, который мы размещаем в нашей сети.
Веб-сервер настроен правильно, сервер имен тоже (и оба работают нормально для других доменов), но домен недоступен из-за сбоя поиска имени хоста. 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, все серверы имен и данные верны. Вчера я обновил информацию о сервере имен через нашего регистратора, но это не помогло.
Вы знаете, в чем может быть проблема? Я никогда раньше не видел ничего подобного. Используемые здесь домены являются фактическими доменами, поэтому вы можете убедиться в этом сами.
Получил ответ от моего регистратора. Оказывается, 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. Попытайтесь найти что-нибудь в веб-интерфейсе регистратора, что могло бы подсказать, почему это происходит. Если не считать этого, вам нужно будет обсудить этот вопрос напрямую со своим регистратором, поскольку он единственные, кто может дать вам прямой ответ о том, в чем проблема.