DNS მენეჯმენტი და მარშრუტიზაცია
მოკლე რეზიუმე
DNS არის „სახელების დონის როუტერი“. ეს დამოკიდებულია კომპეტენტურ TTL- ზე, ზონებზე და პოლიტიკოსზე, თუ რამდენად სწრაფად და პროგნოზირებულად მიიღებენ მომხმარებლები სასურველ ფრონტებზე/კარიბჭეებზე. მინიმალური ნაკრები: Anycast პროვაიდერი, ჯანმრთელი TTL, Health checks ავტომატური failover, DNSSEC + CAA, IaC კონტროლი და დაკვირვება (SLO რეაგირებისა და რეზინის დროს).
ძირითადი არქიტექტურა
ავტორიტეტული სერვერები (ზონები) პასუხისმგებელნი არიან კომპანიის დომენებზე.
რეკურსიული რეზერვუარები (clients/ISP/საკუთარი) - იკითხება ფესვი TLD და ავტორიტეტული.
Anycast არის იგივე IP მისამართი ბევრ PoP- ზე: ახლო PoP უფრო სწრაფად პასუხობს და განიცდის უბედურ შემთხვევებს.
ზონები და დელეგაცია
„NS“ - ის ფესვის ზონა ავტორიტეტული სერვერების პროვაიდერებისთვის.
ქვედანაყოფები (მაგალითად, 'ap. example. com ') შეგიძლიათ დელეგირება მოახდინოთ დამოუკიდებლობისთვის ინდივიდუალურ' NS '/პროვაიდერებზე.
ჩანაწერების ტიპები (მინიმალური)
'A '/' AAAA' - IPv4/IPv6 მისამართები.
'CNAME' - ფსევდონიმი სახელით; არ გამოიყენოთ ზონის ფესვზე (ამის ნაცვლად, ALIAS/ANAME პროვაიდერების მიერ).
'TXT' - გადამოწმება, SPF, საერთო ეტიკეტები.
'MX' - ფოსტა (თუ გამოიყენება).
'SRV' - სერვისები (SIP, LDAP და ა.შ.).
'CAA' - ვისაც შეუძლია დომენის სერთიფიკატების გაცემა.
'NS '/' SOA' - დელეგაცია/ზონის პარამეტრები.
'DS' - DNSSEC გასაღებები მშობლის TLD- სთვის.
ზონის მაგალითი (ფრაგმენტი)
$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 და ქეშირება
მოკლე TTL (30-300 გ) - დინამიკისთვის (API ფრონტები, failover).
საშუალო TTL (300-3600 გ) არის CDN/სტატიკისთვის.
გრძელი TTL (1 დღე) - იშვიათი ცვლილებებისთვის (MX/NS/DS).
მიგრაციის დაგეგმვა, შეამცირეთ TTL წინასწარ 24-72 საათში.
გაითვალისწინეთ Negative Caching TTL (NXDOMAIN): კონტროლდება 'SOA MINIMUM'.
მარშრუტიზაციის პოლიტიკა (GSLB დონე)
Failover (Active/passive) - ჩვენ ვაძლევთ მთავარ IP- ს ყალბი ჩეკით, შემდეგ რეზერვი.
Weighted (traffic-split) - ტრაფიკის განაწილება (მაგალითად, კანი 5/95).
Latency-based არის უახლოესი ქსელის შეფერხების RoP/რეგიონი.
Geo-routing - ქვეყნის/კონტინენტის მიხედვით; სასარგებლოა ადგილობრივი კანონებისთვის/PCI/PII.
მრავალმხრივი - რამდენიმე 'A/AAAA "თითოეული ჯანმრთელობის შემოწმებით.
რჩევები
კრიტიკული API- სთვის დააკავშირეთ latency-based + Health-checks + მოკლე TTL.
გლუვი გამოშვებისთვის - ყოველკვირეული და წილის თანდათანობითი ზრდა.
რეგიონალური შეზღუდვებისთვის - geo და ნებადართული პროვაიდერების სიები.
ჯანმრთელობა და ავტომატური გადართვა
ჯანმრთელობის შემოწმებები: HTTP (S) (200 OK, სხეული/სათაური), TCP (პორტი), ICMP.
რეპუტაცია/fingerprint: შეამოწმეთ არა მხოლოდ პორტი, არამედ backend 'a (ვერსია, build-id) სისწორე.
მგრძნობელობის ბარიერი: 'N' წარმატებული/წარუმატებელი შემოწმება ზედიზედ, რათა თავიდან იქნას აცილებული flopping.
ჭამა მეტრიკი: healthy-endpoints- ის წილი, რეაქციის დრო, გადართვის რაოდენობა.
კერძო ზონები და split-horizon
პირადი DNS: შიდა ზონები VPC/VNet/On-prem (მაგალითად, 'svc. local. example`).
Split-horizon: სხვადასხვა პასუხები შიდა და გარე მომხმარებლებისთვის (შიდა IP vs საჯარო).
გაჟონვისგან დაცვა: ნუ გამოიყენებთ „შიდა“ სახელებს გარეთ; შეამოწმეთ, რომ კერძო ზონები არ იშლება საზოგადოებრივი პროვაიდერების მეშვეობით.
DNS უსაფრთხოება
DNSSEC: ზონის ხელმოწერები (ZSK/KSK), მშობლების ზონაში 'DS' გამოქვეყნება, გასაღების როლიკერი.
CAA: შეზღუდეთ TLS სერიების გამოშვება CA- ს ნდობით.
DoT/DoH რეკურსორებისთვის - მომხმარებლის მოთხოვნების დაშიფვრა.
ACL/ავტორიტეტული ლიმიტი: დაცვა DDoS/ANY მოთხოვნებისგან.
Subdomain Takeover: რეგულარულად სკანირება CNAME/ALIAS დისტანციურ სერვისებზე (რესურსი ამოღებულია - CNAME დარჩა).
NS/Glue ჩანაწერები: თანმიმდევრულობა რეგისტრატორსა და DNS პროვაიდერს შორის.
SLO და დაკვირვება
SLO (მაგალითები)
ავტორიტეტული პასუხების ხელმისაწვდომობა: 99 ევრო. 99 %/30 დღე.
რეკურსორზე პასუხის დრო (p95): 50 ms ადგილობრივად/150 ms გლობალურად.
ჯანმრთელობის შემოწმებების წარმატება: 99 ევრო. 9%, ყალბი პროცესები - 0 ევრო. 1%.
ცვლილების შემდეგ წასვლის დრო: 5 წუთი TTL 60-ზე.
მეტრიკი
RCODE (NOERROR/NXDOMAIN/SERVFAIL), QPS, p50/p95 პასუხის დრო.
აქციები IPv6/IPv4, EDNS ზომა, Truncated (TC) პასუხები.
Health-check- ის გადართვის, flapping, DNSSEC- ის ხელმოწერის შეცდომები.
DoH/DoT მოთხოვნების აქციები (თუ აკონტროლებთ რეკურსორს).
ლოგები
მოთხოვნები (qname, qtype, rcode, client ASN/geo), ანომალიები (ANY ქარიშხლები, ხშირი NXDOMAIN თითო პრეფიქსი).
IaC და ავტომატიზაცია
Terraform/DNS Providers: შეინახეთ ზონები საცავებში, PR review, გეგმა/approve.
ExternalDNS (K8s): ჩანაწერების ავტომატური შექმნა/მოცილება Ingress/Service- დან.
შუალედური გარემოცვები: პრეფიქსი 'dev. '/' stg. "და DNS პროვაიდერის ცალკეული ანგარიშები.
Terraform (გამარტივებული მაგალითი)
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"
}
}რეზერვები, ქეში და პროდუქტიულობა
საკუთარი რეკურსორები (Unbound/Knot/Bind) უფრო ახლოს არიან განაცხადებთან, ვიდრე p95.
ჩართეთ ცხელი ჩანაწერების prefetch, serve stale, უფლებამოსილების მიუწვდომლობის შემთხვევაში.
EDNS (0) და ბუფერის სწორი ზომა, DNS Cookies, minimal-responses.
გაიზიარეთ რეზინის ნაკადები და აპლიკაციების ტრაფიკი (QoS).
გაითვალისწინეთ Negative TTL: ბევრი NXDOMAIN „გატეხილი“ კლიენტისგან შეიძლება ქეში გაიტანოს.
DDoS და სტაბილურობა
Anycast პროვაიდერი გლობალური POP- ით და bot ტრაფიკის ერთეულით.
Response Rate Limiting (RRL) ავტორიტეტული, amplification დაცვა.
აკრძალვა 'ANY', EDNS ბუფერის შეზღუდვა, ფილტრები „მძიმე“ ტიპებისთვის.
ზონების სეგმენტი: კრიტიკული - პროვაიდერზე, რომელსაც აქვს საუკეთესო DDoS ფარი; ნაკლებად კრიტიკული - ცალკე.
სარეზერვო პროვაიდერი (მეორე) 'AXFR/IXFR' და NS ავტომატური ფეილერი რეგისტრატორის დონეზე.
ოპერაციები და პროცესები
ცვლილებები: PR მიმოხილვა, ჩაწერა, ქეში დათბობა (დაბალი TTL deploy TTL- ის დაბრუნება).
Rollover DNSSEC: რეგულაციები, ფანჯრები, შესაბამისობის მონიტორინგი (RFC 8901 KSK/ZSK).
Runbook: PoP ვარდნა, არასწორი NS დელეგაცია, ამოღებული ჯანმრთელობის შემოწმება, მასობრივი SERVFAIL.
DR გეგმა: ალტერნატიული DNS პროვაიდერი, მზა ზონების შაბლონები, რეგისტრატორზე წვდომა, SLA შეცვალა NS.
განხორციელების შემოწმების სია
- ორი დამოუკიდებელი ავტორიტეტული პროვაიდერი/RoP (Anycast), რეგისტრატორის სწორი 'NS'.
- TTL სტრატეგია: მოკლე დინამიკისთვის, გრძელი სტაბილური ჩანაწერებისთვის; negative TTL კონტროლდება.
- ჯანმრთელობის შემოწმებები და პოლიტიკოსები: failover/wighted/latence/geo მომსახურების პროფილის მიხედვით.
- DNSSEC (KSK/ZSK/DS), 'CAA' ზღუდავს ეპიზოდების გამოშვებას.
- IaC ზონებისთვის, ExternalDNS K8s- ისთვის, ინდივიდუალური გარემო/ანგარიშები.
- მონიტორინგი: rcode/QPS/latency/propagation, SERVFAIL ალერტები/ხელმოწერები.
- DDoS: Anycast, RRL, EDNS შეზღუდვები, სიების ბლოკი/ACL.
- დომენის მიგრაციისა და TTL- ის შემცირების რეგულაციები 48-72:
- „ჩამოკიდებული“ CNAME/ALIAS, MX/SPF/DKIM/DMARC რეგულარული აუდიტი (თუ ფოსტა გამოიყენება).
ტიპიური შეცდომები
კრიტიკულ „A/AAA“ ძალიან დიდი TTL გრძელი მიგრაციაა/ფეილოვერები.
ერთი DNS/ერთი PoP მიმწოდებელი არის SPOF.
DNSSEC/CAA- ს არარსებობა არის ჩანაცვლების/უკონტროლო სერტების რისკი.
შეუსაბამო split-horizon შინაგანი სახელების გაჟონვა გარეთ.
GSLB- ზე ჯანმრთელობის შემოწმებები არ არის ხელების შეცვლა და შეფერხება.
გარე სერვისებზე დავიწყებული CNAME takeover რისკს წარმოადგენს.
IaC- ის არარსებობა - „ფიფქია“ - კონფიგი და შეცდომები ხელით გადასინჯვებში.
სპეციფიკა iGaming/fintech
რეგიონალური ვერსიები და PSP: geo/latency-routing, პარტნიორების IP/ASN თეთრი სიები, სწრაფი სწრაფი სწრაფი კარიბჭე.
პიკი (მატჩები/ტურნირები): მოკლე TTL, გაათბეთ CDN, ინდივიდუალური სახელები Ivents ('event-N. example. com ') კონტროლირებადი პოლიტიკით.
იურიდიული სისწორე: დაფიქსირდეს ზონების დრო და ვერსია კრიტიკულ ცვლილებებში (ჟურნალი აუდიტისთვის).
ანტიფროდი/BOT დაცვა: ინდივიდუალური სახელები tiebreakers/capchi/check endpoints; სწრაფი გაყვანა „შავ ხვრელში“ შეტევების დროს.
მინი ფლეიბუკები
წინა კანარის გამოშვება:1. `api-canary. example. com '- 5% ტრაფიკი; 2) დააკვირდით r95/r99/შეცდომებს; 3) გაზარდეთ 25/50/100%; 4) გადინება დეგრადაციის დროს.
გადაუდებელი failover:1. TTL 60 გვ; 2) Health-check- მა შეაჩერა down რეგიონი - GSLB ამოიღო პასუხები; 3) გარე რეზერვისტების შემოწმება; 4) სტატუსის კომუნიკაცია.
DNS პროვაიდერის მიგრაცია:1. ზონის იმპორტი ახალ პროვაიდერში; 2) ჩართეთ სინქრონული საშუალო ძველში; 3) შეცვალეთ 'NS' რეგისტრატორისგან „მშვიდი“ ფანჯარაში; 4) ჩვენ ვაკვირდებით SERVFAIL/val შეცდომებს.
შედეგი
საიმედო DNS წრე არის Anycast ავტორიტეტები + გონივრული TTL + ჯანმრთელობის/შეფერხების მარშრუტიზაცია + DNSSEC/CAA + IaC და დაკვირვება. დააფიქსირეთ მიგრაციისა და როლოვერების პროცესები, შეინახეთ სარეზერვო პროვაიდერი, რეგულარულად შეამოწმეთ ზონა „ჩამოკიდებული“ ჩანაწერებისთვის - და თქვენი მომხმარებლები სტაბილურად მოხვდებიან სწორ ფრონტებზე, თუნდაც ყველაზე ცხელ საათში.