DNS marşrutlaşdırma və failover

1) nasazlıq müqavimət DNS rolu

• Əlçatanlıq (sürətli/etibarlı failover);
• Performans (geo/latency-routing);
• Qiymət (regionlararası egress və 3rd-party zənglərin minimuma endirilməsi);
• Təhlükəsizlik (DNSSEC, anti-hijack, CAA/DMARC/SPF nəzarət).

Açar: Dinamikanın vacib olduğu yerlərdə qısa TTL və sabit zona arxitekturası (public + private, split-horizon).

2) Qeydlər və təcrübə növləri

A/AAAA - əsas ünvanlar; həmişə mümkün olan yerdə IPv6 dərc edin.
CNAME vs ALIAS/ANAME: domen kökündə ALIAS/ANAME (və ya provayder apex-flattening) istifadə edin.
TXT - SPF/DMARC/DKIM, yoxlama; CAA - sertifikat istehsalçılarının məhdudlaşdırılması.
SRV/NS - Discovery xidməti və nümayəndəlik.
SVCB/HTTPS - prioritetləşdirmə və parametrləri ilə müasir alternativ mexanizmdir (ALPN, limanlar).

Tövsiyə: TTL standartlarını siniflərə görə düzəldin (edge/API/statik).

3) Marşrutlaşdırma siyasəti

Weighted (balanslı) - trafikin nəzarət olunan hissələri (kanaryalar/mavi-yaşıl).
Latency-based - ən yaxın gecikmə hovuzunun seçimi.
Geo-routing - ölkə/qitə/region üzrə; data residency üçün vacibdir.
Failover (primary/secondary) - aktiv monitorinq və keçid.
Multi-value - bir neçə A/AAAA; müştəri özü seçir (health-checks əvəz etmir).
Proximity/ASN routing - bəzi provayderlərdə: müştəri şəbəkəsi vasitəsilə.

Birləşdirin: geo → latency → weight → health.

4) TTL, caching və təbliğat

TTL API/dinamik: 30-120 s (faylover sürəti və yük arasında balans).
Static/CDN: 1–24 ч.
Mənfi TTL (SOA 'Minimum') - ≤ 60-300 s, əks halda NXDOMAIN «yapışqan» olacaq.
Unutmayın: rezolverlər dərhal cache atmaq məcburiyyətində deyil; «çirkli quyruq» nəzərə.

5) Sağlamlıq və end nöqtələrinin yoxlanılması

Bir neçə regiondan sağlamlıq-yoxlamalar: TCP/443 + HTTP 2xx/3xx və lambda-yoxlama biznes meyarları (məsələn, uğurlu '/sağlamlıq? deep = true 'asılılıq yoxlaması ilə).
Sintetika (RUM/active): Əsas marşrutlar üzrə API testləri, TLS/OCSP yoxlaması, DNSSEC yoxlamaları.
Eksponat '/ready '(dərin) və '/live' (səthi); DNS hovuzu/ready-ə bağlanır.

6) Açıq vs xüsusi DNS (split-horizon)

Public zone - müştəri girişi.
Private zone - private endpoints (VPC/VNet, on-prem) üçün daxili qətnamə.
Conditional forwarding между on-prem ↔ cloud, region ↔ region.
Adları: 'api. <brand>.<region>.internal. corp` и `api. <brand>.com`.

7) Təhlükəsizlik: DNSSEC və domen siyasəti

DNSSEC: zonanın imzasını (KSK/ZSK) daxil edin, açarların rotasiyasını və etimad zəncirini izləyin.
CAA: icazə verilən CA siyahıları; alertlər üçün 'iodef' daxil edin.
SPF/DMARC/DKIM: poçt nüfuzu və fişinq qorunması.
DNS provayderinin qeydiyyatında registrar-lok və MFA; dəyişiklik jurnalı (WORM-saxlama).

8) failover dizayn

8. 1 Modellər

Active-Active: iki + sağlam hovuz; latency/weight vasitəsilə balans, health-checks qeyri-sağlam istisna.
Active-Passive: əsas hovuz + ehtiyat (0% qəza əvvəl çəki).
Regional ring: yerli qəza zamanı «qonşu» bölgəyə trafik.
Degraded mode: «yüngül» sayta giriş/backend mövcud deyilsə lending.

8. 2 Addım-addım səhnə

1. Monitorinq '/ready 'deqradasiyasını qeyd edir.
2. DNS cavabları dəyişir (hovuz və ya çəki dəyişir).
3. Trafik sağlam bölgəyə gedir, TTL sürəti təyin edir.
4. Sabitləşmədən sonra - grace-period (15-30 dəq) və yalnız sonra tərəzi geri.

9) Konfiqurasiya nümunələri

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 - geo/ASN və failover pool (ideya)

Load Balancer Pools c health-checks (HTTP/TCP), Geo Steering (qitələr/ölkələr) və Session affinity ilə Load Balancer.
Fallback: Page Rule/Transform Rule 5xx piklərdə sadələşdirilmiş arxa planda.

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) Müşahidə və SLO DNS

SLI: TTL daxilində success-rate rezolver, 95-ci persentil rezolver vaxtı, təzə (qeyri-stale) cavabların payı.
SLO: məsələn, '99. 95% uğurlu cavablar ≤ 100 ms.
Metriklər: NXDOMAIN-rate, SERVFAIL-rate, health-state hovuzları, regionlar üzrə trafik payı, kanaryaların payı.
Exemplars: SLI-ni sintetikada 'trace _ id' vasitəsilə HTTP izləri ilə əlaqələndirin.

11) Test və əməliyyat

Müxtəlif ASN/regionlardan sintetika (RIPE Atlas, Catchpoint, k6-DNS).
DNSSEC-i yoxlamaq üçün dnsviz/' delv '; anomaliyalar zamanı' dig + trace '.
Staging zona ('stg. example. com ') feyloverin məşqləri üçün; rehearsal script çəki/prioritet dəyişir və geri qayıdır.
Runbook: kim və necə əl ilə artırır/çəkisini azaldır, hovuzu necə söndürmək olar, necə «freeze» etmək olar.

12) Antipattern

TTL = 3000 + kritik A/AAAA → yavaş/xaotik feylover.
No health-checks və ya yoxlama yalnız TCP-port biznes invariantları olmadan.
Bir dəstə CNAME zəncirləri → yavaş rezolves, cash-xaos.
secondary/axfr ehtiyat olmadan yeganə DNS provayderi.
DNSSEC tələbi ilə imzalanmamış zona; qeyri-aktual CAA.
Şəxsi IP-ləri göstərən qeydlər/DB.

13) iGaming/Maliyyə Xüsusiyyətləri

Yurisdiksiyalar: geo-/country-routing tələblərə cavab vermək üçün (yerli domen/cəbhəyə yönləndirmə).
PSP/KYC: ayrı TTL və feylover siyasətləri ilə ayrılmış alt domenlər; ehtiyat PSP sürətli transfer.
Məsuliyyətli oyun: hüquqi səhifələri olan alt domenlər həmişə mövcuddur (ehtiyat statik/CDN).
Audit: WORM-saxlama zonasında dəyişikliklər jurnalı, dəyişikliklərin imzası və müntəzəm review.
Blok vərəqləri: Regionlar üzrə DNS uyğunluq qaydaları (edge-filtrasiya + DNS-marşrutlaşdırma).

14) Prod hazırlıq yoxlama siyahısı

• Siniflər üzrə TTL profilləri; mənfi TTL ≤ 300 s.
• İki müstəqil DNS anycast şəbəkəsi (primary/secondary), MFA/lok registrator.
• Siyasət: geo/latency/weight + health-checks bir neçə regiondan.
• DNSSEC daxil, CAA/DMARC/DKIM/SPF aktualdır.
• Split-horizon (public/private), daxili trafik üçün xüsusi zonalar.
• Feylover/geri Runbook, rehearsal skript, kanarya domenləri.
• SLI/SLO monitorinqi, NXDOMAIN/SERVFAIL/RTT artımı.
• Stajinq zonası və mütəmadi «təlimlər» failover.
• iGaming üçün: yurisdiksiya marşrutu, PSP/KYC üçün ayrı-ayrı domenlər, dəyişməz audit.

15) TL; DR

Birləşdirilmiş siyasət qurun: geo/latency + health-checks + çəki, TTL 30-120 ilə dinamik. public/private (split-horizon) bölmək, DNSSEC və CAA daxil, secondary DNS saxlayın. rehearsal feylover edin və SLI/SLO DNS-ni müşahidə edin. iGaming üçün ayrı qaydalar və WORM-də dəyişikliklərin loqotipi ilə PSP/KYC domenlərinin yurisdiksiyalarını və rezervasiyalarını nəzərə alın.