Домены и DNS

01Три разные роли: регистратор, nameserver'ы, DNS-хостинг

Их часто путают, потому что все три может делать одна компания. Регистратор — это место, где вы покупаете и продлеваете домен (например, Namecheap, Porkbun или Cloudflare Registrar); он взаимодействует с реестром, который управляет TLD, например .com. В панели регистратора вы указываете, какие nameserver'ы авторитативны для вашего домена. Nameserver'ы принадлежат DNS-хостингу, а DNS-хостинг — это место, где живут сами записи: A, CNAME, MX и так далее. То есть можно купить домен у одного регистратора, направить его nameserver'ы на Cloudflare и управлять всеми записями в Cloudflare. Если вы редактируете записи у регистратора, а nameserver'ы указывают на другого провайдера, ничего не произойдёт, — это очень частая причина путаницы. Аналогия: регистратор — это земельный кадастр, nameserver'ы — табличка, какая контора хранит адресную книгу, а DNS-хостинг — сама эта контора.

• Регистратор: владение, продление, настройка nameserver'ов, контакты WHOIS/RDAP, блокировка трансфера.
• Nameserver'ы: какой DNS-провайдер авторитативно отвечает за домен.
• DNS-хостинг: сами записи.

02Как работает DNS-запрос

Ваше устройство спрашивает рекурсивный резолвер (провайдера, 1.1.1.1, 8.8.8.8). Если ответа нет в кэше, резолвер спрашивает корневой сервер, где находится .com, затем спрашивает серверы .com, какие nameserver'ы обслуживают example.com, а затем запрашивает запись у этих авторитативных nameserver'ов. Каждый ответ кэшируется на его TTL (time to live) в секундах. В следующий раз любой пользователь этого резолвера мгновенно получит ответ из кэша. Именно благодаря кэшированию DNS масштабируется на весь интернет — и именно поэтому изменения видны не везде одновременно.

1# Ask a specific resolver, then follow the whole chain
2dig example.com A @1.1.1.1
3dig +trace example.com
4# Which nameservers are authoritative?
5dig example.com NS +short
6# Ask the authoritative server directly (skips caches)
7dig example.com A @ns1.example-dns.net +short

03Типы записей, которые вам реально понадобятся

A сопоставляет имя с IPv4-адресом, AAAA — с IPv6. CNAME делает одно имя псевдонимом другого; его нельзя ставить на корневой домен (apex) рядом с другими записями, поэтому провайдеры предлагают для apex ALIAS, ANAME или CNAME flattening. MX сообщает миру, какие серверы принимают почту, с приоритетом (меньший пробуется первым). TXT хранит текст и используется для подтверждения домена и безопасности почты: SPF перечисляет, кто может отправлять почту от вашего имени, DKIM публикует ключ подписи, DMARC говорит получателям, что делать с письмами, не прошедшими проверку. NS делегирует зону, CAA ограничивает, какие центры сертификации могут выпускать сертификаты для вашего домена, а SRV описывает сервисы с портом. У каждой записи есть имя, тип, значение и TTL.

1example.com.        300  IN A      203.0.113.10
2example.com.        300  IN AAAA   2001:db8::10
3www.example.com.    300  IN CNAME  example.com.
4example.com.        3600 IN MX     10 mail.example-mail.com.
5example.com.        3600 IN TXT    "v=spf1 include:_spf.example-mail.com -all"
6_dmarc.example.com. 3600 IN TXT    "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
7example.com.        3600 IN CAA    0 issue "letsencrypt.org"

04TTL и «распространение»

На самом деле DNS не «распространяется» — истекают кэши. Если у записи TTL 86400 (одни сутки), резолвер, закэшировавший старое значение, может использовать его ещё до суток после изменения. Смена nameserver'ов идёт ещё медленнее, потому что у делегирования на уровне TLD TTL часто составляет сутки-двое. Практический рецепт для миграции: понизить TTL до 300 секунд как минимум за один период старого TTL до переключения, внести изменение, проверить с нескольких резолверов и снова поднять TTL, когда всё стабилизируется. Некоторые резолверы кэшируют и отрицательные ответы («такого имени нет») согласно SOA-записи, поэтому создавайте записи до того, как объявляете о них.

• 300 с для записей, которые скоро могут поменяться; 3600 с и больше — для стабильных.
• Проверяйте с нескольких резолверов, а не только со своего ноутбука.
• Кэши браузера и ОС могут хранить старые ответы; сбросьте их или проверяйте через dig.

05Проверка записей через dig и nslookup

dig — стандартный инструмент в Linux и macOS; nslookup работает везде, включая Windows. Всегда проверяйте и авторитативный ответ, и публичный резолвер, чтобы понять, проблема в вашей записи или в кэше. Для почты проверяйте MX и TXT-записи SPF, DKIM (на поддомене селектора) и DMARC. Для сертификатов — CAA. Онлайн-сервисы, которые делают запросы из разных стран, помогают убедиться, что изменение дошло до большинства резолверов. Флаг +short выводит только ответ, что удобно в скриптах и ранбуках.

1dig +short example.com A
2dig +short www.example.com CNAME
3dig +short example.com MX
4dig +short example.com TXT
5dig +short selector1._domainkey.example.com TXT
6nslookup -type=MX example.com 8.8.8.8
7# Windows / PowerShell
8Resolve-DnsName example.com -Type A -Server 1.1.1.1

06Советы для продакшена

Относитесь к самому домену как к критической инфраструктуре. Включите автопродление и блокировку у регистратора, используйте аккаунт с двухфакторной аутентификацией и указывайте контактный email на ящике, который у вас останется и через пять лет. Включите DNSSEC, если его поддерживают регистратор и DNS-хостинг, чтобы ответы нельзя было подделать. Храните экспортированную копию файла зоны. Перед сменой nameserver'ов сначала воссоздайте все записи у нового хостинга, особенно MX и TXT, иначе почта молча сломается. Удаляйте «висячие» записи, указывающие на сервисы, которыми вы больше не пользуетесь, — их могут перехватить другие.

07Делегирование, glue-записи и SOA

Зона — это часть дерева DNS, за которую отвечает один набор nameserver. Зона .com не хранит вашу A-запись; она хранит NS-записи, которые делегируют example.com вашим nameserver. Если ваши nameserver находятся внутри того же домена (ns1.example.com), возникает проблема курицы и яйца, поэтому родительская зона хранит также их IP-адреса в виде glue-записей, которые задаются у регистратора. Каждая зона начинается с SOA-записи: основной nameserver, контакт, серийный номер, по которому secondary понимают, когда забирать обновления, и TTL негативного кэширования. Последнее значение определяет, как долго резолверы помнят, что имени не существует. Lame delegation случается, когда родитель указывает на nameserver, которые на самом деле не отвечают за зону, и из-за этого у части резолверов запросы медленные или падают.

1# Delegation as seen by the .com servers
2dig example.com NS @a.gtld-servers.net +norecurse
3# SOA: primary NS, serial, refresh, retry, expire, negative TTL
4dig example.com SOA +short
5# A name that does not exist returns NXDOMAIN plus the SOA
6dig nothing-here.example.com A

08DNSSEC: подпись ответов

Классический DNS не может доказать, что ответ подлинный, поэтому атака cache poisoning могла бы отправить пользователей на поддельный IP. DNSSEC добавляет подписи. Ваш DNS-хостинг подписывает каждый набор записей (записи RRSIG) ключом зоны, опубликованным как запись DNSKEY. Родительская зона хранит запись DS — хэш вашего ключа, который вы добавляете у регистратора. Валидирующие резолверы проходят цепочку: от ключа корня к .com, к вашему DS, к вашему DNSKEY, к подписи ответа. Если что-то не совпадает, резолвер вместо поддельного ответа возвращает SERVFAIL. Эксплуатационный риск в том, что несовпадение ломает и легитимный домен: переезд на другой DNS-хостинг без предварительного удаления или обновления DS-записи выключает домен для всех валидирующих резолверов. Ротацию ключей берут на себя managed-провайдеры; ваша задача — запись DS.

1dig example.com DNSKEY +dnssec +short
2dig example.com DS +short          # what the parent publishes
3dig example.com A +dnssec          # look for the "ad" flag from a validating resolver
4# Online: dnsviz.net shows the full chain of trust

09Современные записи: HTTPS/SVCB, детали CAA и serve-stale

Запись HTTPS (RFC 9460, разновидность SVCB) позволяет домену ещё до подключения сообщить браузеру, какие протоколы он поддерживает (например, h3 и h2), альтернативные порты, IP-подсказки и ключи для Encrypted Client Hello. Её также можно поставить на apex и указать на другой hostname, что частично решает старую проблему CNAME на apex для поддерживающих браузеров. Cloudflare и другие провайдеры публикуют её автоматически для проксируемых hostname. Записи CAA могут также содержать iodef (куда CA сообщают об отклонённых запросах) и issuewild (какой CA может выпускать wildcard). На стороне резолверов многие реализации следуют serve-stale (RFC 8767): если ваши авторитетные серверы недоступны, они могут ещё какое-то время отдавать просроченные ответы. Это повышает доступность во время сбоев, но означает, что очень короткий TTL никогда не гарантирует быстрый failover.

1dig example.com HTTPS +short
2# 1 . alpn="h3,h2" ipv4hint=203.0.113.10
3dig example.com CAA +short
4# 0 issue "letsencrypt.org"
5# 0 issuewild ";"          <- nobody may issue wildcards
6# 0 iodef "mailto:[email protected]"

10Безопасность: takeover, гигиена зоны и anycast

Subdomain takeover случается, когда запись, обычно CNAME, указывает на удалённый вами сторонний ресурс — бакет в облачном хранилище, PaaS-приложение или сервис лендингов. Кто-то другой занимает это имя ресурса и теперь отдаёт контент на вашем поддомене, причём ваши cookie попадают в его область видимости. Предотвращайте это: удаляйте DNS-записи до удаления ресурса или вместе с ним и регулярно проводите аудит зоны. Другие правила гигиены: никогда не разрешайте открытый трансфер зоны (AXFR) кому попало, избегайте wildcard-записей, если они не нужны специально, и не держите внутренние hostname в публичном DNS — они раскрывают карту вашей сети. Для устойчивости хорошие DNS-провайдеры используют anycast: один и тот же IP nameserver анонсируется из многих точек, поэтому запросы идут к ближайшей живой площадке, а крупные флуды распределяются.