Зачем разбираться: Domain Connect не «магия»
Если вы администрируете сайт, почту или SaaS с «подключаемыми» доменами, в какой-то момент вы неизбежно сталкиваетесь с одним и тем же набором сущностей: Domain Connect, делегация DNS, NS, TTL, DS и DNSSEC. В интерфейсах это выглядит как разные переключатели, но на уровне протокола всё сводится к двум задачам.
Делегация: куда родительская зона (TLD вроде .ru/.com) направляет запросы — то есть какие NS авторитетны для вашего домена.
Цепочка доверия: как валидирующий резолвер доказывает, что ответ не подменён — то есть DNSSEC и DS.
Domain Connect пытается автоматизировать первую часть (а иногда и вторую), но если автоматизация не сработала, именно вам придётся понять, где разошлись реальность и ожидания: на стороне регистратора, авторитетных NS или в кэше рекурсоров.
Базовая модель: кто за что отвечает
Держите в голове простую схему — она экономит часы при инцидентах.
Регистратор управляет «родительской» частью: делегацией (NS домена) и, если включён DNSSEC, DS-записью(ями) в родительской зоне.
Авторитетный DNS хранит вашу зону (A/AAAA/CNAME/MX/TXT и т. д.), а при DNSSEC — ещё DNSKEY/RRSIG/NSEC(3).
Рекурсивный резолвер (провайдера, корпоративный, публичный) ходит по цепочке: корневые → TLD → авторитетные NS → кэширует ответы на время TTL.
Практический вывод: NS/делегация меняются у регистратора, а записи внутри зоны меняются у DNS-провайдера. TTL определяет, как долго «мир будет помнить старое» после изменений.
Если вы регулярно работаете с доменами (делегация, переносы, продления), полезно иметь отдельный чек-лист по операциям у регистратора. См. также материал про перенос домена и что он делает с DNS/NS.
Delegation и NS: что означает «прописать NS» на практике
Делегация — это запись в родительской зоне, которая говорит всему интернету: «за ответы для example.com отвечают такие-то name server». Когда вы меняете NS у регистратора, вы меняете именно делегацию. Старые DNS-записи на прежних NS становятся неактуальными не потому, что они удалились, а потому что запросы к ним больше не доходят.
Типовая ошибка: NS поменяли, а зона на новых NS пустая
Симптом: у части пользователей «всё работает», у части — «сайт/почта пропали». Причина почти всегда в кэше: кто-то ещё использует старые NS (или старые ответы), а кто-то уже ходит на новые NS, где нет нужных записей. Это часто выглядит как «флаттеринг» — плавающая доступность.
Как проверить делегацию (без гаданий)
Сначала смотрим, какие NS отдаёт родитель (то есть что реально делегировано):
dig +noall +answer NS example.comДальше — трассировка цепочки. Это лучший способ увидеть, где именно вы «свернули не туда»:
dig +trace example.com AЕсли в конце трассы вы видите не те NS, которые ожидали, значит изменения у регистратора ещё не применились, применились не к тому домену или вы проверяете не ту зону (например, домен в другом аккаунте/у другого регистратора).
Glue-записи: когда без них делегация ломается
Если NS находятся внутри делегируемого домена (например, ns1.example.com), родительская зона должна знать их IP-адреса. Иначе возникает «курица и яйцо»: чтобы узнать IP NS, надо спросить NS, но чтобы спросить NS, надо знать IP.
На стороне регистратора это оформляется как glue records (или «host records», «дочерние NS»). Практический смысл: родитель отдаёт не только имена NS, но и A/AAAA для них.
Быстрая проверка — посмотреть, есть ли дополнительные данные (ADDITIONAL) в ответе:
dig NS example.com +norecurseЕсли glue не настроен (или настроен на неверные IP), делегация может быть нестабильной или полностью неработоспособной.
TTL в DNS: почему «поставил 60 секунд» не всегда сработает
TTL — время жизни записи в кэше рекурсора. Это ключевой параметр при миграциях, смене IP, переезде на новый CDN, переключении MX. Но важно помнить два нюанса.
TTL влияет только на новые кэширования. Если у пользователя уже лежит старый ответ с большим TTL, он будет жить до конца своего времени.
У рекурсоров бывают политики. Кто-то «режет» слишком маленький TTL (например, не ниже 60), кто-то в аварийных режимах дольше держит кэш, если авторитетный сервер отвечает нестабильно.
Практика TTL перед переключением
За 24–48 часов уменьшите TTL на ключевых записях (A/AAAA/CNAME, при необходимости MX) до 60–300.
Дайте времени пройти, чтобы старый высокий TTL «вышел» из кэшей.
После миграции верните TTL к разумным значениям (часто 300–3600 — в зависимости от того, как часто вы меняете записи и насколько критична «быстрая раскатка»).
Посмотреть TTL можно прямо в ответе dig (число перед значением записи):
dig +noall +answer example.com ADomain Connect: что он реально настраивает и где ломается
Domain Connect — стандарт, позволяющий сервису (хостинг, конструктор, CDN, почтовый провайдер) автоматически выставить DNS-настройки у поддерживаемого регистратора или DNS-провайдера. На практике это обычно означает:
добавление или изменение записей в зоне (A/AAAA/CNAME/TXT/MX);
иногда — смену NS (это реже и зависит от конкретной интеграции);
в отдельных реализациях — помощь с DNSSEC (если у регистратора/провайдера есть подходящий API и сценарий).
Плюс — меньше ручного копипаста и меньше типовых ошибок. Минус — при сбое становится непонятно, где искать причину, если вы не разделяете в голове делегацию, зону и кэш.
Частые причины сбоя Domain Connect
Несовпадение ожиданий: сервис думает, что управляет зоной, но домен делегирован на другие NS.
Доступы: домен в другом аккаунте, нет подтверждения владения, отключён API, не хватает прав.
Конфликт записей: например, сервис хочет поставить CNAME на
@, а там уже есть A; или TXT-верификация уже занята другим сервисом.Кэш: записи обновились, но часть пользователей ещё видит старое из-за TTL.
DNSSEC и DS: почему «включается в двух местах»
DNSSEC добавляет криптографическую подпись к данным DNS, чтобы валидирующий резолвер мог проверить целостность и происхождение ответа. Но это работает только как цепочка доверия от корня до вашей зоны.
DS — связка между родительской зоной (TLD) и вашей зоной: в родителе публикуется «отпечаток» ключа (точнее, DNSKEY вашей зоны). Поэтому DS живёт у регистратора, а ключи и подписи — у вашего DNS-провайдера.
Практическое правило: DNSSEC — это всегда «две половины»: подписанная зона у DNS-провайдера и DS у регистратора. Сделали только половину — готовьтесь к
SERVFAILу валидирующих резолверов.
Типовой сценарий поломки DNSSEC
Самый частый инцидент выглядит так: вы сменили DNS-провайдера (или у провайдера сменились ключи), а DS у регистратора остался старым. В результате валидирующие резолверы видят DS, пытаются проверить подписи, получают несоответствие и отвечают SERVFAIL. При этом «у кого-то работает» (без валидации), а «у кого-то нет» (с валидацией).
Как посмотреть DS и DNSKEY
Проверяем DS в родительской зоне (если DS опубликован, он вернётся):
dig +noall +answer DS example.comПроверяем DNSKEY в вашей зоне:
dig +noall +answer DNSKEY example.comИ полезная «быстрая диагностика глазами» — запрос с DNSSEC-данными:
dig +dnssec example.com AПочему «скопировал не то поле» тоже кладёт домен
DS состоит из нескольких параметров (key tag, algorithm, digest type, digest). Ошибка в любом поле или DS «не от того ключа» приводит к той же картине: валидирующие резолверы уходят в SERVFAIL.
Поэтому совет максимально практичный: берите DS целиком в панели DNS-провайдера, где генерируются ключи, и вставляйте его у регистратора как готовое значение, а не «собирайте» по частям.
Смена DNS-провайдера: как не устроить DNSSEC-аварию
Если вы меняете авторитетные NS (то есть делегацию) и при этом у домена включён DNSSEC, порядок действий критичен. Консервативная схема, которая подходит большинству проектов (без сложных KSK/ZSK rollover и двойной подписи), такая:
На старом провайдере выключить DNSSEC (или подготовить план удаления DS).
У регистратора удалить DS и дождаться, пока он исчезнет из родительской зоны.
Сменить NS (делегацию) на новые.
Проверить, что новые NS отдают корректные записи зоны.
Включить DNSSEC на новом провайдере и добавить новый DS у регистратора.
Да, это означает окно без DNSSEC. Но для многих проектов это лучше, чем риск массового SERVFAIL и простоя. Если нужно мигрировать без снятия DNSSEC, планируйте rollover отдельно и проверяйте, поддерживают ли оба провайдера нужный сценарий.
Диагностика: быстрый чек-лист
1) Делегация правильная?
dig +noall +answer NS example.com
dig +trace example.com A2) Новые NS реально отдают то, что вы ожидаете?
Запросите записи напрямую у конкретного NS (подставьте имя сервера):
dig @ns1.your-ns.tld example.com A
dig @ns1.your-ns.tld www.example.com CNAME
dig @ns1.your-ns.tld example.com MX3) Не упираетесь ли вы в кэш и TTL?
Смотрите TTL в ответе и сравнивайте ответы от разных резолверов (локального, корпоративного, у провайдера). Сброс кэша помогает только там, где резолвер под вашим управлением; для внешних пользователей работает только ожидание TTL.
4) Подозрение на DNSSEC: сразу DS и DNSKEY
dig +noall +answer DS example.com
dig +noall +answer DNSKEY example.com
dig +dnssec example.com AЕсли DS есть, а зона не подписана или ключи не совпадают с тем, что ожидается, это почти гарантированный кандидат на SERVFAIL у валидирующих резолверов.
Практические советы: как сочетать Domain Connect и ручное управление
В продакшене часто живут в гибриде: часть записей выставляет сервис через Domain Connect, а часть вы ведёте вручную (SPF/DKIM/DMARC, ACME DNS-01, отдельные A/AAAA для инфраструктуры, делегирование поддоменов).
Фиксируйте «источник правды»: где меняются NS (регистратор), где редактируется зона (конкретный DNS-провайдер), у кого доступ.
Не делайте «быструю смену NS» без экспорта/импорта зоны и проверки, что записи идентичны на новых NS.
Для критичных доменов документируйте DNSSEC: включён ли, где лежит DS, кто отвечает за rollover и в какие сроки.
Перед подключением нового сервиса через Domain Connect проверьте, управляет ли он именно той зоной, которая реально обслуживает домен после делегации.
Если у вас используются поддомены с отдельной делегацией (например, api.example.com на другом DNS), держите отдельный регламент. См. также заметку про делегацию поддоменов через NS.
Итоги: «якоря» для ежедневной админки
NS/делегация — у регистратора, это маршрут к вашей зоне.
Записи зоны — у авторитетного DNS, это содержимое зоны.
TTL — не «скорость применить изменения», а «сколько времени пользователи будут видеть старое из кэша».
DNSSEC — всегда пара: подпись зоны + DS у регистратора.
Domain Connect экономит время, но не отменяет навыка проверить
dig +traceи понять, на каком шаге сломалась цепочка.
Когда эти части складываются в одну картину, любые «не открывается сайт после смены DNS», «почта не приходит после миграции», «SERVFAIL у части пользователей» превращаются из гадания в последовательную диагностику.
