DNS для продакшена: latency, split-horizon и умный выбор NS-провайдера

DNS давно перестал быть просто «телефонной книгой интернета». Для современных проектов это полноценный уровень инфраструктуры, от которого зависят latency, отказоустойчивость, корректная работа e-mail и сложных схем роутинга трафика.

В этой статье разберём именно практическую часть: как выбирать NS-провайдера, почему важно измерять latency DNS, когда нужен split-horizon / split-view, и какие архитектуры зон имеют смысл для разных типов проектов.

При этом DNS остаётся одним из самых недооценённых компонентов: его редко мониторят, почти не версионируют и часто оставляют «как у регистратора по умолчанию».

Базовая модель DNS: что реально важно администратору

Схематично цепочка DNS-запроса к вашему домену выглядит так:

1. Клиент (браузер, мобильное приложение, скрипт) спрашивает у локального резолвера (обычно DNS-провайдер, корпоративный DNS, публичные резолверы и т.п.).
2. Резолвер при необходимости идёт к корневым серверам, затем к серверам доменной зоны (TLD), затем к авторитетным NS вашего домена.
3. Авторитетный NS отвечает IP-адресом (A/AAAA), данными MX, TXT и т.д., резолвер кэширует ответ на время TTL.

С точки зрения продакшена нас интересуют несколько ключевых параметров:

• latency DNS-запроса до ваших авторитетных NS;
• надёжность и отказоустойчивость NS-провайдера;
• поддержка современных фич: DNSSEC, GeoDNS, split-horizon, API для автоматизации;
• гибкость управления зонами (API, шаблоны, импорт/экспорт, массовые изменения).

Самая частая ошибка: считать DNS «одинаковым везде» и выбирать NS-провайдера только по цене или просто «где куплен домен».

Дополнительно важно, как именно NS-провайдер интегрируется с вашей инфраструктурой: может ли он автоматически подтверждать домены для SSL-сертификаты по DNS-01, поддерживает ли IaC-инструменты и аудиты изменений зон.

DNS latency и реальная скорость сайта

Для современного HTTP/2 и особенно HTTP/3 каждая миллисекунда на старте соединения важна. DNS-запрос — это первый сетевой шаг, который делает браузер перед тем, как обратиться к вашему сайту или API.

Из чего состоит задержка DNS

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

• к корневым серверам (.);
• к TLD-серверам (.ru, .com и т.д.);
• к авторитетным NS вашего домена.

Традиционно принято говорить о latency именно до авторитетного NS, потому что корневые и TLD-серверы обычно очень быстрые и распределённые по миру. Но на практике значимую долю времени могут съедать и дополнительные запросы к NS, если:

• зона фрагментирована, и разные поддомены делегированы на разные NS;
• часть ответов отдаётся по CNAME через другие домены и NS-провайдеров;
• TTL выставлены слишком низкие, кэш почти не помогает.

Резолвер использует кэш, так что для популярных доменов (фронты, статика, API) количество «холодных» запросов меньше. Но именно эти первые холодные хиты критичны для UX, особенно на мобильных сетях.

Какие цифры считать нормальными

Ориентиры для latency до авторитетных NS (средние по региону):

• до 20–30 мс — очень хорошо;
• 30–80 мс — допустимо для большинства проектов;
• >100 мс стабильно — ощутимо замедляет первый запрос, особенно в мобильном интернете.

Важно смотреть не только на среднее значение, но и на хвосты распределения (95–99-й перцентиль): плохие маршруты до отдельных NS могут «подпортить» картину.

Как измерять latency до NS

Для оценки производительности DNS можно использовать:

• dig, drill, kdig с ключом +trace или запросом конкретных NS;
• утилиты нагрузки на DNS, например dnsperf, resperf;
• глобальные тесты через внешние сервисы диагностики, которые используют точки по всему миру.

Примеры минимальных ручных проверок:

dig @ns1.example-dns.net example.com A +nocmd +noall +stats
kdig example.com A +trace

Сравнивайте результаты из разных регионов (VDS в разных ДЦ, VPN, коллеги из других стран). Это даёт понимание, насколько равномерно провайдер распределяет anycast-узлы NS и как это сказывается на вашей аудитории.

Выбор NS-провайдера: на что смотреть, кроме цены

Домены часто регистрируют у одного регистратора, хостинг берут у другого, а NS-провайдера выбирают «по умолчанию», даже не задумываясь. В результате в критичный момент вы можете упереться в функциональные ограничения панели или в плохую глобальную доступность NS.

Для продакшена желательно сразу отделять место, где вы делаете регистрация доменов, от места, где вы управляете зонами: NS-провайдера можно сменить без переноса домена.

Ключевые критерии выбора DNS-провайдера

• Геораспределение NS. Нужна ли вам глобальная аудитория или достаточно фокуса на одном регионе.
• Архитектура NS: anycast vs unicast, количество физических площадок.
• Поддержка DNSSEC и удобство включения/ротации ключей.
• Возможности геораспределённого роутинга (GeoDNS, latency-based routing, weighted records).
• Поддержка split-horizon / split-view, если планируете разное содержимое ответов для внутренних и внешних клиентов.
• API для автоматизации: выпуск сертификатов по DNS-01, CI/CD для зон, динамические записи.
• Лимиты: количество зон, записей, RPS, длина имён, размер TXT и т.п.
• Логирование и аудит изменений, возможность отката версий зоны (zone versioning).

В продакшене отсутствие API у NS-провайдера рано или поздно становится бутылочным горлышком: от DNS-01 до автоматизации blue-green релизов через DNS.

Если вы активно автоматизируете инфраструктуру, имеет смысл сразу выбирать провайдера с поддержкой Terraform/Ansible-модулей и хорошей документацией по API.

Anycast NS и влияние на latency

Современные NS-провайдеры почти всегда используют anycast: один и тот же IP анонсируется из нескольких дата-центров по миру, а трафик маршрутизируется по BGP до ближайшей точки.

Плюсы anycast для DNS:

• меньше latency для пользователей в разных регионах;
• лучше устойчивость к отказу отдельных площадок;
• часто — лучшая защита от DDoS за счёт рассредоточения трафика.

Но нужно понимать, что «anycast» в маркетинге ещё не гарантирует хорошую реальную латентность. Поэтому тесты из разных регионов остаются обязательными — особенно если вы рассчитываете на международную аудиторию или у вас несколько независимых фронтов на разных платформах (виртуальный хостинг, свой VDS, облако и т.п.).

TTL, кэширование и баланс между гибкостью и скоростью

TTL записей DNS сильно влияет на то, как быстро будут применяться изменения и насколько часто резолверы будут обращаться к NS. Это влияет и на latency (потому что запросов меньше), и на устойчивость (кратковременные проблемы NS могут перекрываться за счёт кэша).

Практические TTL-профили

Типичные рекомендации для продакшена:

• A/AAAA записей фронтов (web/API) — 300–1200 секунд. Если вы активно используете DNS в оркестрации (blue-green, canary), можно держать 60–300 секунд, но надо понимать нагрузку на NS.
• MX — 3600–86400 секунд. Почта менее чувствительна к медленному изменению MX, но критична к надёжности.
• TXT для SPF/DKIM/DMARC — 3600–86400, менять их часто редко приходится.
• NS записей зоны — обычно 86400; менять NS каждый день не должно быть нормой.

Для миграций (переезд сайта, смена NS, крупные изменения инфраструктуры) можно временно снижать TTL за сутки–двое до работ, а после успешного релиза возвращать более высокие значения.

Как TTL влияет на latency в реальности

Интуитивно кажется: чем ниже TTL, тем выше суммарное количество запросов к NS, а значит чаще будет «дорогой» DNS-запрос. Это верно, но с поправкой на популярность домена:

• для высоконагруженных проектов популярные домены почти всегда в кэше у крупных резолверов;
• при TTL в 300–600 секунд разница в UX между «почти всегда в кэше» и «иногда холодные запросы» обычно мала;
• зато низкий TTL позволяет гибко рулить трафиком через DNS, в том числе использовать weighted / latency / GeoDNS-паттерны.

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

Split-horizon / split-view DNS: когда внешний и внутренний мир должны видеть разное

Split-horizon (он же split-view) — это схема, при которой один и тот же домен (или поддомен) возвращает разные ответы в зависимости от того, кто спрашивает. Типичный пример: внутри офиса сотрудники видят внутренние IP серверов, а внешние пользователи — публичные.

Задачи, которые решает split-horizon DNS

• Разделение внутренней и внешней адресации. Внутри сети — RFC1918 адреса (10.x, 192.168.x), снаружи — публичные IP.
• Оптимальный роутинг. Внутренние сервисы ходят по короткому приватному пути, а не через публичный интернет или VPN.
• Скрытие внутренней топологии от внешних пользователей: во внешнем DNS показываются только фронтовые ноды, а все внутренние сервисы видны только внутри.
• Особые политики для админских зон: одни и те же домены могут отдавать разные MX, SRV и т.д. для внутренних агентов.

Важно: split-horizon — не про безопасность как таковую. Это в первую очередь вопрос архитектуры и удобства, а не полноценная защита от атакующего.

Частая ошибка — пытаться «спрятать» сервисы только за счёт split-view, не закрывая их на уровне сетевых политик и аутентификации.

Как обычно реализуют split-horizon

Есть две базовые архитектуры:

1. Отдельные DNS-серверы внутри инфраструктуры, обслуживающие «внутренний» вид зоны.
   • Внешние NS — у публичного провайдера, работают для всего мира.
   • Внутренние резолверы (в офисе, в VPC) настроены так, чтобы использовать ваши внутренние авторитетные NS для домена.
2. NS-провайдер с поддержкой views / split-horizon.
   • Провайдер даёт возможность создавать несколько «видов» зоны.
   • Определённые сети (по IP/ASN) получают один набор записей, остальные — другой.

В первом случае вы полностью контролируете внутреннюю часть, но отвечаете за её отказоустойчивость сами. Во втором — полагаетесь на возможности провайдера и его глобальную сеть.

Типичные сценарии использования split-view

• Корпоративная сеть + внешний сайт.
  • Внутри компании app.example.com резолвится в 10.0.0.10 (внутренний кластер).
  • Снаружи — в 203.0.113.10 (публичный балансировщик).
• Гибрид: on-prem + облако.
  • Внешние пользователи ходят в облачный фронт.
  • Внутренние сервисы ходят на on-prem IP напрямую, но под теми же доменными именами.
• Тестовые и стейджинг-среды.
  • Для внешнего мира зона содержит только прод-ресурсы.
  • Внутри — те же имена могут указывать на стейджинг окружение (осторожно, чтобы не перепутать).

Последний сценарий особенно опасен: легко случайно отправить пользователей на тестовый фронт или наоборот. Обычно для стейджинга используют отдельные домены или поддомены и явно помечают их в интерфейсах и конфигурации.

Ограничения и риски split-horizon

При использовании split-view важно помнить:

• Диагностика усложняется: внешний мониторинг видит одно, внутренние агенты — другое.
• Автоматизация (CI/CD, Terraform, Ansible) должна осознанно работать с несколькими «видами» зон.
• Клиенты вне ожидаемых сетей (например, мобильные сотрудники) могут получить «не тот» ответ, если резолвер не попадает под правила.
• DNSSEC с split-horizon требует аккуратности: подписывать обе версии зоны, следить за консистентностью.

Если ваша задача — просто гибко рулить трафиком между дата-центрами или CDN, возможно, лучше подойдёт GeoDNS / latency-based routing без split-horizon в классическом понимании.

GeoDNS, latency-based routing и NS с «умным» выбором ответа

Многие NS-провайдеры предлагают расширенные типы записей и политики, которые позволяют на уровне DNS балансировать трафик:

• GeoDNS: разные IP в ответ в зависимости от геолокации резолвера (по IP / ASN / стране / региону).
• Latency-based routing: выбор ближайшего узла по измеренной latency между точками провайдера и вашими бэкендами.
• Weighted records: взвешенное распределение трафика между несколькими IP (например, A-записи с весами).
• Failover records: при недоступности основного IP NS начинает отдавать резервный.

Когда GeoDNS оправдан, а когда нет

GeoDNS имеет смысл, если:

• у вас есть несколько площадок / кластеров в разных регионах;
• вы можете обслуживать пользователей из «ближайшего» дата-центра;
• у вас есть мониторинг доступности каждой площадки, интегрированный с NS-провайдером.

Если инфраструктура фактически одна (один ЦОД или одна зона в облаке), GeoDNS не даст реальной пользы; проще и надёжнее использовать обычные записи, а масштабирование реализовать на L7-балансерах или внутри оркестратора.

DNS failover: плюсы и подводные камни

Многие надеются, что «DNS сам переключит трафик при падении фронта», но это работает не так просто:

• NS-провайдер должен иметь встроенный мониторинг ваших узлов (health checks).
• Переключение ограничено TTL: пока резолверы не сбросят кэш, пользователи продолжают попадать на старый IP.
• Некоторые резолверы могут игнорировать слишком низкий TTL или переиспользовать закэшированные данные дольше ожидаемого.

DNS failover хорош как дополнительный защитный слой, но не может заменить корректный L4/L7-балансировщик с healthcheck внутри вашей инфраструктуры. Особенно это критично для проектов, где RTO измеряется секундами, а не минутами.

Архитектура NS и зон для разных типов проектов

Построим несколько типовых сценариев с учётом latency, split-horizon и возможностей NS-провайдеров.

Небольшой сайт / лендинг / визитка

Цели: простота, минимальные затраты времени, отсутствие сложных схем split-horizon.

• Используем NS-провайдера с нормальной географией NS (хотя бы несколько точек в нужном регионе).
• TTL A/AAAA около 3600 секунд; MX/TXT/NS — 86400.
• Никакого split-horizon; внутреннюю сеть (если есть) обслуживаем через отдельную внутреннюю зону вида corp.example.local.

Этого достаточно, чтобы не ломать голову лишний раз и при этом не страдать от чрезмерно долгих миграций (TTL в 1 час хорошо переживаем). Для таких проектов нередко достаточно NS, которые идут в комплекте с услугой купить хостинг.

Средний проект с API, несколькими окружениями и разными командами

Цели: гибкая миграция, автоматизация, осознанная работа с latency.

• Выбираем NS-провайдера с API, поддержкой GeoDNS / weighted records (по необходимости) и нормальной статистикой/аудитом изменений.
• Разделяем окружения по поддоменам: api.example.com, staging.example.com, admin.example.com.
• TTL для критичных фронтов — 300–600 секунд (для более комфортных релизов через DNS).
• Используем weighted A/AAAA для мягкого перевода трафика между новыми и старыми нодами (canary / blue-green через DNS).

Split-horizon обычно не требуется: все окружения доступны по своим поддоменам, а внутренние сервисы — по отдельному внутреннему домену. Здесь особенно удобно описывать зоны в Terraform/Ansible и хранить их рядом с кодом инфраструктуры.

Крупный продукт с несколькими регионами и гибридной инфраструктурой

Цели: минимальный latency для пользователей в разных странах, гибрид on-prem + облако, кластеры в нескольких регионах.

• NS-провайдер обязательно с anycast-сетью, GeoDNS и latency-based routing.
• Основной домен example.com обслуживает пользователей по миру, используя GeoDNS для разных регионов.
• Внутренние сервисы в on-prem и облаке доступны через split-horizon: внутренние резолверы видят приватные IP, внешние — публичные.
• Terraform/Ansible управляет всеми «видами» зон из одного репозитория, с чётко разделёнными ресурсами для внутреннего и внешнего мира.

Здесь уже действительно оправдан split-view: он экономит трафик, уменьшает задержки для внутренних сервисов и позволяет использовать те же доменные имена для внутренних и внешних сценариев. Не забывайте регулярно проверять зону из внешних и внутренних точек мониторинга, чтобы поймать рассинхронизацию.

Практические советы по эксплуатации DNS в продакшене

Логируйте и мониторьте DNS как полноценный сервис

Даже если вы не управляете авторитетным NS сами, вы можете и должны:

• собирать метрики успешности резолвинга домена и медианы latency из разных регионов;
• контролировать ошибки резолвинга на уровне приложений (например, таймауты DNS-запросов в логах API);
• иметь alerting на изменение NS / SOA / критичных A/AAAA/MX записей.

Это помогает вовремя заметить проблемы у NS-провайдера или некорректные правки в зоне. Для доменов, связанных с брендом и безопасностью, стоит также продумать процессы, описанные в материале о защите бренда на уровне доменов.

Не смешивайте тестовые эксперименты с боевыми зонами

Очень часто попытки «поиграться с split-horizon» на боевом домене заканчиваются тем, что:

• часть пользователей видит тестовую версию;
• мониторинг (который ходит через отдельные резолверы) не видит реальные проблемы;
• часть сервисов перестаёт находить нужные хосты из‑за разных ответов.

Если вы хотите освоить split-view, заведите отдельный тестовый домен и NS-зону. Только после того, как процесс станет предсказуемым и автоматизированным, переносите подход в продакшен.

Автоматизируйте управление DNS-зонами

Как только зона выходит за рамки «пара A-записей и один MX», её нужно описывать как код:

• использовать Terraform / Ansible / собственные скрипты поверх API NS-провайдера;
• хранить конфигурацию зоны в репозитории с ревью, историями изменений и откатами;
• иметь чётко прописанные процессы: кто и как вносит изменения, как они тестируются, как откатываются.

Это особенно важно, если вы используете split-horizon, GeoDNS, сложные наборы CNAME/ALIAS, записи для почты, VoIP и десятки сервисов. Для автоматизации выпуска сертификатов по DNS-01 можно дополнительно почитать статью о Wildcard и DNS-01 для автоматизации SSL.

Выводы

DNS для продакшена — это не только про «записал A-запись и забыл». От выбора NS-провайдера, настроек TTL, наличия GeoDNS и split-horizon напрямую зависят:

• latency первого запроса к сайту или API;
• устойчивость к сбоям и миграциям инфраструктуры;
• удобство работы команд разработки, эксплуатации и безопасности.

Подход «по умолчанию у регистратора» может работать для простых сайтов, но как только проект растёт — инвестировать время в осмысленную DNS-архитектуру становится критически важно. Измеряйте latency, тестируйте NS из разных регионов, планируйте TTL, внедряйте автоматизацию и используйте split-horizon только там, где он действительно решает ваши задачи, а не добавляет лишнюю сложность.