Домен и DNS на практике: зона своего сайта и переезд без простоя

Зона DNS — список записей домена: A, CNAME, MX, TXT. Действует та зона, на которую указывают NS-серверы домена у регистратора.

Три компании и один домен

С доменом работают сразу три стороны, и путаница между ними: это самая частая причина «я всё поменял, а ничего не изменилось».

• Регистратор: компания, у которой вы купили имя. Она записывает в реестр (например, в реестр зоны .ru), что имя за вами, и сообщает, чьи серверы NS отвечают за зону. Для .ru и .рф регистраторов много, их список ведёт Координационный центр доменов; имя оформляют на человека или организацию, и для физического лица регистратор попросит паспортные данные (в открытом списке владельцев они скрыты).
• DNS-хостинг: серверы, на которых лежит ваша зона: список записей домена. Часто это DNS самого регистратора, но может быть DNS хостинга, Яндекс Облака или стороннего сервиса.
• Хостинг сайта: компьютер, на который указывает запись A. С первым уроком части вы уже знаете, что это отдельная покупка.

Главное правило: действует та зона, на которую указывают NS домена. Если NS домена указывают на DNS регистратора, а вы изменили запись в панели хостинга, вы поправили копию, которую никто не спрашивает. Поэтому первая проверка при любой проблеме с DNS одна: dig example.ru NS (или аналог в онлайн-сервисе), и правите вы там, куда эти серверы ведут.

Проверьте себя: где правят записи домена, если NS указывают на DNS регистратора?

В панели DNS регистратора. Любая другая копия зоны (у хостинга, у сервиса) не используется, пока NS не переключат на неё.

Как выглядит зона

В записях, которые вы разобрали в уроке о DNS, нет ничего нового. Но на практике их читают как текст. Каждая строка зоны это имя, TTL, тип и значение:

@      300   A      192.0.2.10
www    300   CNAME  example.ru.
@      3600  MX     10 mail.example.ru.
@      3600  TXT    "v=spf1 include:_spf.mail.example ~all"
_dmarc 3600  TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.ru"

Адреса здесь выдуманные: 192.0.2.10 из блока, который зарезервирован для документации. Три мелочи, на которых спотыкаются.

• @ означает сам домен (корень), www значит поддомен www.example.ru.
• Точка в конце имени (example.ru.) значит «полное имя, дописывать ничего не нужно». В некоторых панелях точку нужно ставить, в других она подставляется сама. Если в панели без точки получилось example.ru.example.ru, значит, она дописала домен второй раз.
• Каждая панель переводит эти строки в свои поля, но смысл тот же: имя, тип, значение, TTL.

Корень и www

Посетители набирают оба варианта, example.ru и www.example.ru, и оба должны открывать сайт. Кажется, что достаточно записи CNAME на корень, но это ловушка: по правилам DNS CNAME должна быть единственной записью на своём имени (RFC 1034), а в корне всегда есть служебные записи NS и SOA, и часто ещё MX и TXT. Поэтому:

• для корня ставят A (и AAAA для IPv6) с адресом сервера, а когда адрес платформы меняется и её документация этого не обещает, просят у провайдера DNS ALIAS/ANAME или «CNAME flattening»: провайдер сам подставляет актуальный адрес;
• для www ставят CNAME на корень или на имя, которое назвала платформа.

И ещё одно решение, которое поможет и поиску: выберите один основной адрес, а второй перенаправляйте на него постоянным редиректом 301, как в уроке про HTTP. Тогда у сайта один адрес для людей и поисковиков, а не два одинаковых.

Языки: каталог, поддомен или домен

Если в брифе есть второй язык, нужно решить, где он живёт. Три варианта.

1. Каталог: example.ru/en/. Ничего не меняется в DNS, один сертификат, весь вес домена общий. Для небольшого сайта это обычно лучший выбор.
2. Поддомен: en.example.ru. Подходит, если у языка свой сервер или приложение. В DNS ещё одна запись, и сертификат должен охватывать поддомен.
3. Отдельный домен: example.com. Это отдельный рынок или бренд: за него отдельно платят, и вес сайта делится на два.

В любом случае страницы связывают друг с другом атрибутом hreflang, как в части про HTML. Поддомены нужны не только для языков: status.example.ru для страницы состояния, app.example.ru для приложения, blog.example.ru, если блог живёт на другом сервисе.

Почта и подтверждения в зоне

У зоны есть три «посторонние» задачи, и все они записываются в тот же файл.

• MX говорит, куда доставлять письма. Если почту ведёт внешний сервис (Яндекс 360, VK WorkSpace, Mail.ru для бизнеса и другие), он даст точные значения. Значением MX всегда служит имя сервера, а не IP-адрес, и это имя не должно быть CNAME.
• SPF, DKIM, DMARC это TXT-записи, о которых подробно рассказано в части про рассылки. Здесь важны две практические вещи: SPF-запись на домене должна быть одна (две ломают проверку, правила объединяют в одну), а DMARC начинают с p=none и смотрят отчёты.
• TXT для подтверждения владения. Яндекс Вебмастер, Google Search Console, облачные сервисы и платформы просят положить в TXT особую строку, чтобы убедиться, что домен ваш. Такие записи можно оставлять, пока вы пользуетесь сервисом.

В дополнение полезна запись CAA: она перечисляет, какие удостоверяющие центры вправе выдавать сертификаты на домен. Для небольшого сайта это необязательная защита, но она есть в следующем уроке.

Поиграйте на схеме. В первой вкладке вы переезжаете на новый сервер и смотрите, сколько посетителей ещё идёт на старый: меняйте TTL и время, когда вы его уменьшили. Во второй проверяется зона, написанная текстом: в примере сразу несколько ошибок, найдите и исправьте их.

Переезд на новый сервер Проверить зону

TTL записи сейчас 5 минут1 чассутки Заранее уменьшили до 1 минуты5 минут1 часа за сколько часов до переезда не уменьшализа 1 чза 6 чза 24 чза 48 ч

Прошло после смены записи: 30 мин

• видит новый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер
• видит старый сервер

1 из 30 посетителей уже видят новый сервер, 29 всё ещё старый. Дольше всех старый ответ может жить около 24 ч. Сначала уменьшите TTL и подождите хотя бы прежний срок: пока он не истёк, кэши держат длинный ответ.

{W.dotsNote}

Проверьте себя: почему перед переездом TTL уменьшают заранее, а не в момент смены записи?

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

Переезд без простоя

Это обычный порядок, и он годится для любого сайта.

1. За двое суток уменьшите TTL записей, которые будете менять, до 300 секунд. Подождите не меньше прежнего срока: пока он не истёк, кэши держат длинный ответ.
2. Подготовьте новый сервер и проверьте его, не трогая DNS: у многих платформ есть временный адрес, а у вас на компьютере можно временно сопоставить имя и IP в файле hosts.
3. В назначенный час замените запись A (или значение CNAME) на новый адрес. С этой минуты новые запросы идут на новый сервер, старые догорают по мере истечения кэшей.
4. Проверьте: dig +short example.ru, из разных сетей (домашний интернет и мобильная сеть), на нескольких публичных резолверах. Не забудьте браузер и систему: у них свой кэш.
5. Подождите сутки, старый сервер не выключайте: часть посетителей ещё идёт на него. Потом верните TTL в разумное значение (час) и только после этого освобождайте старый хостинг.

Если что-то пошло не так, откат это та же правка в обратную сторону, и именно короткий TTL делает её быстрой. В этом и смысл подготовки.

Ошибки, которые стоят сайта

Есть неприятности, которые происходят не при переезде, а годами позже. Запомните четыре.

• Домен просрочен. Не оплатили продление, и сайт, почта и всё остальное исчезают. Включите автопродление и укажите почту, которую читаете.
• Аккаунт регистратора оформлен на подрядчика. Фрилансер «настроил всё» и записал домен на себя. Когда вы расстанетесь, домен может оказаться чужим. Домен регистрируют на вас или на вашу организацию, а подрядчику дают доступ к зоне.
• Одно письмо на всё. К почте, на которую оформлен регистратор, привязано восстановление всех паролей. Потеряли её, и вместе с ней потеряли домен.
• Забытые записи. После переезда на старый IP-адрес может прийти чужой сайт: этим пользуются злоумышленники. Удаляйте записи, которые больше не нужны.

Как смотреть самому

dig +short example.ru A        # адрес сайта
dig example.ru NS              # чья зона действует
dig @1.1.1.1 example.ru A      # ответ чужого резолвера, для сравнения
nslookup example.ru            # то же без dig (есть в Windows)

TTL в ответе уменьшается при повторных запросах: это остаток кэша, и по нему видно, как долго ещё проживёт старый ответ.

Практика

Перед вами ваш сайт, а под ним таблица зоны и план переезда. Впишите тип, значение и TTL для шести записей, затем в абзацах скажите, где живут языки из брифа и на кого оформлен домен, и распишите пять шагов переезда. Адрес для примеров возьмите из блока 192.0.2.x: это адреса для документации, настоящий сервер вам выдаст хостинг.

Что было не так раньше

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