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 - найближчий по мережевій затримці РоР/регіон.
Geo-routing - по країні/континенту; корисно для локальних законів/PCI/PII.
Multivalue - кілька'A/AAAA'з перевірками здоров'я кожного.
Поради
Для критичних API з'єднуйте latency-based + health-checks + короткий TTL.
Для плавних релізів - weighted і поступове зростання частки.
Для регіональних обмежень - geo і списки дозволених провайдерів.
Здоров'я та автоматичне перемикання
Health-checks: HTTP (S) (200 OK, тіло/заголовок), TCP (порт), ICMP.
Репутація/фінгерпринт: перевіряйте не тільки порт, але і коректність backend'a (версія, 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.
Чек-лист впровадження
- Два незалежних авторитативних провайдера/РоР (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. ru). example. com') з керованою політикою.
Юридична коректність: фіксуйте час і версію зон при критичних змінах (журнал для аудиту).
Антифрод/БОТ-захист: окремі імена для tiebreakers/капчі/чек-ендпоінтів; швидке відведення на «чорну діру» (sinkhole) при атаках.
Міні-плейбуки
Канарний реліз фронту (weighted):1. `api-canary. example. com'→ 5% трафіку; 2) моніторимо р95/р99/помилки; 3) підвищуємо до 25/50/100%; 4) згортаємо при деградації.
Екстрений failover:1. TTL 60 с; 2) health-check позначив регіон down → GSLB зняв з відповідей; 3) перевірка зовнішніх резолверів; 4) комунікація статусу.
Міграція провайдера DNS:1. Імпорт зони в нового провайдера; 2) Включаємо синхронний secondary у старого; 3) Міняємо'NS'у реєстратора в «тихе» вікно; 4) Спостерігаємо SERVFAIL/val-помилки.
Підсумок
Надійний DNS-контур - це Anycast-авторитети + розумні TTL + маршрутизація по здоров'ю/затримці + DNSSEC/CAA + IaC і спостережуваність. Зафіксуйте процеси міграцій і ролловерів, тримайте резервного провайдера, регулярно перевіряйте зону на «висячі» записи - і ваші користувачі стабільно потраплять на потрібні фронти навіть в самий «гарячий» час.