DNS მარშრუტიზაცია და failover

1) DNS- ის როლი უარის თქმაში

• წვდომა (სწრაფი/საიმედო სწრაფი);
• პროდუქტიულობა (geo/latency-routing);
• ღირებულება (ინტერრეგიონალური egress და 3rd-party ზარების შემცირება);
• უსაფრთხოება (DNSSEC, anti-hijack, CAA/DMARC/SPF კონტროლი).

გასაღები: მოკლე TTL, სადაც დინამიკა მნიშვნელოვანია და სტაბილური ზონალური არქიტექტურა (public + კერძო, split-horizon).

2) ჩანაწერების და პრაქტიკის ტიპები

A/AAAA - ძირითადი მისამართები; ყოველთვის გამოაქვეყნეთ IPv6 სადაც ეს შესაძლებელია.
CNAME vs ALIAS/ANAME: გამოიყენეთ ALIAS/ANAME დომენის ფესვზე (ან პროვაიდერის აფთიაქი).
TXT - SPF/DMARC/DKIM, გადამოწმება; CAA - სერთიფიკატის კურსდამთავრებულთა შეზღუდვა.
SRV/NS - მომსახურების დისკი და დელეგირება.
SVCB/HTTPS არის თანამედროვე ალტერნატიული პრიორიტეტული და პარამეტრების მექანიზმი (ALPN, პორტები).

რეკომენდაცია: ჩაწერეთ TTL სტანდარტები კლასებში (edge/API/სტატიკა).

3) მარშრუტიზაციის პოლიტიკა

Weighted (შეჩერებული) - კონტროლირებადი ტრაფიკის წილი (კანარი/ცისფერი-მწვანე).
Latency-based - უახლოესი აუზის არჩევანი.
Geo-routing - ქვეყნის მასშტაბით/კონტინენტი/რეგიონი; მნიშვნელოვანია მონაცემთა რეაბილიტაციისთვის.
Failover (პრიმერა/მეორე) - აქტიური მონიტორინგი და გადართვა.
Multi-value - რამდენიმე A/AAA; თავად კლიენტი ირჩევს (არ ცვლის ჯანმრთელობის შემოწმებებს).
Proximity/ASN როტინგი - ზოგიერთი პროვაიდერის მიერ: კლიენტის ქსელის მიხედვით.

დააკავშიროთ: geo-latency-weight-health.

4) TTL, ქეშირება და პროპაგანდა

TTL API/დინამიკა: 30-120 წმ (ბალანსი ფალოვერის სიჩქარესა და დატვირთვას შორის).
Static/CDN: 1–24 ч.
უარყოფითი TTL (SOA 'Minimum') - 60-300 ევრო, წინააღმდეგ შემთხვევაში NXDOMAIN იქნება „წებოვანი“.
დაიმახსოვრე: საჭრელები არ არიან ვალდებულნი დაუყოვნებლივ გადააგდონ ქეში; გაითვალისწინეთ „ბინძური კუდი“.

5) ჯანმრთელობა და ენდოინტის შემოწმება

ჯანმრთელობის შემოწმებები რამდენიმე რეგიონიდან: TCP/443 + HTTP 2xx/3xx და ბიზნეს კრიტერიუმების ლამბდა შემოწმება (მაგალითად, წარმატებული '/health? deep = ნამდვილი დამოკიდებულების შემოწმებით).
სინთეზური (RUM/აქტივი): API ტესტები მთავარ მარშრუტებზე, TLS/OCSP შემოწმება, DNSSEC შემოწმება.
გამოიფინა '/ready '(ღრმა) და '/live' (ზედაპირული); DNS აუზი მიბმული/ready.

6) საზოგადოებრივი vs პირადი DNS (split-horizon)

საზოგადოებრივი ზონა - კლიენტის წვდომა.
Private zone არის შიდა რეზოლუცია კერძო endpoints (VPC/VNet, on-prem).
Conditional forwarding между on-prem ↔ cloud, region ↔ region.
სახელწოდება: 'app. <brand>.<region>.internal. corp` и `api. <brand>.com`.

7) უსაფრთხოება: DNSSEC და დომენის პოლიტიკა

DNSSEC: ჩართეთ ზონის ხელმოწერა (KSK/ZSK), დააკვირდით გასაღებების ბრუნვას და ნდობის ჯაჭვს.
CAA: ჩამოთვალეთ დასაშვები CA; ჩართეთ 'iodef' ალერტებისთვის.
SPF/DMARC/DKIM: ფოსტის რეპუტაცია და ფიშინგისგან დაცვა.
Registrar-lock და MFA DNS პროვაიდერის ანგარიშებზე; ცვლილების ჟურნალი (WORM საცავი).

8) Failover- ის დიზაინი

8. 1 მოდელები

აქტიური აქტივობა: ორი + ჯანმრთელი აუზი; ბალანსი ლინზების/შაბათ-კვირის საშუალებით, ჯანმრთელობის შემოწმებები გამორიცხავს არაჯანსაღი.
Active-Passive: მთავარი აუზი + ნაკრძალი (0% წონა უბედური შემთხვევის წინ).
რეგიონალური რინგი: ტრეფიკი „მეზობელ“ რეგიონში ადგილობრივ ავარიაში.
Degraded mode: ჩაწერა „მსუბუქი“ საიტისთვის/landing, თუ ზურგჩანთა არ არის ხელმისაწვდომი.

8. 2 ეტაპობრივი სცენა

1. მონიტორინგი აფიქსირებს '/ready 'დეგრადაციას.
2. DNS ცვლის პასუხებს (გამორიცხავს აუზს ან ცვლის წონას).
3. ტრაფიკი მიდის ჯანმრთელ რეგიონში, TTL განსაზღვრავს სიჩქარეს.
4. სტაბილიზაციის შემდეგ - გრეის პერიოდი (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 - geo/ASN და failover აუზი (იდეა)

Load Balancer Pools ჯანმრთელობის შემოწმებებით (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-ე Percentil, TTL- ში ახალი (არა-ფოლადის) პასუხების წილი.
SLO: მაგალითად, '99. 95% 'წარმატებული პასუხები - 100 ms.
მეტრიკა: NXDOMAIN-rate, SERVFAIL-rate, Health-state ტყვიები, რეგიონების ტრეფიკის წილი, კანარის წილი.
Exemplars: დააკავშირეთ SLI სინთეზში HTTP ტრეკების საშუალებით.

11) ტესტირება და ოპერაცია

სინთეზური სხვადასხვა ASN/რეგიონიდან (RIPE Atlas, Catchpoint, k6-DNS).
dnsviz/' delv 'DNSSEC- ის შესამოწმებლად;' dig + trace 'ანომალიებში.
Staging ზონა ('stg. example. com ') ფეილოვერის რეპეტიციებისთვის; rehearsal სკრიპტი ცვლის წონას/პრიორიტეტებს და უბრუნდება უკან.
Runbook: ვინ და როგორ ხელით ზრდის/ამცირებს წონას, როგორ გამორთეთ აუზები, როგორ უნდა შეასრულოთ „freeze“.

12) ანტიპატერები

TTL = 3000 + კრიტიკულ A/AAA - ნელი/ქაოტური ფეილოვერი.
ჯანმრთელობის შემოწმებების არარსებობა ან მხოლოდ TCP პორტის შემოწმება ბიზნეს ინვარიანტების გარეშე.
CNAME ჯაჭვების თაიგული - ნელი რეზოლები, ქეში ქაოსი.
ერთადერთი DNS პროვაიდერი საშუალო/axfr ნაკრძალის გარეშე.
დაუმთავრებელი ზონა DNSSEC- ის მოთხოვნით; შეუსაბამო CAA.
ჩანაწერები, რომლებიც მიუთითებს კერძო ზურგჩანთების/BD საჯარო IP.

13) iGaming/ფინანსების სპეციფიკა

იურისდიქცია: geo/country-routing მოთხოვნების დასაკმაყოფილებლად (გადამისამართება ადგილობრივ დომენზე/ფრონტზე).
PSP/KYC: ცალკეული TTL და ფეილოვერის პოლიტიკოსების ხაზგასმა; სწრაფი გადასვლა სარეზერვო PSP- ზე.
საპასუხისმგებლო თამაში: იურიდიული გვერდებით ჩანაცვლება ყოველთვის ხელმისაწვდომია (სარეზერვო სტატიკები/CDN).
აუდიტი: ზონის ცვლილების ჟურნალი WORM საცავში, ცვლილებების ხელმოწერა და რეგულარული შურისძიება.
ბლოკის ფურცლები: DNS წესები რეგიონებში (edge ფილტრაცია + DNS მარშრუტიზაცია).

14) მზადყოფნის ჩეკის სია

• პროფილები TTL კლასებში; უარყოფითი TTL-300.
• ორი დამოუკიდებელი anycast ქსელი DNS (primary/საშუალო), MFA/რეგისტრატორი-ლოკი.
• პოლიტიკოსები: geo/latence/weight + Health checks რამდენიმე რეგიონიდან.
• DNSSEC შედის, CAA/DMARC/DKIM/SPF აქტუალურია.
• Split-horizon (public/private), პირადი ზონები შიდა ტრაფიკისთვის.
• Runbook faylover/დაბრუნება, 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, შეინარჩუნეთ საშუალო DNS. გააკეთეთ rehearsal faylover და დააკვირდით SLI/SLO DNS. IGaming- ისთვის გაითვალისწინეთ PSP/KYC დომენების იურისდიქციები და რეზერვაცია ცალკეული წესებით და WORM- ში ცვლილებების გაუმჯობესებით.