Δρομολόγηση και αποτυχία DNS
1) Ο ρόλος του DNS στην ανοχή βλάβης
Το DNS είναι ο πρώτος δρομολογητής του χρήστη. "Τα ακόλουθα εξαρτώνται από το σχεδιασμό του:- Διαθεσιμότητα (ταχεία/αξιόπιστη αποτυχία)·
- Επιδόσεις (geo/latency-routing)·
- κόστος (ελαχιστοποίηση της διαπεριφερειακής εξόδου και των κλήσεων τρίτου μέρους)·
- Ασφάλεια (DNSSEC, αντι-αεροπειρατεία, έλεγχος CAA/DMARC/SPF).
Κλειδί: σύντομες TTL όπου η δυναμική είναι σημαντική και σταθερή αρχιτεκτονική ζωνών (δημόσιος + ιδιωτικός, διαχωριστικός ορίζοντας).
2) Τύποι αρχείων και πρακτικών
A/AAAA - κύριες διευθύνσεις· δημοσιεύει πάντα το IPv6 όπου είναι δυνατόν.
CNAME vs ALIAS/ANAME: Στη ρίζα του τομέα, χρησιμοποιήστε το ALIAS/ANAME (ή τον πάροχο apex-flattening).
TXT - SPF/DMARC/DKIM, επαλήθευση· CAA - περιορισμός των εκδοτών πιστοποιητικών.
SRV/NS - ανακάλυψη υπηρεσιών και ανάθεση καθηκόντων.
Η SVCB/HTTPS είναι ένας σύγχρονος εναλλακτικός μηχανισμός με προτεραιότητα και παραμέτρους (ALPN, θύρες).
Σύσταση: καθορισμός προτύπων TTL ανά κατηγορία (άκρη/API/στατική).
3) Πολιτικές δρομολόγησης
Σταθμισμένα - ελεγχόμενα μερίδια κίνησης (καναρίνια/γαλάζιο-πράσινο).
Με βάση την καθυστέρηση - Επιλέξτε τη δεξαμενή που βρίσκεται πιο κοντά στην καθυστέρηση.
Geo-routing - ανά χώρα/ήπειρο/περιοχή· σημαντικές για την κατοικία στα δεδομένα.
Αποτυχία (πρωτογενής/δευτεροβάθμια) - ενεργός παρακολούθηση και αλλαγή.
Πολλαπλή αξία - πολλές A/AAAA· ο πελάτης επιλέγει τον εαυτό του (δεν αντικαθιστά τους υγειονομικούς ελέγχους).
Προσέγγιση/δρομολόγηση ASN - για ορισμένους παρόχους: μέσω του δικτύου του πελάτη.
Συνδυασμός: γεωγραφική καθυστέρηση βάρος υγεία.
4) TTL, αποθήκευση και διάδοση
TTL API/ομιλητές: 30-120 s (ισορροπία μεταξύ στροφών και φορτίου).
Στατική/CDN: 1-24 ч.
Αρνητικό TTL (SOA 'Minimum') - ≤ 60-300 s, διαφορετικά το NXDOMAIN θα είναι «κολλώδες».
Θυμηθείτε: δεν απαιτείται να πετάξετε αμέσως την κρύπτη. σκεφτείτε την «βρώμικη ουρά».
5) Υγεία και έλεγχος των τελικών σημείων
Έλεγχοι υγείας από πολλές περιφέρειες: TCP/443 + HTTP 2xx/3xx και έλεγχοι επιχειρηματικών κριτηρίων λάμδα (π.χ. επιτυχής "/υγεία βαθύ = αληθές "με έλεγχο εξάρτησης).
Συνθετικό (RUM/ενεργό): δείγματα API κατά μήκος των κύριων διαδρομών, έλεγχοι TLS/OCSP, έλεγχοι DNSSEC.
Εκτίθενται «/έτοιμα »(βαθιά) και «/ζωντανά» (επιφανειακά). Δεσμεύστε τη δεξαμενή DNS στο/έτοιμο.
6) Δημόσιο έναντι ιδιωτικού DNS (διαχωριστικός ορίζοντας)
Δημόσια ζώνη - πρόσβαση των πελατών.
Ιδιωτική ζώνη - εσωτερική ανάλυση σε ιδιωτικά τελικά σημεία (VPC/VNet, on-prem).
Υπό όρους προώθηση между on-prem ↔ νέφος, περιοχή ↔ περιοχή.
Όνομα: 'api. <εμπορικό σήμα>. <περιφέρεια> .internal. corp 'и' api. <εμπορικό σήμα> .com '.
7) Ασφάλεια: DNSSEC και πολιτική τομέα
DNSSEC: Ενεργοποιήστε την υπογραφή ζώνης (KSK/ZSK), παρακολουθήστε την εναλλαγή κλειδιών και την αλυσίδα εμπιστοσύνης.
CAA: κατάλογος έγκυρων CA· συμπεριλαμβάνεται το «iodef» για τις καταχωρίσεις.
SPF/DMARC/DKIM: φήμη του ταχυδρομείου και προστασία από phishing.
κλείδωμα γραμματέα και ΜΧΣ για λογαριασμούς παρόχου DNS· αλλαγή ημερολογίου (κατάστημα WORM).
8) Σχεδιασμός αποτυχίας
8. 1 Υποδείγματα
Ενεργό: δύο + υγιείς δεξαμενές. ισορροπία λόγω καθυστέρησης/βάρους, οι υγειονομικοί έλεγχοι αποκλείουν την ανθυγιεινή κατάσταση.
Ενεργός παθητική: κύρια δεξαμενή + αποθεματικό (0% βάρος πριν από το ατύχημα).
Περιφερειακός δακτύλιος: η κυκλοφορία στην «γειτονική» περιοχή σε περίπτωση τοπικής καταστροφής.
Κατάσταση υποβάθμισης: εγγραφή στην «εύκολη» θέση/προσγείωση εάν η υποστήριξη δεν είναι διαθέσιμη.
8. 2 Σενάριο βήμα προς βήμα
1. Η παρακολούθηση καταγράφει υποβάθμιση του '/έτοιμου '.
2. Το DNS αλλάζει τις απαντήσεις (εξαλείφει το σύνολο ή μεταβάλλει τα βάρη).
3. Η κυκλοφορία πηγαίνει σε μια υγιή περιοχή, το TTL καθορίζει την ταχύτητα.
4. Μετά τη σταθεροποίηση - περίοδος χάριτος (15-30 λεπτά) και μόνο τότε η επιστροφή των κλιμάκων.
9) Παραδείγματα διαμόρφωσης
9. 1 Διαδρομή AWS 53 - καθυστέρηση + στάθμιση υγείας +
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 pool (ιδέα)
Το Load Balancer Pools c health-check (HTTP/TCP), το Load Balancer με Geo Steering (ηπείρους/χώρες) και τη συγγένεια συνεδρίας.
Fallback: Κανόνας σελίδας/μετατροπή κανόνα σε απλοποιημένο backend στις κορυφές 5xx.
9. 3 Azure/GCP
Azure Traffic Manager: Προτεραιότητα/σταθμισμένη/απόδοση/γεωγραφική.
Google Cloud Load Balancing + Cloud DNS πολιτική: γεωπολιτική + υγειονομικοί έλεγχοι через Εξωτερική HTTP (S) LB.
10) Παρατηρησιμότητα και SLO DNS
SLI: Ανάλυση ποσοστού επιτυχίας, 95ο εκατοστημόριο του χρόνου ανάλυσης, αναλογία νωπών (μη μπαγιάτικων) απαντήσεων εντός του TTL.
SLO: για παράδειγμα, '99. 95% των επιτυχημένων απαντήσεων ≤ 100 ms.
Μετρήσεις: NXDOMAIN-rate, SERVFAIL-rate, health-state pools, traffic share by region, canary share.
Παραδείγματα: Συσχετίστε το SLI με ίχνη HTTP μέσω 'trace _ id' στα συνθετικά.
11) Δοκιμή και λειτουργία
Συνθετικά από διαφορετικές περιοχές ASN (RIPE Atlas, Catchpoint, k6-DNS).
dnsviz/' delv 'για τον έλεγχο του DNSSEC·' ανασκαφές + ίχνη 'για ανωμαλίες.
Ζώνη στάθμευσης ('stg. παράδειγμα. com ') για τις πρόβες feilover, το σενάριο της πρόβας αλλάζει βάρη/προτεραιότητες και αποδόσεις.
Runbook: ποιος και πόσο χειροκίνητα αυξάνει/μειώνει τα βάρη, πώς να απενεργοποιήσει την πισίνα, πώς να εκτελέσει «πάγωμα».
12) Αντιπατερίδια
TTL = 3000 + σε κρίσιμο A/AAAA → αργό/χαοτικό feilover.
Δεν υπάρχουν υγειονομικοί έλεγχοι ή έλεγχοι μόνο σε λιμένα TCP χωρίς αναλλοίωτες επιχειρηματικές δραστηριότητες.
Ένα μάτσο αλυσίδες CNAME → αργές αναλύσεις, κρύπτουν χάος.
Ο μοναδικός πάροχος DNS χωρίς αντίγραφο ασφαλείας δευτερεύοντος/άξονα.
μη υπογεγραμμένη ζώνη όταν απαιτείται DNSSEC· μη σχετικές CAA.
Καταχωρήσεις που δείχνουν το δημόσιο IP ιδιωτικών backends/βάσεων δεδομένων.
13) Ιδιαιτερότητες του iGaming/Finance
Δικαιοδοσίες: geo/country-routing για συμμόρφωση (ανακατευθύνσεις σε τοπικό τομέα/μέτωπο).
PSP/KYC: ειδικοί υποτομείς με επιμέρους πολιτικές TTL και feilover· γρήγορη μεταφορά σε PSP σε αναμονή.
Υπεύθυνο παιχνίδι: οι υποδιαιρέσεις με νόμιμες σελίδες είναι πάντα διαθέσιμες (εφεδρικό στατικό/CDN).
Έλεγχος - Αλλαγές ζώνης καταγραφής σε αποθήκη WORM, αλλαγές υπογραφής και τακτική επανεξέταση.
Καταλόγους τμημάτων: κανόνες συμμόρφωσης DNS ανά περιφέρεια (φιλτράρισμα ακμών + δρομολόγηση DNS).
14) Κατάλογος ελέγχου ετοιμότητας Prod
- προφίλ TTL ανά κατηγορία· Αρνητικό TL ≤ 300 s.
- Δύο ανεξάρτητα δίκτυα DNS (πρωτοβάθμια/δευτεροβάθμια), κλείδωμα MAX/μητρώου.
- Πολιτικές: γεω/καθυστέρηση/βάρος + υγειονομικοί έλεγχοι από πολλές περιφέρειες.
- Ενεργοποίηση της DNSSEC, επικαιροποιημένη CAA/DMARC/DKIM/SPF.
- Split-horizon (δημόσιος/ιδιωτικός τομέας), ιδιωτικές ζώνες εσωτερικής κυκλοφορίας.
- Flyer/return runbook, proearsal script, canary domains.
- Παρακολούθηση SLI/SLO, προειδοποιήσεις για την ανάπτυξη NXDOMAIN/SERVFAIL/RTT.
- Χώρος στάθμευσης και τακτική αποτυχία «ασκήσεων».
- Για το iGaming: δρομολόγηση ανά δικαιοδοσία, ξεχωριστοί τομείς για το PSP/KYC, αμετάβλητος έλεγχος.
15) TL· DR
Χάραξη συνδυασμένης πολιτικής: geo/latency + υγειονομικοί έλεγχοι + σταθμίσεις, με TTL 30-120 s στον ομιλητή. Χωριστό δημόσιο/ιδιωτικό (split-horizon), επιτρέπει DNSSEC και CAA, διατηρεί δευτερεύον DNS. Κάντε μια πρόβα-feilover και παρατηρήστε SLI/SLO DNS. Για το iGaming, εξετάστε τις δικαιοδοσίες και τις κρατήσεις τομέα PSP/KYC με ξεχωριστούς κανόνες και καταγραφή των αλλαγών στο WORM.