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-перцентиль резолю уақыты, TTL шегіндегі жаңа (stale емес) жауаптардың үлесі.
SLO: мысалы, '99. 95% табысты жауаптар ≤ 100 мс.
Метриктер: NXDOMAIN-rate, SERVFAIL-rate, health-state пулдар, аймақтар бойынша трафик үлесі, канарейка үлесі.
Exemplars: SLI-ді синтетикадағы 'trace _ id' арқылы HTTP трассировкаларымен байланыстырыңыз.

11) Тестілеу және пайдалану

Әртүрлі ASN/өңірлерден синтетика (RIPE Atlas, Catchpoint, k6-DNS).
DNSSEC тексеру үшін dnsviz/' delv '; ауытқулар кезінде' dig + trace '.
Staging аймағы ('stg. example. com ') фейловердің дайындығы үшін; rehearsal-скрипт салмақты/басымдықтарды өзгертеді және кері қайтарады.
Runbook: кім және қалай қолмен салмақты көтереді/азайтады, пулды қалай өшіру керек, «freeze» қалай орындау керек.

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

TTL = 3000 + критикалық A/AAAA → баяу/хаотикалық фейловер.
Бизнес инварианттары жоқ тек TCP-портты тексерудің немесе тексерудің болмауы.
CNAME тізбектерінің үйіндісі → баяу қақтығыстар, кэш-хаос.
secondary/axfr-резерві жоқ жалғыз DNS-провайдер.
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-дегі өзгерістердің логині бар юрисдикцияларын және резервтеуді ескеріңіз.