DNS yönlendirme ve yük devretme

1) DNS'nin hata toleransındaki rolü

• Kullanılabilirlik (hızlı/güvenilir yük devretme);
• Performans (geo/latency-routing);
• Maliyet (bölgelerarası çıkış ve 3. taraf çağrılarını en aza indirmek);
• Güvenlik (DNSSEC, kaçırma önleme, CAA/DMARC/SPF kontrolü).

Anahtar: Dinamiklerin önemli olduğu kısa TTL'ler ve istikrarlı bölgesel mimari (kamu + özel, bölünmüş ufuk).

2) Kayıt ve uygulama türleri

A/AAAA - ana adresler; Mümkün olan her yerde her zaman IPv6 yayınlayın.
CNAME vs ALIAS/ANAME: Etki alanının kökünde ALIAS/ANAME (veya sağlayıcı apeks düzleştirmesi) kullanın.
TXT - SPF/DMARC/DKIM, doğrulama; CAA - sertifika verenlerin sınırlandırılması.
SRV/NS - hizmet keşfi ve delegasyonu.
SVCB/HTTPS, önceliklendirme ve parametrelere (ALPN, portlar) sahip modern bir alternatif mekanizmadır.

Öneri: TTL standartlarını sınıfa göre düzeltin (kenar/API/statik).

3) Yönlendirme politikaları

Ağırlıklı - kontrollü trafik payları (kanaryalar/mavi-yeşil).
Gecikme tabanlı - Gecikmede en yakın havuzu seçin.
Coğrafi yönlendirme - ülkeye/kıtaya/bölgeye göre; Data residency için önemlidir.
Yük devretme (birincil/ikincil) - aktif izleme ve anahtarlama.
Çok değerli - birkaç A/AAAA; Müşteri kendini seçer (sağlık kontrollerinin yerini almaz).
Yakınlık/ASN yönlendirmesi - bazı sağlayıcılar için: müşterinin ağı üzerinden.

Birleştir: Coğrafi? Gecikme? Ağırlık? Sağlık.

4) TTL, önbellekleme ve yayılma

TTL API/hoparlörler: 30-120 s (feiler hızı ve yük arasındaki denge).
Statik/CDN: 1-24 ч.
Negatif TTL (SOA 'Minimum') - 60-300 s ≤, aksi takdirde NXDOMAIN "yapışkan" olacaktır.
Unutmayın: çözücülerin önbelleği anında atmaları gerekmez; "Kirli kuyruk'u düşünün.

5) Sağlık ve kontrol bitiş noktaları

Birden fazla bölgeden sağlık kontrolleri: TCP/443 + HTTP 2xx/3xx ve lambda iş kriterleri kontrolleri (örn. Başarılı'/sağlık? deep = true 'bağımlılık kontrolü ile).
Sentetik (RUM/aktif): Ana yollar boyunca API örnekleri, TLS/OCSP kontrolleri, DNSSEC kontrolleri.
'/hazır '(derin) ve'/canlı' (yüzeysel); DNS havuzunu/hazır olarak bağlayın.

6) Genel ve özel DNS (bölünmüş ufuk)

Genel bölge - istemci erişimi.
Özel bölge - özel uç noktalara dahili çözünürlük (VPC/VNet, on-prem).
Koşullu iletme между hazır ↔ bulut, bölge ↔ bölge.
Adlandırma: 'api. <brand>. <region> .internal. Corp 'и' api. <brand> .com '.

7) Güvenlik: DNSSEC ve etki alanı politikası

DNSSEC: bölge imzasını etkinleştir (KSK/ZSK), anahtar rotasyonunu ve güven zincirini izle.
CAA: liste geçerli CA'lar; Uyarılar için 'iodef' ekleyin.
SPF/DMARC/DKIM: Postanın itibarı ve kimlik avına karşı koruma.
DNS sağlayıcı hesapları için kayıt sorumlusu kilidi ve MFA; Günlüğü değiştir (WORM mağazası).

8) Yük devretme tasarımı

8. 1 Modeller

Aktif-Aktif: iki + sağlıklı havuz; Gecikme/ağırlık ile denge, sağlık kontrolleri sağlıksız ekarte.
Aktif-Pasif: ana havuz + rezerv (kazadan önce %0 ağırlık).
Bölgesel halka: Yerel bir felakette "komşu" bölgeye trafik.
Bozulmuş mod: arka uç mevcut değilse'kolay "siteye/inişe yazın.

8. 2 Adım adım senaryo

1. '/ready 'kayıtlarının bozulmasının izlenmesi.
2. DNS yanıtları değiştirir (havuzu ortadan kaldırır veya ağırlıkları değiştirir).
3. Trafik sağlıklı bir bölgeye gidiyor, hızı TTL belirliyor.
4. Stabilizasyondan sonra - ödemesiz dönem (15-30 dakika) ve ancak o zaman ölçeklerin geri dönüşü.

9) Yapılandırma örnekleri

9. 1 AWS Route 53 - gecikme + sağlık + ağırlıklı

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 ve yük devretme havuzu (fikir)

Yük Dengeleyici Havuzları c sağlık kontrolleri (HTTP/TCP), Coğrafi Yönlendirmeli Yük Dengeleyici (kıtalar/ülkeler) ve Oturum yakınlığı.
Fallback: Sayfa Kuralı/5xx zirvelerinde basitleştirilmiş bir arka uca Dönüştür Kuralı.

9. 3 Azure/GCP

Azure Trafik Yöneticisi: Öncelik/Ağırlıklı/Performans/Coğrafi.
Google Cloud Load Balancing + Cloud DNS politikası: jeo-politika + sağlık kontrolleri через Harici HTTP (S) LB.

10) Gözlemlenebilirlik ve DNS SLO

SLI: başarı oranı çözünürlüğü, çözüm süresinin yüzde 95'i, TTL içindeki taze (eski olmayan) yanıtların oranı.
SLO: örneğin, '99. Başarılı yanıtların %95'i 100 ms'yi ≤.
Metrikler: NXDOMAIN oranı, SERVFAIL oranı, sağlık durumu havuzları, bölgeye göre trafik payı, kanarya payı.
Örnekler: SLI'yi sentetiklerde 'trace _ id' aracılığıyla HTTP izleriyle ilişkilendirin.

11) Test ve operasyon

Farklı ASN/bölgelerden sentetikler (RIPE Atlas, Catchpoint, k6-DNS).
DNSSEC'i kontrol etmek için dnsviz/' delv ';' Anomaliler için dig + trace.
Evreleme bölgesi ('stg. örnek. com ') feilover provaları için; Prova senaryosu ağırlıkları/öncelikleri ve dönüşleri değiştirir.
Runbook: kim ve nasıl manuel olarak ağırlıkları yükseltir/düşürür, havuz nasıl kapatılır, "donma" nasıl yapılır.

12) Antipatterns

TTL = 3000 + üzerinde kritik A/AAAA - yavaş/kaotik feilover.
İş değişmezleri olmadan sağlık kontrolleri veya yalnızca TCP bağlantı noktası kontrolleri yok.
Bir grup CNAME zinciri - yavaş çözünürlükler, önbellek kaosu.
İkincil/axfr yedeklemesi olmayan tek DNS sağlayıcısı.
DNSSEC gerektiğinde imzasız bölge; Alakasız CAA'lar.
Özel arka uçların/veritabanlarının genel IP'sine işaret eden girişler.

13) iGaming/Finansın Özellikleri

Yargı alanları: Uyumluluk için coğrafi/ülke yönlendirmesi (yerel etki alanına/öne yönlendirme).
PSP/KYC: Bireysel TTL ve feilover politikalarına sahip özel alt alanlar; Bekleme PSP'ye hızlı aktarım.
Sorumlu oyun: Yasal sayfalara sahip alt alanlar her zaman mevcuttur (yedek statik/CDN).
Denetim - Bölge değişikliklerini WORM deposuna kaydedin, değişiklikleri işaretleyin ve düzenli olarak gözden geçirin.
Blok listeleri: Bölgeye göre DNS uyumluluk kuralları (kenar filtreleme + DNS yönlendirme).

14) Prod Hazırlık Kontrol Listesi

• Sınıflara göre TTL profilleri; Negatif TTL ≤ 300 s.
• İki bağımsız DNS ağı (birincil/ikincil), MFA/kayıt sorumlusu kilidi.
• Politikalar: Coğrafi/gecikme/ağırlık + birden fazla bölgeden sağlık kontrolleri.
• DNSSEC etkin, CAA/DMARC/DKIM/SPF güncel.
• Bölünmüş ufuk (kamu/özel), iç trafik için özel bölgeler.
• El ilanı/dönüş runbook, prova komut dosyası, kanarya alanları.
• SLI/SLO izleme, NXDOMAIN/SERVFAIL/RTT büyümesi hakkında uyarılar.
• Evreleme alanı ve düzenli yük devretme "matkaplar".
• iGaming için: yetki alanına göre yönlendirme, PSP/KYC için ayrı alanlar, değiştirilemez denetim.

15) TL; DR

Birleştirilmiş bir politika oluşturun: geo/latency + health-checks + weights, TTL 30-120 s hoparlörde. Ayrı genel/özel (bölünmüş ufuk), DNSSEC ve CAA'yı etkinleştirin, ikincil DNS'yi saklayın. Bir prova-feilover yapın ve SLI/SLO DNS'yi gözlemleyin. IGaming için, ayrı kurallara ve WORM'deki değişikliklerin günlüğe kaydedilmesine sahip yargı yetkilerini ve PSP/KYC alan adı rezervasyonlarını göz önünde bulundurun.