DNS-менеджмент и маршрутизация

Краткое резюме

DNS — это «роутер уровня имен». От грамотного TTL, зон и политик зависит, насколько быстро и предсказуемо пользователи попадут на нужные фронты/шлюзы. Минимальный набор: Anycast-провайдер, здоровые TTL, health-checks с автоматическим failover, DNSSEC + CAA, IaC-управление и наблюдаемость (SLO по ответам и времени резолва).

Базовая архитектура

Авторитетные сервера (zones) — отвечают за домены компании.
Рекурсивные резолверы (clients/ISP/собственные) — спрашивают корень → TLD → авторитетные.
Anycast — одна и та же IP-адресация на множестве PoP: ближний PoP отвечает быстрее и переживает аварии.

Зоны и делегирование

Корневая зона домена → `NS` на провайдеров авторитетных серверов.
Поддомены (например, `api.example.com`) можно делегировать на отдельные `NS`/провайдеры для независимости.

Типы записей (минимум)

`A`/`AAAA` — IPv4/IPv6 адреса.
`CNAME` — псевдоним на имя; не используйте на корне зоны (вместо этого ALIAS/ANAME у провайдеров).
`TXT` — верификации, SPF, custom-метки.
`MX` — почта (если используется).
`SRV` — сервисы (SIP, LDAP и т. п.).
`CAA` — кто может выпускать сертификаты для домена.
`NS`/`SOA` — делегирование/параметры зоны.
`DS` — ключи DNSSEC на родительский TLD.

Пример зоны (фрагмент)

$TTL 300
@    IN SOA ns1.dns.example. noc.example. (2025110501 3600 600 604800 300)
IN NS ns1.dns.example.
IN NS ns2.dns.example.
@    IN A  203.0.113.10
@    IN AAAA 2001:db8::10 api   IN CNAME api-prod.global.example.
_www  IN CNAME cdn.example.net.
_caa  IN CAA 0 issue "letsencrypt.org"

TTL и кэширование

Короткий TTL (30–300 c) — для динамики (API-фронты, failover).
Средний TTL (300–3600 c) — для CDN/статики.
Длинный TTL (≥ 1 день) — для редких изменений (MX/NS/DS).
Планируя миграции, снизьте TTL за 24–72 часа заранее.
Учитывайте Negative Caching TTL (NXDOMAIN): управляется `SOA MINIMUM`.

Политики маршрутизации (GSLB-уровень)

Failover (active/passive) — отдаем основной IP до фейла health-check’ом, потом резерв.
Weighted (traffic-split) — распределение трафика (например, canary 5/95).
Latency-based — ближайший по сетевой задержке PoP/регион.
Geo-routing — по стране/континенту; полезно для локальных законов/PCI/PII.
Multivalue — несколько `A/AAAA` с проверками здоровья каждого.

Советы

Для критичных API соединяйте latency-based + health-checks + короткий TTL.
Для плавных релизов — weighted и постепенный рост доли.
Для региональных ограничений — geo и списки разрешенных провайдеров.

Здоровье и автоматическое переключение

Health-checks: HTTP(S) (200 OK, тело/заголовок), TCP (порт), ICMP.
Репутация/фингерпринт: проверяйте не только порт, но и корректность backend’а (версия, build-id).
Порог чувствительности: `N` успешных/неуспешных проверок подряд, чтобы избегать флаппинга.
Съем метрик: доля healthy-ендпоинтов, время реакции, количество переключений.

Частные зоны и split-horizon

Private DNS: внутренние зоны в VPC/VNet/On-prem (например, `svc.local.example`).
Split-horizon: разные ответы для внутренних и внешних клиентов (внутренний IP vs публичный).
Защита от утечек: не используйте «внутренние» имена вовне; проверьте, что приватные зоны не резолвятся через публичных провайдеров.

Безопасность DNS

DNSSEC: подписи зон (ZSK/KSK), публикация `DS` в родительской зоне, ролловер ключей.
CAA: ограничьте выпуск TLS-сертов доверенным CA.
DoT/DoH для рекурсоров — шифрование запросов клиентов.
ACL/Rate-limit на авторитативных: защита от отражающих DDoS/ANY-запросов.
Subdomain Takeover: регулярно сканируйте «висячие» CNAME/ALIAS на удаленные сервисы (удален ресурс — CNAME остался).
NS/Glue-записи: консистентность между регистратором и провайдером DNS.

SLO и наблюдаемость

SLO (примеры)

Доступность авторитативных ответов: ≥ 99.99% / 30 дней.
Время ответа рекурсору (p95): ≤ 50 мс локально / ≤ 150 мс глобально.
Успешность health-checks: ≥ 99.9%, ложных срабатываний — ≤ 0.1%.
Время схода после изменения (propagation): ≤ 5 мин при TTL 60 с.

Метрики

RCODE (NOERROR/NXDOMAIN/SERVFAIL), QPS, p50/p95 времени ответа.
Доли IPv6/IPv4, EDNS размер, Truncated (TC) ответы.
Кол-во переключений по health-check, флаппинг, ошибки подписей DNSSEC.
Доли DoH/DoT запросов (если контролируете рекурсор).

Логи

Запросы (qname, qtype, rcode, client ASN/geo), аномалии (ANY-штормы, частые NXDOMAIN по одному префиксу).

IaC и автоматизация

Terraform/Провайдеры DNS: держите зоны в репозитории, PR-ревью, план/аппрув.
ExternalDNS (K8s): автоматическое создание/удаление записей из Ingress/Service.
Промежуточные окружения: префиксы `dev.`/`stg.` и отдельные аккаунты DNS-провайдера.

Terraform (упрощенный пример)

hcl resource "dns_a_record_set" "api" {
zone = "example.com."
name = "api"
addresses = ["203.0.113.10","203.0.113.20"]
ttl = 60
}

resource "dns_caa_record" "caa" {
zone = "example.com."
name = "@"
ttl = 3600 record {
flags = 0 tag  = "issue"
value = "letsencrypt.org"
}
}

Резолверы, кэш и производительность

Собственные рекурсоры (Unbound/Knot/Bind) ближе к приложениям → меньше p95.
Включайте prefetch горячих записей, serve-stale при недоступности авторитета.
EDNS(0) и правильный размер буфера, DNS Cookies, minimal-responses.
Разделяйте потоки резолва и трафик приложений (QoS).
Учитывайте Negative TTL: много NXDOMAIN от «битого» клиента может забить кэш.

DDoS и устойчивость

Anycast-провайдер с глобальными PoP и агрегацией бот-трафика.
Response Rate Limiting (RRL) на авторитативных, защита от amplification.
Запрет `ANY`, ограничение EDNS-буфера, фильтры на «тяжелые» типы.
Сегментация зон: критичное — у провайдера с лучшим DDoS-щитом; менее критичное — отдельно.
Резервный провайдер (secondaries) с `AXFR/IXFR` и автоматическим фейловером NS на уровне регистратора.

Операции и процессы

Изменения: PR-review, canary-записи, прогрев кэшей (низкий TTL → deploy → вернуть TTL).
Ролловер DNSSEC: регламент, окна, мониторинг валидности (RFC 8901 KSK/ZSK).
Runbook: падение PoP, некорректная NS-делегация, отвалившийся health-check, массовый SERVFAIL.
DR-план: альтернативный DNS-провайдер, готовые шаблоны зон, доступ к регистратору, SLA на смену NS.

Чек-лист внедрения

• Два независимых авторитативных провайдера/PoP (Anycast), корректные `NS` у регистратора.
• TTL-стратегия: короткий для динамики, длинный для стабильных записей; negative TTL под контролем.
• Health-checks и политики: failover/weighted/latency/geo по профилю сервисов.
• DNSSEC (KSK/ZSK/DS), `CAA` ограничивает выпуск сертов.
• IaC для зон, ExternalDNS для K8s, отдельные окружения/аккаунты.
• Мониторинг: rcode/QPS/latency/propagation, алерты по SERVFAIL/подписям.
• DDoS: Anycast, RRL, ограничения EDNS, блок списки/ACL.
• Регламенты миграций доменов и понижения TTL за 48–72 ч.
• Регулярный аудит «висячих» CNAME/ALIAS, MX/SPF/DKIM/DMARC (если используется почта).

Типичные ошибки

Слишком большой TTL на критичных `A/AAAA` — долгие миграции/фейловеры.
Один провайдер DNS/один PoP — SPOF.
Отсутствие DNSSEC/CAA — риск подмены/неконтролируемых сертов.
Непоследовательный split-horizon → утечки внутренних имен наружу.
Никаких health-checks на GSLB — переключение руками и задержки.
Забытые CNAME на внешние сервисы → риск takeover.
Отсутствие IaC → «снежинка»-конфиги и ошибки при ручных правках.

Специфика для iGaming/финтех

Региональные версии и PSP: geo/latency-routing, белые списки IP/ASN партнеров, быстрый failover шлюзов.
Пики (матчи/турниры): короткий TTL, прогрев CDN, отдельные имени для ивентов (`event-N.example.com`) с управляемой политикой.
Юридическая корректность: фиксируйте время и версию зон при критичных изменениях (журнал для аудита).
Антифрод/БОТ-защита: отдельные имена для tiebreakers/капчи/чек-эндпоинтов; быстрый отвод на «черную дыру» (sinkhole) при атаках.

Мини-плейбуки

1. `api-canary.example.com` → 5% трафика; 2) мониторим p95/p99/ошибки; 3) повышаем до 25/50/100%; 4) сворачиваем при деградации.

1. TTL 60 с; 2) health-check пометил регион down → GSLB снял из ответов; 3) проверка внешних резолверов; 4) коммуникация статуса.

1. Импорт зоны в нового провайдера; 2) Включаем синхронный secondary у старого; 3) Меняем `NS` у регистратора в «тихое» окно; 4) Наблюдаем SERVFAIL/val-ошибки.

Итог

Надежный DNS-контур — это Anycast-авторитеты + разумные TTL + маршрутизация по здоровью/задержке + DNSSEC/CAA + IaC и наблюдаемость. Зафиксируйте процессы миграций и ролловеров, держите резервного провайдера, регулярно проверяйте зону на «висячие» записи — и ваши пользователи стабильно попадут на нужные фронты даже в самый «горячий» час.