Неймсерверы и DNS-записи: кто что контролирует

К тому, чтобы посетитель попал на ваш сайт, обычно причастны три разные компании, и их постоянно путают. Регистратор - тот, у кого вы арендуете имя и кому платите каждый год. DNS-хостинг - тот, кто отвечает на запросы об этом имени, а неймсерверы - это имена его машин. Веб-хостинг - место, где сайт на самом деле работает. Любую из трёх можно поменять, не трогая две другие, и большая часть страха перед «переносом домена» происходит от того, что человек не знает, какую именно из ролей он переносит.

Неймсерверы и DNS-записи - два разных слоя одной и той же системы. Неймсерверы говорят, кто отвечает. Записи - это то, чем они отвечают. Смена неймсерверов переносит всю зону к новому провайдеру вместе со всеми записями. Смена записи переносит одну вещь - сайт, почту, один поддомен - и оставляет всё остальное на месте. Почти всякий раз, когда кто-то говорит «мне нужно сменить неймсерверы», на самом деле нужно сменить одну запись A.

Три роли и кто обычно выполняет каждую#

По умолчанию регистратор одновременно и DNS-хостинг, потому что при регистрации имени он назначает свои неймсерверы. Из-за этой настройки по умолчанию две роли и кажутся одной вещью. Как только вы направляете неймсерверы куда-то ещё - к управляемому DNS-провайдеру, CDN, хостинг-компании, у которой свои, - регистратор перестаёт иметь отношение к вашим записям, и правка записей в его панели не даёт никакого эффекта. Это одно предложение объясняет значительную долю обращений в поддержку по DNS: клиент правит зону, которую никто не обслуживает.

Как запрос находит ваш сервер#

Когда в кэше резолвера посетителя ничего нет, он идёт вниз от самого верха.

1. Он спрашивает корневой сервер, кто отвечает за .com. Корень отвечает адресами неймсерверов .com. Этот ответ кэшируется на дни.
2. Он спрашивает сервер реестра `.com` про example.com. Реестр не знает вашего сайта - он знает только делегирование, то есть список записей NS, которые записал там ваш регистратор. Он отвечает отсылкой: «спросите ns1.dnsprovider.net».
3. Он спрашивает ваши неймсерверы о записи, которая ему на самом деле нужна, и получает ответ с приложенным TTL.
4. Он подключается по адресу из этого ответа.

Из шага 2 следуют два вывода, и их стоит запомнить.

Делегирование живёт у родителя, а не в вашей зоне. В вашей зоне на apex тоже есть записи NS, и они должны совпадать, но резолвер идёт по тем, которые выдаёт реестр. Поэтому смена неймсерверов делается у регистратора и больше нигде.

Делегирование кэшируется надолго. Отсылка .com выдаётся с TTL в два дня, так что смена неймсерверов становится видна везде до 48 часов, как бы низко вы ни задали TTL внутри собственной зоны. Записи меняются быстро, потому что их TTL контролируете вы; неймсерверы меняются медленно, потому что не контролируете. Типы записей и причину, по которой кэш - самая запутанная часть, разбирает статья DNS-записи простыми словами.

Смена места, где живёт сайт#

Это обычный случай, и он лёгкий. Зона остаётся там, где была. Вы меняете одну запись или две.

1. За день-два до этого понизьте TTL на записях, которые будете менять - example.com и www - с нынешнего значения до 300.
2. Доведите новый сервер до полной готовности и убедитесь, что он отдаёт сайт по своему адресу, прежде чем какой-либо DNS на него укажет.
3. Проверьте его под настоящим именем хоста, не меняя DNS. Либо добавьте строку в файл hosts, либо принудительно задайте разрешение имени для одного запроса:

$ curl -I --resolve example.com:443:203.0.113.10 https://example.com/$ curl -I --resolve www.example.com:443:203.0.113.10 https://www.example.com/

1. Измените запись A (и AAAA, если она есть) на новый адрес. Все остальные записи не трогайте - особенно MX и любые записи TXT для почты, потому что именно так перенос сайта уносит с собой и почту.
2. Следите за журналами доступа обоих серверов. Трафик стекает со старого в течение старого TTL.
3. Оставьте старый сервер работать минимум сутки. Одни резолверы игнорируют TTL, а у некоторых пользователей браузер открыт уже неделю.
4. Когда всё закончено, верните TTL к разумному значению.

В RE:NODE этот новый адрес - тот, что показан в слоте прокси на тарифах для приложений и сайтов. Направьте на него запись A, и сертификат будет выпущен и продлён автоматически в окне 21 день. Мы не регистрируем домены и не хостим DNS-зоны, поэтому редактора зоны здесь нет: запись вы создаёте у того провайдера, на которого указывают ваши неймсерверы, а мы лишь даём адрес, на который она указывает. Остальную часть инструкции содержит статья как направить домен на свой сервер, а почему запись нужна обоим именам, а не одному, объясняет статья www или apex: домен и редиректы.

Если это игровой сервер, а не сайт, схема та же, но запись может быть и SRV, и A - см. как привязать домен к игровому серверу.

Смена того, кто держит зону#

Переезд к новому DNS-провайдеру - это смена неймсерверов, и она переносит всё сразу. Если сделать это небрежно, вместе с сайтом упадёт почта, потому что почтовые записи живут в той же зоне.

1. Экспортируйте текущую зону. Большинство провайдеров предлагают экспорт файла зоны; если нет, перечислите все записи вручную, включая MX, каждую TXT (SPF, селекторы DKIM, DMARC, подтверждения владения доменом) и каждый поддомен. Обычная жертва - проверочные записи TXT, о добавлении которых никто не помнит.
2. Полностью воссоздайте зону у нового провайдера. Пока не переключайтесь.
3. Запросите новые неймсерверы напрямую и сравните ответы со старыми, запись за записью:

$ dig @ns1.newprovider.net example.com A +short$ dig @ns1.newprovider.net example.com MX +short$ dig @ns1.newprovider.net _dmarc.example.com TXT +short

1. Проверьте DNSSEC. Если домен подписан, в реестре есть запись DS с ключом вашего нынешнего провайдера. Если сменить неймсерверы, не разобравшись с ней, валидирующие резолверы получат разорванную цепочку и вернут SERVFAIL - а это не «медленное распространение», а недоступность вашего домена для большой части интернета. Либо удалите запись DS у регистратора и дождитесь окончания её TTL перед переключением, либо выполните полноценную ротацию multi-signer, если оба провайдера её поддерживают.
2. Смените неймсерверы у регистратора. Это единственный шаг, который выполняется там.
3. Оставьте старую зону на месте, без изменений, минимум на неделю. Резолверы, закэшировавшие старое делегирование, продолжают спрашивать старые неймсерверы, а пока те отвечают правильно, никто ничего не замечает.

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

Смена того, у кого вы арендуете имя#

Перенос регистратора переносит только платёжные отношения и ничего больше. Если ваши неймсерверы указывают на стороннего провайдера, перенос вообще не влияет на записи, сайт и почту. Если же неймсерверы принадлежат старому регистратору, сначала отдельно спланируйте перенос DNS, потому что прежний регистратор не обязан продолжать обслуживать DNS для имени, которое ему больше не принадлежит.

Шаги одинаковы у всех регистраторов для .com, .net и .org:

1. Разблокируйте домен: статус реестра clientTransferProhibited должен быть снят.
2. Убедитесь, что адрес электронной почты регистранта в записи - тот, который вы можете прочитать, потому что подтверждение приходит на него.
3. Получите код авторизации, который иногда называют кодом EPP или auth-кодом.
4. Начните перенос у нового регистратора и оплатите. Для большинства родовых доменов перенос добавляет год к регистрации.
5. Подтвердите его. Если никто ничего не нажмёт, он может завершиться до пяти дней, потому что у прежнего регистратора есть столько времени на действие.

Две блокировки застают людей врасплох. Домен нельзя переносить в течение 60 дней после регистрации или в течение 60 дней после предыдущего переноса. Изменение контактных данных регистранта тоже запускает 60-дневную блокировку у большинства регистраторов, если не отказаться от неё при изменении. Проверьте даты, прежде чем обещать кому-либо окно для миграции.

Продление - вторая вещь, которая живёт только у регистратора, и для неё стоит завести запись в календаре: истёкший домен перестаёт разрешаться независимо от того, насколько здоровы DNS и хостинг. Каждая запись, каждый сертификат и каждая почтовая политика находятся ниже по течению относительно того, что имя по-прежнему ваше.

Читаем делегирование сами#

Всё это видно снаружи, а значит, вам никогда не придётся гадать, в чью панель заходить.

# What the registry says: the authoritative nameservers$ dig NS example.com +short# What the zone itself says, asked of one of those nameservers$ dig @ns1.dnsprovider.net NS example.com +short# The whole walk, root to answer$ dig +trace example.com# Serial numbers from each nameserver, to see if they agree$ dig @ns1.dnsprovider.net SOA example.com +short$ dig @ns2.dnsprovider.net SOA example.com +short

В Windows без установленного dig ту же работу делает PowerShell:

Resolve-DnsName example.com -Type NS -Server 8.8.8.8Resolve-DnsName www.example.com -Type A -Server 1.1.1.1

whois example.com показывает имя регистратора и неймсерверы в том виде, как они записаны в реестре, и это окончательный ответ на вопрос «где это менять». Если whois и dig NS расходятся, изменение ещё в пути, а вы смотрите на кэширование.

Сравнение серийных номеров SOA - самое недооценённое из всего этого. Каждый неймсервер, обслуживающий зону, должен сообщать один и тот же серийный номер. Два разных номера означают, что один из них не подхватил вашу последнюю правку, и если вы отлаживаете запись, которая «работает иногда», причина именно в этом.

Vanity-неймсерверы и glue-записи#

Если вы запускаете неймсерверы, названные по вашему собственному домену, - ns1.example.com, обслуживающий example.com, - возникает проблема начальной загрузки. Чтобы найти ns1.example.com, резолверу нужно спросить неймсерверы example.com, а именно их он и пытался найти. Ответ - glue-запись: запись A для неймсервера, хранящаяся в реестре рядом с делегированием, так что отсылка несёт адрес с собой.

Glue создаётся у регистратора, обычно в разделе с названием вроде «register a nameserver» или «host records», и она отделена от записи A внутри вашей зоны. Нужны обе, и они должны совпадать. Если вы измените адрес vanity-неймсервера и обновите только зону, glue продолжит отправлять резолверы на старую машину, и вы получите перемежающиеся сбои, которые лично у вас проходят, потому что ваш резолвер случайно закэшировал ответ самой зоны.

Если нет особой причины - хостинговый бренд или требования к тому, какие имена показываются в whois, - vanity-неймсерверы не стоят лишнего вида сбоя. Используйте имена вашего DNS-провайдера.

Где это идёт не так#

Правка записей не у того провайдера. DNS-панель регистратора по-прежнему показывает зону после того, как вы направили неймсерверы в другое место. Всё, что вы там набираете, значения не имеет. Прежде чем что-либо править, проверьте через dig NS.

Lame-делегирование. Записи NS указывают на неймсервер, который зону не обслуживает, - обычно это остаток от провайдера, которому вы перестали платить. Резолверы пробуют его, получают REFUSED и переходят к остальным, так что сайт работает, но каждый запрос медленнее, а некоторые резолверы вообще сдаются. Удаляйте неймсерверы, которыми больше не пользуетесь.

Потерянная при переезде сайта почта. Запись MX и запись SPF TXT при перестройке зоны у нового провайдера воссоздали неверно или не воссоздали вовсе. Сбои почты для вас тихие: отправители получают отказ, а вы ничего. Проверяйте MX и каждую почтовую запись TXT сразу после любого переноса зоны; какие именно искать, перечислено в статье SPF, DKIM и DMARC простыми словами.

DNSSEC, оставленный подписанным у старого провайдера. Описано выше, и стоит повторить, потому что проявляется как полная авария для одних пользователей и как работающий сайт для других, а это самый трудный для диагностики по обращению вид сбоя.

TTL, который так и не понизили. Запись с TTL в 24 часа, изменённая в 09:00, всё ещё отдаёт старый ответ в 08:00 на следующий день всем, кто спрашивал за это время. Сбросить чужие резолверы нельзя. Планируйте это или понижайте TTL заранее.

Сертификат, выпущенный до того, как запись стала верной. При выпуске проверяется, что имя указывает на сервер, запрашивающий сертификат. Если запись A всё ещё разрешается в старый хост, выпуск не удаётся, а сообщение об ошибке говорит о проверке (challenge), а не о DNS. Исправьте запись, дождитесь окончания TTL, попробуйте снова.

FAQ#

Нужно ли менять неймсерверы, чтобы перенести сайт?

Нет. Измените запись A - и AAAA, если она есть, - на адрес нового сервера. Менять неймсерверы нужно, только если вы переходите к другому DNS-провайдеру. Переезд хостинга и переезд DNS - разные решения, и делать их по отдельности проще.

Могут ли регистратор и DNS-провайдер быть разными компаниями?

Да, и для чего-то важного обычно так и стоит делать. Вы регистрируете имя в одном месте и направляете неймсерверы в другое; регистратор тогда занимается только продлением, делегированием и переносами. На ваши записи это никак не влияет.

Сколько занимает смена неймсерверов?

До 48 часов для .com и большинства gTLD, потому что таков TTL делегирования, которое выдаёт реестр. На практике часто гораздо быстрее, но сократить его нельзя, и старую зону не следует удалять, пока не пройдёт всё окно.

Почему изменение DNS работает у меня, но не у всех остальных?

Потому что ваш резолвер уже получил новый ответ, а у чужих ещё действует старый TTL. Проверьте через dig @8.8.8.8 и dig @1.1.1.1, а также через свой резолвер, и сравните серийный номер SOA на всех ваших неймсерверах на случай, если один из них просто не обновился.

Что будет с моей почтой, если я поменяю веб-хостинг?

Ничего, пока вы меняете только запись A для сайта. Записи MX и почтовые записи TXT - отдельные элементы той же зоны, и почта доставляется туда, куда указывает MX. Проблемы возникают, только когда зону перестраивают с нуля у нового DNS-провайдера и эти записи забывают.

Предоставляет ли RE:NODE неймсерверы или регистрирует ли домены?

Нет. Мы не регистрируем домены, не запускаем неймсерверы и не хостим DNS-зоны, и в панели нет редактора зоны. Домен вы оставляете у своего регистратора, а зону - у того DNS-провайдера, которого предпочитаете, и направляете запись на адрес, который даёт слот прокси.