DNS маршрутизація і failover

1) Роль DNS у відмовостійкості

• Доступність (швидкий/надійний failover);
• Продуктивність (гео/latency-routing);
• Вартість (мінімізація міжрегіонального egress і 3rd-party викликів);
• Безпека (DNSSEC, anti-hijack, контроль CAA/DMARC/SPF).

Ключ: короткі TTL там, де важлива динаміка, і стабільна зональна архітектура (public + private, split-horizon).

2) Типи записів і практики

A/AAAA - основні адреси; завжди публікуйте IPv6 де можливо.
CNAME vs ALIAS/ANAME: на корені домену використовуйте ALIAS/ANAME (або провайдерський apex-flattening).
TXT - SPF/DMARC/DKIM, верифікації; CAA - обмеження випускників сертифікатів.
SRV/NS - сервіс-дискавері та делегування.
SVCB/HTTPS - сучасний альтернативний механізм з пріоритизацією і параметрами (ALPN, порти).

Рекомендація: фіксуйте стандарти TTL за класами (edge/API/статик).

3) Політики маршрутизації

Weighted (зважена) - контрольовані частки трафіку (канарки/blue-green).
Latency-based - вибір найближчого по затримці пулу.
Geo-routing - по країні/континенту/регіону; важливо для data residency.
Failover (primary/secondary) - активний моніторинг і перемикання.
Multi-value - кілька A/AAAA; клієнт сам вибирає (не замінює health-checks).
Proximity/ASN routing - у деяких провайдерів: по мережі клієнта.

Комбінуйте: geo → latency → weight → health.

4) TTL, кешування та пропаганда

TTL API/динаміки: 30-120 с (баланс між швидкістю фейловера і навантаженням).
Static/CDN: 1-24 год.
Негативний TTL (SOA'Minimum') - ≤ 60-300 с, інакше NXDOMAIN буде «липким».
Пам'ятайте: резолвери не зобов'язані моментально викидати кеш; враховуйте «брудний хвіст».

5) Здоров'я та перевірка ендпоінтів

Health-checks з декількох регіонів: TCP/443 + HTTP 2xx/3xx і лямбда-перевірки бізнес-критеріїв (наприклад, успішний '/health? deep = true'з перевіркою залежностей).
Синтетика (RUM/active): API-проби за основними маршрутами, перевірка TLS/OCSP, перевірки DNSSEC.
Експонуйте '/ready'( глибока) і '/live'( поверхнева); DNS-пул прив'язуйте до/ready.

6) Публічний vs приватний DNS (split-horizon)

Public zone - клієнтський доступ.
Private zone - внутрішня резолюція до private endpoints (VPC/VNet, on-prem).
Conditional forwarding между on-prem ↔ cloud, region ↔ region.
Іменування: `api. <brand>.<region>.internal. corp` и `api. <brand>.com`.

7) Безпека: DNSSEC і політика домену

DNSSEC: вмикайте підпис зони (KSK/ZSK), слідкуйте за ротацією ключів і ланцюжком довіри.
CAA: перерахуйте допустимі CA; увімкніть'iodef'для алертів.
SPF/DMARC/DKIM: репутація пошти і захист від фішингу.
Registrar-лок і MFA на обліки провайдера DNS; журнал змін (WORM-сховище).

8) Проектування failover

8. 1 Моделі

Active-Active: два + здорових пулу; баланс через latency/weight, health-checks виключають нездорові.
Active-Passive: основний пул + резерв (0% вага до аварії).
Regional ring: трафік в «сусідній» регіон при локальній аварії.
Degraded mode: запис на «легкий» сайт/лендінг, якщо бекенд недоступний.

8. 2 Покроковий сценрій

1. Моніторинг фіксує деградацію '/ready'.
2. DNS змінює відповіді (виключає пул або змінює ваги).
3. Трафік йде в здоровий регіон, TTL визначає швидкість.
4. Після стабілізації - grace-період (15-30 хв) і тільки потім повернення ваг.

9) Приклади конфігурацій

9. 1 AWS Route 53 — latency + health + weighted

hcl
Two latency aliases for different regions resource "aws_route53_record" "api_latency_eu" {
zone_id = var. zone_id name  = "api. example. com"
type  = "A"
set_identifier = "eu1"
latency_routing_policy { region = "eu-central-1" }
alias { name = aws_lb. api_eu. dns_name zone_id = aws_lb. api_eu. zone_id evaluate_target_health = true }
health_check_id = aws_route53_health_check. api_eu. id ttl = 60
}

resource "aws_route53_record" "api_latency_us" {
zone_id = var. zone_id name  = "api. example. com"
type  = "A"
set_identifier = "us1"
latency_routing_policy { region = "us-east-1" }
alias { name = aws_lb. api_us. dns_name zone_id = aws_lb. api_us. zone_id evaluate_target_health = true }
health_check_id = aws_route53_health_check. api_us. id ttl = 60
}

Canary in EU: 10% of the weight of the resource "aws_route53_record" "api_weighted_canary" {
zone_id = var. zone_id name  = "api. example. com"
type  = "A"
set_identifier = "eu1-canary"
weighted_routing_policy { weight = 10 }
alias { name = aws_lb. api_eu_canary. dns_name zone_id = aws_lb. api_eu_canary. zone_id evaluate_target_health = true }
ttl = 30
}

9. 2 Cloudflare - гео/ASN і failover pool (ідея)

Load Balancer Pools c health-checks (HTTP/TCP), Load Balancer з Geo Steering (континенти/країни) і Session affinity.
Fallback: Page Rule/Transform Rule на спрощений бекенд при 5xx піках.

9. 3 Azure/GCP

Azure Traffic Manager: Priority/Weighted/Performance/Geographic.
Google Cloud Load Balancing + Cloud DNS policy: geo-policy + health-checks через External HTTP(S) LB.

10) Спостережуваність і SLO DNS

SLI: success-rate резолва, 95-й перцентиль часу резолва, частка свіжих (не-stale) відповідей в межах TTL.
SLO: наприклад,'99. 95% успішних відповідей ≤ 100 мс.
Метрики: NXDOMAIN-rate, SERVFAIL-rate, health-state пулів, частка трафіку по регіонах, частка канарок.
Exemplars: зв'язуйте SLI з трасуваннями HTTP через'trace _ id'в синтетиці.

11) Тестування та експлуатація

Синтетика з різних ASN/регіонів (RIPE Atlas, Catchpoint, k6-DNS).
dnsviz/' delv'для перевірки DNSSEC;'dig + trace'при аномаліях.
Staging-зона ('stg. example. com') для репетицій фейловера; rehearsal-скрипт змінює ваги/пріоритети і повертає назад.
Runbook: хто і як вручну підвищує/знижує ваги, як відключити пул, як виконати «freeze».

12) Антипатерни

TTL = 3000 + на критичних A/AAAA → повільний/хаотичний фейловер.
Відсутність health-checks або перевірки тільки TCP-порту без бізнес-інваріантів.
Купа CNAME-ланцюжків → повільні резолви, кеш-хаос.
Єдиний DNS-провайдер без secondary/axfr-резерву.
Непідписана зона при вимозі DNSSEC; неактуальні CAA.
Записи, що вказують на публічні IP приватних бекендів/БД.

13) Специфіка iGaming/фінансів

Юрисдикції: geo-/country-routing для дотримання вимог (перенаправлення на локальний домен/фронт).
PSP/KYC: виділені піддомени з окремими TTL і політиками фейловера; швидкий переклад на резервного PSP.
Відповідальна гра: піддомени з юридичними сторінками завжди доступні (резервні статики/CDN).
Аудит: журнал змін зони в WORM-сховищі, підпис змін і регулярні рев'ю.
Блок-листи: DNS-правила комплаєнсу за регіонами (edge-фільтрація + DNS-маршрутизація).

14) Чек-лист prod-готовності

• Профілі TTL за класами; негативний TTL ≤ 300 с.
• Дві незалежні anycast-мережі DNS (primary/secondary), MFA/реєстратор-лок.
• Політики: geo/latency/weight + health-checks з декількох регіонів.
• DNSSEC включений, CAA/DMARC/DKIM/SPF актуальні.
• Split-horizon (public/private), private zones для внутрішнього трафіку.
• Runbook фейловера/повернення, rehearsal-скрипт, канарські домени.
• Моніторинг SLI/SLO, алерти на NXDOMAIN/SERVFAIL/зростання RTT.
• Стаджинг-зона і регулярні «навчання» failover.
• Для iGaming: роутинг по юрисдикціях, окремі домени для PSP/KYC, незмінний аудит.

15) TL; DR

Будуйте комбіновану політику: geo/latency + health-checks + ваги, з TTL 30-120 с на динаміці. Розділяйте public/private (split-horizon), включайте DNSSEC і CAA, тримайте secondary DNS. Робіть rehearsal-фейловер і спостерігайте SLI/SLO DNS. Для iGaming враховуйте юрисдикції і резервування PSP/KYC доменів з окремими правилами і логуванням змін в WORM.