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.