Zarządzanie i routing DNS
Krótkie podsumowanie
DNS jest routerem na poziomie nazwy. "To zależy od właściwego TTL, stref i zasad, jak szybko i przewidywalnie użytkownicy dostać się do żądanych frontów/bram. Minimalny zestaw: dostawca Anycast, zdrowy TTL, kontrola zdrowia z automatycznym awaryjnym, DNSSEC + CAA, zarządzanie IaC i obserwowalność (SLO przez czas odpowiedzi i rozdzielczości).
Podstawowa architektura
Autorytatywne serwery (strefy) - odpowiadają za domeny firmy.
Rekursywni rozdzielcy (klienci/dostawcy usług internetowych/właściciele) - zapytaj główny → TLD → autorytatywny.
Anycast jest tym samym adresem IP na wielu PoP: w pobliżu PoP reaguje szybciej i przeżywa wypadki.
Strefy i przekazanie uprawnień
Strefa główna domeny → 'NS' do dostawców autorytatywnych serwerów.
Subdomeny (np. 'api. przykład. com ") mogą być przekazywane poszczególnym" NS "/dostawcom w celu zapewnienia niezależności.
Typy rekordów (minimum)
„A ”/„ AAAA” - adresy IPv4/IPv6.
„CNAME” - pseudonim nazwy; nie używać u źródła strefy (zamiast ALIAS/ANAME u dostawców).
„TXT” - weryfikacja, SPF, niestandardowe etykiety.
„MX” - poczta (jeżeli jest używana).
„SRV” - usługi (SIP, LDAP itp.).
„CAA” - kto może wydawać certyfikaty dla domeny.
„NS ”/„ SOA” - parametry delegacji/strefy.
'DS' - klucze DNSSEC do rodzica TLD.
Strefa próbki (fragment)
$TTL 300
@ IN SOA ns1.dns.example. noc.example. (2025110501 3600 600 604800 300)
IN NS ns1.dns.example.
IN NS ns2.dns.example.
@ IN A 203.0.113.10
@ IN AAAA 2001:db8::10 api IN CNAME api-prod.global.example.
_www IN CNAME cdn.example.net.
_caa IN CAA 0 issue "letsencrypt.org"TTL i buforowanie
Krótki TTL (30-300 s) - dla dynamiki (fronty API, awaria).
Średni TTL (300-3600 s) - dla CDN/statyków.
Długi TTL (≥ 1 dzień) - dla rzadkich zmian (MX/NS/DS).
Podczas planowania migracji, zmniejszyć TTL 24-72 godzin wcześniej.
Rozważenie ujemnego buforowania TTL (NXDOMAIN): zarządzanego przez „SOA MINIMUM”
Zasady routingu (warstwa GSLB)
Awaria (aktywny/pasywny) - dajemy główny IP do błędnej kontroli zdrowia, a następnie rezerwy.
Ważony (podział ruchu) - rozkład ruchu (na przykład kanaryjski 5/95).
Opóźnienie jest najbliższym PoR/region przez opóźnienie sieci.
Trasa geograficzna - według kraju/kontynentu; przydatne dla przepisów lokalnych/PCI/PII.
Multivalue - kilka „A/AAAA” z kontrolą zdrowia każdego.
Rady
W przypadku krytycznych interfejsów API należy połączyć system latencji + kontrole zdrowotne + krótki TTL.
Gładkie uwolnienia - ważony i stopniowy wzrost akcji.
W przypadku ograniczeń regionalnych - geo i wykazy dozwolonych dostawców.
Zdrowie i automatyczne przełączanie
Kontrole zdrowotne: HTTP (S) (200 OK, ciało/nagłówek), TCP (port), ICMP.
Reputacja/odcisk palca: sprawdź nie tylko port, ale również poprawność backend'a (wersja, build-id).
Próg wrażliwości: 'N' udane/nieudane kontrole z rzędu w celu uniknięcia klapowania.
Metryka: udział punktów końcowych zdrowych, czas reakcji, liczba przełączników.
Obszary prywatne i podział na horyzonty
DNS prywatny: wewnętrzne strefy w VPC/VNet/On-prem (np. 'svc. lokalne. przykład ").
Podział na horyzonty: różne odpowiedzi dla klientów wewnętrznych i zewnętrznych (wewnętrzne IP vs public).
Ochrona przed wyciekami: nie używać nazw „wewnętrznych” na zewnątrz; sprawdzić, czy obszary prywatne nie są rozstrzygane za pośrednictwem publicznych dostawców.
Bezpieczeństwo DNS
DNSSEC: podpisy strefowe (ZSK/KSK), publikacje „DS” w strefie macierzystej, przewrócenie klucza.
CAA: Ograniczenie uwalniania serii TLS do zaufanych urzędów certyfikacji.
DoT/DoH dla rekursorów - szyfrowanie żądań klienta.
ACL/Rate-limit on authoritative: protection against reflective DDoS/ANY requests.
Subdomain Przejęcie: regularnie skanować „wiszące” CNAME/ALIAS dla usług zdalnych (zasoby usunięte - CNAME pozostaje).
Rekordy NS/kleju: spójność między rejestratorem a dostawcą DNS.
SLO i obserwowalność
SLO (przykłady)
Dostępność autentycznych odpowiedzi: ≥ 99. 99 %/30 dni.
Czas reakcji na nawrót (p95): ≤ 50 ms miejscowo/≤ 150 ms globalnie.
Udane kontrole zdrowotne: ≥ 99. 9%, fałszywe dodatnie - ≤ 0. 1%.
Czas propagacji: ≤ 5 min przy TTL 60 s.
Mierniki
RCODE (NOERROR/NXDOMAIN/SERVFAIL), QPS, czas odpowiedzi p50/p95.
IPv6/IPv4 frakcji, rozmiar EDNS, odpowiedzi okrojone (TC).
Liczba przełączników kontrolnych, klapek, błędów podpisu DNSSEC.
Akcje zapytań DoH/DoT (jeśli kontrolujesz rekursję).
Dzienniki
Zapytania (qname, qtype, rcode, client ASN/geo), anomalie (storms ANY, częste NXDOMAIN przez jeden prefiks).
IaC i automatyzacja
Dostawcy terraform/DNS: przechowywanie stref w repozytorium, przegląd PR, plan/aplikacja.
DNS (K8s): automatyczne tworzenie/usuwanie rekordów z usługi Ingress/Service.
Środowisko pośrednie: "dev. '/' stg. "prefiksy i indywidualne konta dostawcy DNS.
Terraform (przykład uproszczony)
hcl resource "dns_a_record_set" "api" {
zone = "example.com."
name = "api"
addresses = ["203.0.113.10","203.0.113.20"]
ttl = 60
}
resource "dns_caa_record" "caa" {
zone = "example.com."
name = "@"
ttl = 3600 record {
flags = 0 tag = "issue"
value = "letsencrypt.org"
}
}Rozdzielacze, pamięć podręczna i wydajność
Unbound/Knot/Bind jest bliżej aplikacji → mniej niż p95.
Włącz prefetch gorących rekordów, serve-stale, gdy władza jest niedostępna.
EDNS (0) i poprawny rozmiar bufora, DNS Ciasteczka, minimalne odpowiedzi.
Oddzielne przepływy rozdzielczości i ruch aplikacji (QoS).
Rozważ negatywny TTL: Wiele NXDOMAIN od złamanego klienta może zatkać pamięć podręczną.
DDoS i odporność
Dostawca Anycast z globalnej agregacji ruchu PoP i bot.
Ograniczenie wskaźnika odpowiedzi (RRL) w zakresie autorytatywnego, ochrony przed wzmocnieniem.
„WSZELKIE” zakaz, EDNS bufora ograniczenia, filtry na „ciężkich” typów.
Segmentacja strefy: krytyczna - u dostawcy z najlepszą tarczą DDoS; mniej krytyczny - oddzielnie.
Dostawca kopii zapasowych (wtórników) z 'AXFR/IXFR' i automatycznym NS na poziomie rejestratora.
Operacje i procesy
Zmiany: PR-recenzja, płyty kanaryjskie, pamięci podręczne (niski TTL → wdrożenie → zwrot TTL).
Rollover DNSSEC: regulacja, okna, monitorowanie ważności (RFC 8901 KSK/ZSK).
Runbook: Kropla PoP, nieprawidłowa delegacja NS, odpadła kontrola zdrowia, masywna SERVFAIL.
Plan DR: alternatywny dostawca DNS, gotowe szablony stref, dostęp do rejestratora, SLA w celu zastąpienia NS.
Lista kontrolna wdrażania
- Dwóch niezależnych autorytatywnych dostawców/RoP (Anycast), poprawny "NS' u rejestratora.
- Strategia TTL: krótka dla dynamiki, długa dla stabilnych rekordów; ujemny TTL pod kontrolą.
- Kontrole i polityka zdrowotna: awaria/ważona/opóźnienie/geo według profilu usługi.
- DNSSEC (KSK/ZSK/DS), „CAA” ogranicza uwalnianie sert.
- IaC dla stref, w przypadku K8s, oddzielnych środowisk/kont.
- Monitorowanie: rcode/QPS/latency/propagation, wpisy przez SERVFAIL/podpisy.
- DDoS: Anycast, RRL, ograniczenia EDNS, blok listy/ACL.
- Przepisy dotyczące migracji domen i obniżenia TTL w ciągu 48-72 godzin.
- Regularny audyt „wiszących” CNAME/ALIAS, MX/SPF/DKIM/DMARC (w przypadku korzystania z poczty).
Częste błędy
Zbyt dużo TTL na krytycznych 'A/AAAA' - długie migracje/fylovers.
Jeden dostawca DNS/jeden PoP jest SPOF.
Brak DNSSEC/CAA - ryzyko zastąpienia/niekontrolowanych serii.
Niespójny podział-horyzont → wewnętrzne nazwy wyciek.
Brak kontroli zdrowotnych GSLB - przełączanie ręczne i opóźnienia.
Zapomniane CNÚ na zewnętrznych usług → ryzyko przejęcia.
Brak IaC → konfiguracje „snowflake” i błędy podczas ręcznych edycji.
Specyfika dla iGaming/fintech
Wersje regionalne i PSP: geo/latency-routing, IP/ASN whitelist partner, szybkie bramy awaryjne.
Wybrania (mecze/turnieje): krótki TTL, rozgrzewka CDN, oddzielne nazwy wydarzeń ('event-N. przykład. com ") z zarządzaną polityką.
Poprawność prawa: zapisać czas i wersję stref podczas zmian krytycznych (dziennik audytu).
Ochrona antyfraud/BOT: oddzielne nazwy tiebreakerów/captcha/punktów końcowych kontroli; szybkie wycofanie się do „czarnej dziury” (zatoki) w atakach.
Mini playbooks
Kanaryjskie uwolnienie przodu (ważone):1. "api-canary. przykład. com "→ 5% ruchu; 2) monitor p95/p99/błędy; 3) wzrost do 25/50/100%; 4) zwijać się podczas degradacji.
Awaryjna awaria:1. TTL 60 s; 2) kontrola zdrowia oznaczony region w dół → GSLB usunięte z odpowiedzi; 3) kontrola rozdzielców zewnętrznych; 4) komunikacja statusowa.
Migracja dostawcy DNS:1. Importowanie strefy do nowego dostawcy; 2) Włącz synchroniczny wtórny dla starego; 3) Zmień 'NS' rejestratora na „ciche” okno; 4) Obserwuj błędy SERVFAIL/val.
Wynik
Niezawodna pętla DNS jest autorytetem Anycast + rozsądne TTL + health/latency routing + DNSSEC/CAA + IaC i obserwowalność. Rejestruj procesy migracji i rolloverów, utrzymuj dostawcę kopii zapasowych, regularnie sprawdzaj strefę pod kątem „wiszących” rekordów - a Twoi użytkownicy stabilnie dotrą na pożądane fronty nawet w najgorętszej godzinie.