Routing i awaria systemu DNS

1) Rola DNS w tolerancji błędów

• Dostępność (szybka/niezawodna awaria);
• Wydajność (geo/latency-routing);
• Koszt (zminimalizowanie międzyregionalnego wyjścia i 3rd-party calls);
• Bezpieczeństwo (DNSSEC, anty-porwanie, kontrola CAA/DMARC/SPF).

Klucz: krótkie TTL, gdzie dynamika jest ważna, i stabilna architektura strefowa (public + private, split-horizon).

2) Rodzaje rejestrów i praktyk

A/AAAA - główne adresy; zawsze publikuj w miarę możliwości protokół IPv6.
CNAME vs ALIAS/ANAME: U źródła domeny należy użyć ALIAS/ANAME (lub apex-spłaszczenie dostawcy).
TXT - SPF/DMARC/DKIM, weryfikacja; CAA - ograniczenie emitentów certyfikatów.
SRV/NS - odkrycie i delegowanie usług.
SVCB/HTTPS to nowoczesny mechanizm alternatywny z priorytetyzacją i parametrami (ALPN, porty).

Zalecenie: naprawić normy TTL według klasy (krawędź/API/statyczna).

3) Polityka routingu

Ważony - kontrolowane udziały w ruchu (kanarki/niebiesko-zielone).
Latency - Wybierz basen, który jest najbliżej opóźnienia.
Trasa geograficzna - według kraju/kontynentu/regionu; ważne dla rezydencji danych.
Awaria (podstawowa/wtórna) - aktywny monitoring i przełączanie.
Wielowartościowa - kilka A/AAAA; klient sam wybiera (nie zastępuje kontroli zdrowotnych).
Routing bliskości/ASN - dla niektórych dostawców: przez sieć klienta.

Połączenie: geo → opóźnienie → waga → zdrowie.

4) TTL, buforowanie i rozmnażanie

TTL API/głośniki: 30-120 s (równowaga między prędkością feilera a obciążeniem).
Statyczny/CDN: 1-24 °.
Ujemny TTL (SOA 'Minimum') - ≤ 60-300 s, inaczej NXDOMAIN będzie „lepki”.
Pamiętaj: rozdzielcy nie są zobowiązani do natychmiastowego wyrzucenia pamięci podręcznej; weźmy pod uwagę „brudny ogon”.

5) Punkty końcowe zdrowia i kontroli

Kontrole zdrowotne z wielu regionów: TCP/443 + HTTP 2xx/3xx oraz kontrole kryteriów biznesowych lambda (np. udane '/zdrowie? deep = true 'z kontrolą zależności).
Syntetyczne (RUM/active): próbki API na głównych trasach, kontrole TLS/OCSP, kontrole DNSSEC.
odsłonić „/gotowe ”(głębokie) i „/żywe” (powierzchowne); Powiązać pulę DNS z/gotową.

6) Publiczny vs prywatny DNS (podział na horyzonty)

Strefa publiczna - dostęp do klienta.
Strefa prywatna - wewnętrzna rozdzielczość do prywatnych punktów końcowych (VPC/VNet, on-prem).
Spedycja warunkowa мера, on-prem, „cloud”, region i region.
Nazwa: 'api. <marka>. <region> .internal. corp 'б' api. <marka> .com '.

7) Bezpieczeństwo: DNSSEC i polityka domeny

DNSSEC: włączyć podpis strefy (KSK/ZSK), monitorować rotację klucza i łańcuch zaufania.
CAA: wykaz ważnych urzędów certyfikacji; zawiera „jodef” dla wpisów.
SPF/DMARC/DKIM: renoma poczty i ochrona przed phishingiem.
blokada rejestru i MFA dla kont dostawców DNS; dziennik zmian (magazyn WORM).

8) Projektowanie awarii

8. 1 Modele

Active-Active: dwa + zdrowe baseny; równowaga poprzez opóźnienie/waga, kontrole zdrowia wyklucza niezdrowe.
Active-Passive: basen główny + rezerwa (0% wagi przed wypadkiem).
Regionalny pierścień: ruch do „sąsiedniego” regionu w katastrofie lokalnej.
Tryb awarii: napisz do „łatwego” miejsca/lądowania, jeśli backend nie jest dostępny.

8. 2 Scenariusz krok po kroku

1. Rejestry monitorowania degradacji „/gotowych ”.
2. DNS zmienia reakcje (eliminuje pulę lub zmienia wagę).
3. Ruch prowadzi do zdrowego regionu, TTL określa prędkość.
4. Po stabilizacji - okres łaski (15-30 min), a dopiero wtedy powrót wagi.

9) Przykłady konfiguracji

9. 1 AWS Route 53 - opóźnienia + zdrowie + ważone

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 i pula awaryjna (idea)

Load Balancer Pools c health-checks (HTTP/TCP), Load Balancer z Geo Steering (kontynenty/kraje) i powinowactwo sesyjne.
Fallback: Reguła strony/Reguła przekształcenia do uproszczonego backendu na pikach 5xx.

9. 3 Azure/GCP

Azure Traffic Manager: Priority/Weighted/Performance/Geographic.
Google Cloud Load Balancing + Cloud Polityka DNS: geo-policy + health-checks мереz Zewnętrzna HTTP (S) LB.

10) Obserwowalność i DNS SLO

SLI: rozdzielczość szybkości sukcesu, 95 procentyl czasu rozdzielczości, odsetek odpowiedzi świeżych (niekontrolowanych) w obrębie TTL.
SLO: na przykład, '99. 95% udanych odpowiedzi ≤ 100 ms.
Wskaźniki: NXDOMAIN-rate, SERVFAIL-rate, health-state pools, share traffic by region, canary share.
Przykłady: Powiązanie SLI ze śladami HTTP poprzez 'trace _ id' w syntetyce.

11) Badanie i działanie

Syntetyka z różnych regionów ASN (RIPE Atlas, Catchpoint, k6-DNS).
dnsviz/" delv "do sprawdzenia DNSSEC;" dig + trace 'dla anomalii.
Strefa postoju ('stg. przykład. com ") w przypadku prób feilover; skrypt prób zmienia wagi/priorytety i zwroty.
Runbook: kto i jak ręcznie podnosi/obniża ciężary, jak wyłączyć basen, jak wykonać „zamrożenie”.

12) Antypattery

TTL = 3000 + na krytycznym A/AAAA → powolny/chaotyczny feilover.
Żadnych kontroli zdrowotnych lub kontroli portowych tylko TCP bez stałej działalności gospodarczej.
Kilka łańcuchów CNAME → powolne rozdzielczości, cache chaos.
Jedyny dostawca DNS bez kopii zapasowej wtórnej/axfr.
Strefa bez podpisu, gdy wymagany jest DNSSEC; nieistotne CAA.
Wpisy wskazujące publiczny IP prywatnych baz danych.

13) Szczegóły dotyczące iGaming/Finance

Jurysdykcja: geo/country-routing dla zgodności (przekierowanie do domeny lokalnej/przodu).
PSP/KYC: dedykowane subdomeny z indywidualną polityką TTL i feilover; szybki transfer do standby PSP.
Odpowiedzialna gra: subdomeny z legalnymi stronami są zawsze dostępne (backup static/CDN).
Audyt - Zmiany strefy dziennika w sklepie WORM, zmiany podpisu i regularne przeglądy.
Listy bloków: reguły zgodności DNS według regionu (filtrowanie krawędzi + routing DNS).

14) Lista kontrolna gotowości Prod

• Profile TTL według klas; ujemny TTL ≤ 300 s.
• Dwie niezależne sieci DNS (podstawowe/wtórne), MFA/blokada rejestratora.
• Polityka: geo/opóźnienie/waga + kontrole zdrowotne z wielu regionów.
• DNSSEC enabled, CAA/DMARC/DKIM/SPF up to date.
• Podział na horyzonty (publiczny/prywatny), strefy prywatne dla ruchu wewnętrznego.
• Flyer/return runbook, skrypt prób, domeny kanaryjskie.
• Monitorowanie SLI/SLO, wpisy dotyczące wzrostu NXDOMAIN/SERVFAIL/RTT.
• Obszar postoju i regularne „ćwiczenia awaryjne”.
• W przypadku iGaming: routing według jurysdykcji, odrębne domeny dla PSP/KYC, niezmienny audyt.

15) TL; DR

Zbuduj wspólną politykę: geo/latency + kontrola zdrowia + wagi, z TTL 30-120 s na głośniku. Oddzielne publiczne/prywatne (split-horizon), włącz DNSSEC i CAA, zachowaj wtórny DNS. Wykonaj próbę feilover i obserwuj SLI/SLO DNS. Dla iGaming, rozważyć jurysdykcje i rezerwacje domeny PSP/KYC z oddzielnymi zasadami i rejestrowania zmian w WORM.