У регистратора остались NS прошлого подрядчика: домен разъехался

MAATRIX

Через три дня после смены DNS-подрядчика в поддержку начали падать взаимоисключающие тикеты: один клиент видит новый каталог и новые цены, другой — версию сайта, которую сняли с продакшена ещё на прошлой неделе. Разработчики клянутся, что зона обновлена и все A-записи верные. А домен как будто живёт в двух параллельных версиях одновременно. Разбираемся, почему так бывает и как это лечится за один звонок регистратору — если знать, куда смотреть.

Что сломалось: тикеты, которые не сходились друг с другом

Компания несколько лет отдавала хостинг и DNS на аутсорс веб-студии. Летом решили забрать инфраструктуру себе: перенесли сайт на собственный VPS, подняли свою DNS-зону на новом сервере имён и (как казалось) аккуратно переключили всё на новый провайдер. Через сутки после переключения посыпались странности:

• часть посетителей из соцсетей и поиска попадала на старую версию сайта — с ценами и баннерами месячной давности;
• письма с формы обратной связи иногда уходили на старый почтовый ящик, который никто уже не проверял;
• один из менеджеров жаловался, что у него в браузере сайт открывается нормально, а у коллеги за соседним столом — нет, хотя оба сидят в одном офисе за одним роутером;
• мониторинг с одной точки показывал сайт живым, с другой — резолвинг вёл на IP, который давно не отвечает на 443-й порт.

Самое неприятное в таких инцидентах — это отсутствие стабильной картины. Обычно если что-то сломано, оно сломано у всех одинаково: не резолвится домен, не работает сертификат, лежит сервер. Здесь же поведение зависело от того, кто спрашивает и в какой момент. Это первый и самый надёжный признак того, что где-то в цепочке разрешения имени участвуют два разных источника правды одновременно.

Первые гипотезы — и почему они не подтвердились

Первым делом заподозрили классику — задержку распространения изменений DNS. Логично: TTL старых записей мог быть выставлен на сутки или больше, и часть резольверов в мире просто ещё не обновила кэш. Подождали двое суток. Расхождение осталось ровно таким же по масштабу — не уменьшилось ни на йоту, что для честного истечения TTL нехарактерно: пропагация обычно "тает" постепенно, а не держится плато.

Вторая гипотеза — кэш на стороне клиента: браузер, локальный DNS-кэш операционной системы, резолвер провайдера. Проверили в приватных вкладках, с полностью очищенным resolv.conf, через мобильный интернет на другом операторе. Расхождение воспроизводилось стабильно и одинаковыми парами: одни и те же пользователи видели одну и ту же версию сайта раз за разом, разные пользователи — разные версии. Это не похоже на случайный устаревший кэш, это похоже на систему с воспроизводимым, но разным результатом.

Третья гипотеза — ошибка в конфигурации новой DNS-зоны: может быть, где-то остался старый A-record, дублирующая запись, забытый CNAME. Подняли зону в текстовом виде на новом сервере имён построчно — там всё было консистентно, единственная запись A вела на новый VPS, единственная MX — на новый почтовый сервер. Проблема была не в содержимом новой зоны. Проблема была в том, что не все в мире вообще спрашивали новую зону.

Как увидели расхождение: dig с разных резолверов и напрямую к NS

Дальше перешли от гипотез к прямым измерениям. Первый шаг — посмотреть, что вообще отдаёт делегирование на уровне TLD, независимо от того, что настроено в панели DNS-провайдера:

dig NS example.ru +short

Результат неожиданный: в ответе было не два NS-сервера нового провайдера, а четыре — вперемешку старые и новые:

ns1.newprovider.net.
ns2.newprovider.net.
ns1.oldstudio-hosting.ru.
ns2.oldstudio-hosting.ru.

То есть у регистратора в делегировании домена числятся сразу четыре authoritative-сервера: два от новой инфраструктуры и два — от той веб-студии, с которой уже разорвали договор. Дальше — контрольный выстрел: спросить каждый NS-сервер напрямую, в обход всей цепочки резолвинга, и сравнить ответы:

dig example.ru A @ns1.newprovider.net +short
# 91.203.xx.xx  — новый VPS, всё верно

dig example.ru A @ns1.oldstudio-hosting.ru +short
# 178.45.xx.xx  — старый сервер студии, который давно не трогали

Оба NS-сервера являются, с точки зрения реестра домена, полностью официальными и равноправными authoritative-источниками. Резолвер клиента при разрешении имени опрашивает не строго какой-то один из них, а любой из перечисленных в делегировании — обычно выбирая того, кто отвечает быстрее в конкретный момент, либо чередуя по алгоритмам конкретной реализации DNS-сервера. В результате какая-то доля запросов по всему миру закономерно улетала на серверы старой студии и получала оттуда устаревший, но абсолютно "легальный" с точки зрения протокола ответ.

Для наглядности стоило свести результат в таблицу — так разница видна руководству без объяснений про NS и делегирование:

Ровно то же самое подтвердил сервис проверки DNS с разных географических точек — примерно у половины проверяемых локаций домен резолвился на новый IP, у другой половины — на старый. Никакой закономерности по региону не было: распределение выглядело как честная лотерея между четырьмя NS.

Реальная причина: делегирование не заменили, а дополнили

Когда добрались до панели регистратора, причина стала очевидной. При переезде на нового DNS-провайдера ответственный сотрудник зашёл в раздел управления NS-записями домена и увидел уже заполненные два поля со старыми серверами студии. Вместо того чтобы стереть их и вписать новые, он воспользовался кнопкой "добавить сервер имён" и дописал ещё два поля с новыми NS — по принципу "лишним не будет, пусть будет с запасом". Форма это позволила: регистратор не проверяет, отвечают ли перечисленные серверы согласованными данными, он просто принимает список NS и передаёт его в реестр зоны .ru.

С точки зрения протокола делегирования это абсолютно валидная, хоть и вредная конфигурация: у домена может быть сколько угодно authoritative NS-серверов, и все они по умолчанию считаются равноценными источниками. Никакого автоматического требования "все перечисленные NS обязаны отдавать идентичную зону" в протоколе нет — эта синхронизация целиком на совести администратора. Обычно она обеспечивается зонным трансфером (AXFR/IXFR) между мастером и вторичными серверами одного и того же оператора DNS. Но здесь два "вторичных" сервера принадлежали чужой инфраструктуре, с которой никакого трансфера зоны никогда не настраивалось — это были просто старые NS предыдущего подрядчика, которые продолжали существование как отдельная, никак не связанная с новой копия давно устаревших записей.

Отдельно стоит отметить второй слой проблемы, который вскрылся уже в процессе фикса: договор со студией был расторгнут, но их сервер физически продолжал работать — просто по инерции, потому что его никто не выключил и он всё ещё числился клиентом хостинг-провайдера студии. Если бы студия успела снести свою инфраструктуру раньше, чем в реестре убрали делегирование на неё, картина была бы другой — часть запросов получала бы таймауты или SERVFAIL вместо тихо устаревшего, но валидного ответа. Формально это было бы даже проще для диагностики: явная ошибка сразу бросается в глаза, а вот "сайт открывается, просто не тот" — нет.

Как чинили: убираем лишние NS и синхронизируем переключение

Фикс по содержанию простой, но есть нюансы, которые стоит проговорить явно, чтобы не наступить на те же грабли повторно.

Первое — зашли в панель регистратора и заменили список NS-записей домена полностью, оставив только два сервера нового провайдера:

ns1.newprovider.net
ns2.newprovider.net

Старые записи студии убрали целиком, а не "оставили на всякий случай" — именно эта привычка перестраховываться и стала причиной инцидента.

Второе — сразу после сохранения проверили, что изменение действительно приняла база реестра, а не только кэш панели регистратора:

whois example.ru | grep -i "nserver\|name server"

Реестр .ru/.рф обычно применяет изменение делегирования не мгновенно, а с задержкой в диапазоне от нескольких минут до пары часов — это нормальная механика синхронизации с реестром, а не баг регистратора. Дальше уже включается обычная логика TTL: пока не истечёт TTL старой NS-записи, закэшированной резолверами, часть мира продолжит помнить прежнее делегирование. Здесь помогает то, что TTL на самой NS-записи домена, как правило, задаётся реестром централизованно и не бывает экстремально большим, но закладывать на полное затухание всё равно стоит хотя бы сутки-двое, а не рассчитывать, что всё поправится за пять минут.

Третье, уже больше про гигиену на будущее, — договорились с самой студией окончательно выключить старый сервер после подтверждённого переезда, чтобы даже случайно оставленная где-то ссылка на старые NS не смогла больше отдавать вообще ничего, кроме таймаута. Явная недоступность в диагностике гораздо честнее, чем тихий, но неверный ответ.

Четвёртое — прогнали контрольную проверку тем же способом, каким нашли проблему: опросили оба новых NS напрямую и сверили с ответами публичных резолверов нескольких провайдеров через сутки после смены делегирования. Только когда все точки проверки синхронно показали один и тот же IP, инцидент закрыли.

Похожая логика "старое не убрали, а добавили сверху" часто всплывает и при переносе домена между регистраторами — там частая ошибка ровно того же типа: NS меняют, а глю-записи или дублирующиеся серверы имён у старого регистратора не чистят. Если интересно, как устроена сама механика поиска ответа резолвером до того, как он доходит до authoritative-сервера, — это разобрано в статье про то, как DNS-запрос обходит полмира.

Что теперь: чек-лист смены DNS-провайдера и мониторинг делегирования

После разбора инцидента переезд на нового DNS-провайдера оформили в виде обязательного чек-листа, который теперь проходят перед любой сменой инфраструктуры домена:

• За несколько дней до переключения снизить TTL на всех критичных записях (A, AAAA, MX, CNAME) до минимально разумного значения — например, 300 секунд — чтобы в момент реального переезда старые ответы затухали быстро, а не сутками.
• Перед сохранением новых NS в панели регистратора явно выписать текущий список делегирования (dig NS domain +short или whois) и свериться, что новый список — это замена, а не дополнение.
• После сохранения проверить делегирование напрямую через whois, а не полагаться на интерфейс панели регистратора — она может визуально "не успевать" отражать реальное состояние реестра.
• Опросить каждый NS-сервер из итогового списка отдельно (dig @ns_адрес) и убедиться, что все они отдают одинаковый ответ по ключевым записям.
• Проверить резолвинг с нескольких независимых точек — из разных сетей, а не только с рабочего ноутбука в офисе, где локальный DNS-кэш мог уже "договориться" с правильным ответом.
• Зафиксировать в договоре с прежним подрядчиком дату и факт отключения его инфраструктуры, а не полагаться на устные договорённости "мы там всё выключим как-нибудь".
• Через неделю после переезда повторно проверить делегирование — это дешёвая страховка от ситуации, когда кто-то по привычке "восстановил бэкап конфигурации" и случайно вернул старые записи.

Отдельно стоит настроить лёгкий мониторинг именно делегирования, а не только доступности сайта: простой периодический скрипт, сверяющий список NS у регистратора и ответы каждого из них между собой, ловит подобные рассинхроны сам, без жалоб пользователей:

#!/usr/bin/env bash
DOMAIN="example.ru"
for ns in $(dig NS "$DOMAIN" +short); do
  echo "== $ns =="
  dig "$DOMAIN" A "@${ns%.}" +short
done

Если вывод для разных NS расходится — это сигнал разбираться немедленно, а не ждать, пока расхождение заметят клиенты через тикеты в поддержку. Такой скрипт стоит копейки в виде cron-задачи на любом сервере, но экономит недели репутационных потерь.

Частые вопросы