Алексеем Рыжовым, теневым исследователем рунета 
и моим другом был обнаружен один интересный глюк. Покопавшись в истоках глюка удалось сделать кое-какие заключения. Поскольку Алексей действительно человек скрытный и публичных заявлений не делает, напишу об этом я. Наунет блог точно читает, поэтому, полагаю, все будет исправлено либо Наунетом, либо ТЦ.
Немного информации для непосвященных: ТЦ - технический центр зоны .RU. В ТЦ стекается информация о всех действиях с доменами в зоне. Если в информации о домене в ТЦ и у регистратора имеются расхождения основной считается информация из базы ТЦ. Также из ТЦ берется whois-информация, выдаваемая whois.ripn.net:43. Кстати, если порыться в хуизах различных регистраторов, бывают случаи, когда старый регистратор продолжает считать домен своим, в то время, как он уже был передан другому регистратору. Суть понятна - данным ТЦ доверять можно, а какому-то конкретному регистратору - с натяжкой.
У Наунет есть домен bestwebdesigner.ru. Whois этого домена на момент написания поста (звездочки в поле e-mail - мои):
domain: BESTWEBDESIGNER.RU
type: CORPORATE
nserver: ns4.hostlife.net.
nserver: .
nserver: ns3.hostlife.net.
state: REGISTERED, DELEGATED
person: Vitalij G Jushkov
phone: +7 951 4529709
fax-no: +7 951 4529709
e-mail: *****@******.ru
registrar: NAUNET-REG-RIPN
created: 2008.02.10
paid-till: 2009.02.10
source: TC-RIPN
Last updated on 2008.04.26 12:06:06 MSK/MSD
Сразу бросается в глаза нейм-сервер - точка. Точка в конце каждого нейм-сервера добавляется автоматически. Таким образом, нейм-сервер, поданный при делегировании домена ничего не содержал, либо содержал некий служебный символ, который не интерпретируется системой. Пустота на месте нейм-сервера подтверждается и при проверке зоны на корневых NS .RU. Особенно интересные результаты можно обнаружить, если пользоваться не дигом, а низкоуровневыми обращениями к DNS.
Известно, что по правилам домен может быть делегирован только в том случае, если на нейм-серверах содержится зона для делегируемого домена с указанием в записях типа NS всех нейм-серверов, указанных в заявке на делегирование, и ни каких более.
В данном случае при делегировании домена должны были быть проверены три нейм-сервера: ns4.hostlife.net, ns3.hostlife.net и ”(пусто)”. На каждом из этих нейм-серверов должна быть зона для домена с записями типа NS вида:
bestwebdesigner.ru. 14400 IN NS ns4.hostlife.net.
bestwebdesigner.ru. 14400 IN NS ns3.hostlife.net.
(Это реальный ответ с ns3.hostlife.net. C ns4.hostlife.net ответ получить не удалось.)
Понятно, что на “пустом” нейм-сервере никакой зоны содержаться не может, равно как странно предполагать наличие в зоне записи вида
bestwebdesigner.ru. 14400 IN NS .
named, сталкиваясь с подобными случаями, “подвисает” и перестает воспринимать новую информацию до правки зон и перезагрузки.
Поскольку регистраторы по определению существа ненадежные (относительно ТЦ), а проверка нейм-серверов при делегировании возложена именно на них, то можно допустить, что Наунет пропустил такой набор нейм-серверов мимо ушей и выставил домену статус “делегирован”. Но что же в это время делал технический центр? Входящие данные о нейм-серверах должны проверяться. Просто хотя бы на корректность хоста по шаблону. Иначе можно было бы “делегировать” домены на
nserver: chto hochu.
nserver: to.
nserver: vorochu.
Совершенно непонятно, как ТЦ и Наунет пропустили такую информацию. Одно из предположений: при проверке используется конструкция вида:
if (ns != null && !check(ns, regexp)) then BAD else GOOD
И если на каком-то раннем этапе в качестве ns проскочила пустая строка, то бац - и пустой сервер становится GOOD.
Как это случилось на самом деле, думаю могут сказать только Наунет и ТЦ. Надеюсь, они прочитают этот пост и примут меры. Иначе ерунда какая-то получается.
Всем спасибо
*за иллюстрацию отдельное спасибо 19th.
UPD 27 апреля
Нсы исправили. Итого пустой НС провисел с 9 по 27 апреля
Кстати, как показал анализ истории по доменам, такой случай уже был по меньшей мере один раз: домен madmind.ru висел с пустым нейм-сервером с 14 по 16 сентября 2006 года. Значит у Каравана тоже был глючок, правда исправили оперативно - наверное клиент пожаловался на недоступность сайта.