Прямой ответ
DNS — телефонная книга интернета: иерархическая распределённая база «имя → данные», где разработчику нужны четыре вещи. Записи: A/AAAA (имя → IPv4/IPv6 адрес), CNAME (имя → другое имя — для указания на сервисы типа app.herokuapp.com), MX (почта домена), TXT (произвольный текст — подтверждение владения, SPF/DKIM), NS (кто авторитетен за зону). Резолвинг: ваш запрос идёт через рекурсивный резолвер (провайдера/1.1.1.1), который обходит иерархию — корень → зона .ru/.com → авторитетные серверы домена — и кеширует ответ на время TTL. TTL — время жизни записи в кешах: 300 секунд — норма для рабочих записей, 3600+ — для стабильных; переезд сервера начинается со снижения TTL за сутки (иначе клиенты держат старый адрес часами). Отладка: dig +short example.com (что отвечает), dig NS example.com (кто авторитетен), dig @1.1.1.1 (сравнение резолверов — «у меня не работает, а у соседа работает» почти всегда кеш). Понимание этой механики снимает большинство «магических» проблем деплоя: сайт «не переехал» — это почти всегда неотработавший TTL, а не сломанный сервер.
Записи: что и когда использовать
A/AAAA — базовая пара: сайт на своём сервере — A-запись на IP (+ AAAA при IPv6); www — либо отдельная A, либо CNAME на apex-имя (не наоборот — CNAME на www безопаснее при смене IP). CNAME — делегирование имени другому имени: обязательный паттерн для PaaS/CDN (app.example.com CNAME → your-app.provider.net): провайдер меняет свои IP — ваша запись не трогается; ограничение протокола — CNAME не может сосуществовать с другими записями на том же имени (apex-домен example.com с CNAME несовместим — отсюда ALIAS/ANAME-псевдонимы у провайдеров). MX с приоритетами — почтовые серверы (10 — основной, 20 — запасной: меньшее число приоритетнее); TXT — верификации («google-site-verification»), почтовая аутентификация (SPF/DKIM/DMARC — TXT-записи); NS — делегирование зоны (смена DNS-провайдера = смена NS у регистратора — самая «долгая» операция, до 24–48 часов по корневым кешам). Отдельные полезные: CAA (каким CA разрешено выпускать сертификаты домена — TLS-статья), SRV/TXT для service discovery — нишевые.
Резолвинг и кеши: почему «не сразу»
Путь запроса: приложение → системный резолвер → рекурсивный резолвер (кеш!) → корневые серверы (отсылают к .com-зоне) → TLD-серверы (отсылают к авторитетным NS домена) → авторитетный сервер (даёт запись). Кешируются ответы на каждом уровне на TTL записи: браузер, ОС, рекурсивный резолвер провайдера. Практические следствия: изменение записи видно не всем сразу (у кого-то закешировано старое — «у меня работает/не работает» — проверять через разные резолверы: dig @1.1.1.1, @8.8.8.8); отрицательное кеширование тоже существует (NXDOMAIN кешируется — опечатка в записи может «запомниться»); прогрев — после добавления записи первый запрос медленный (полный обход иерархии), далее — из кеша. Локальные исключения: /etc/hosts (разработка — локальный HTTPS) и корпоративные DNS-фильтры (переопределяют ответы — «в офисе сайт не открывается» без проблем у провайдера).
TTL и миграции: переезд без простоя
Сценарий переезда сервера — дисциплина TTL: за 24–48 часов снизить TTL целевых записей до 60–300 секунд (старые кеши с часовым TTL должны истечь до смены IP); поднять новый сервер и проверить по IP напрямую (curl с Host-заголовком или hosts-файл — прокси-настройка); переключить A-запись; наблюдать трафик на старом сервере (access-логи: пока идут запросы — часть клиентов на старом кеше — держать старый живым минимум старые TTL); через сутки поднять TTL обратно (низкий TTL — лишняя нагрузка на авторитетные серверы и медленнее ответы). Частые ошибки: смена IP при TTL 86400 (сутки «полуработы»), удаление старого сервера сразу (закешированные клиенты падают), смена NS одновременно с переездом (два независимых ожидания накладываются — миграции разносить). Для zero-downtime крупных переездов — взвешенные записи/CDN-проксирование (Cloudflare-оранжевое облако: IP скрыт за прокси, миграция бэкенда невидима клиентам).
Практический сценарий: деплой нового домена
Задача: сервис переезжает на свой VPS с доменом service.example.ru. Шаг 1 — зона: у регистратора/провайдера DNS создаём записи: A service → 203.0.113.10 (TTL 300), CNAME www.service → service.example.ru, при наличии почты — MX+TXT(SPF); проверка авторитетности — dig NS example.ru показывает серверы провайдера. Шаг 2 — сервер: nginx с server_name (виртуальные хосты), сертификат Let's Encrypt — выпуск требует, чтобы DNS уже работал (HTTP-01 валидация идёт по домену — порядок «сначала DNS, потом сертификат» обязателен; автопродление). Шаг 3 — проверка цепочки: dig +short service.example.ru → IP; curl -vI → сертификат и 200; с внешнего резолвера (@1.1.1.1`) — то же (проверка, что зона разошлась, а не только у регистратора). Шаг 4 — мониторинг сутки: старый хостинг показывает спад трафика до нуля — кеши отработали; фиксируем: полная доступность через ~2 часа (TTL был 300 — сошлось с ожиданием). Отладочная ветка сценария: «сайт открывается через раз» — dig с разных резолверов даёт разные IP — забыта старая A-запись (две A = round-robin между старым и новым сервером — классика); удаление лишней записи + TTL — проблема уходит.
FAQ
Почему dig показывает одно, а браузер другое?
Между ними кеши: ОС/браузер (сброс: очистка кеша DNS браузера, systemd-resolve --flush-caches/dscacheutil -flushcache), корпоративный резолвер-фильтр, VPN с своим DNS. Dig через явный резолвер (@1.1.1.1) показывает «объективную» картину — расхождение с браузером ищет промежуточный кеш.
Что такое DNS-пропагация и сколько ждать? Не магия, а истечение TTL в кешах: рабочая запись с TTL 300 расходится за минуты; смена NS-делегирования — до 24–48 часов (кеши TLD/корня живут долго). «Ждать пропагации» без снижения TTL заранее — добровольное удлинение миграции.
Нужен ли свой DNS-сервер? Практически никогда: DNS провайдера/Cloudflare надёжнее и с аналитикой; свой авторитетный сервер — ниша (внутренние зоны, специфические политики). Локальный dnsmasq/CoreDNS полезен в dev-средах и кластерах (Docker-сети), не для публичных зон.
Как быстро проверить, что домен «ожил» после покупки?
dig NS домен — вернул NS провайдера; whois домен — статус registered; A-запись и HTTP — по шагам сценария. «Домен куплен, сайт не работает» в 90% случаев — не созданы записи в зоне (покупка ≠ записи) или NS не переключены.
Источники: RFC 1034/1035 (DNS), материалы Cloudflare Learning — ссылки в шапке.