ניתוב DNS וכישלון

1) תפקיד DNS בסובלנות לקויה

• זמינות (כשל מהיר/אמין);
• ביצועים (ניתוב גיאו/latency);
• עלות (מזעור יציאות בין-אזוריות וקריאות צד שלישי);
• אבטחה (DNSEC, אנטי-חטיפה, CAA/DMARC/SPF control).

מפתח: TLs קצר שבו הדינמיקה חשובה, וארכיטקטורה זונית יציבה (ציבורית + פרטית, אופק מפוצל).

2) סוגי רשומות ומנהגים

A/AAAA - כתובות ראשיות; תמיד לפרסם IPv6 בכל מקום אפשרי.

CNAME נגד ALIAS/ANAME: בשורש התחום, השתמש בכינויים/ANAME

TXT - SPF/DMARC/DKIM, אימות; CAA - הגבלה של שליחי תעודות.
SRV/NS - תגלית שירות ומשלחת.
SVCB/HTTPS הוא מנגנון אלטרנטיבי מודרני בעל עדיפות ופרמטרים (ALPN, ports).

המלצה: תיקון תקני TTL לפי רמה (edge/API/static).

3) מדיניות ניתוב

מניות משוקללות של תנועה (קנריות/כחול-ירוק).
תבחר את הבריכה הקרובה ביותר באיחור.
ניתוב גאו - על ידי מדינה/יבשת/אזור; חשוב להתמחות בנתונים.
כשל (ראשי/משני) - ניטור פעיל והחלפה.
רב-ערך - מספר A/AAA; הלקוח בוחר את עצמו (לא מחליף בדיקות בריאות).
ניתוב קרבה/ASN - עבור ספקים מסוימים: מעל הרשת של הלקוח.

Combine: geo # latency # health.

4) TTL, מטמון והפצה

TTL API/רמקולים: 30-120 S (איזון בין מהירות פיילר לעומס).
סטטי/CDN: 1-24.
TTL שלילי (SOA 'מינימום') - 60-300 S, אחרת NXDOMAIN יהיה ”דביק”.
זכור: נחושים אינם נדרשים להשליך מייד את המטמון; שקול את ”הזנב המלוכלך”.

5) בריאות ובדיקת נקודות סוף

בדיקות בריאות מאזורים מרובים: TCP/443 + HTTP 2xx/3xx ו-Lambda בדיקת קריטריונים עסקיים (לדוגמה: מצליח '/בריאות? עמוק נכון "עם בדיקת תלות).
דגימות API לאורך המסלולים הראשיים, בדיקות TLS/OCSP, בדיקות DNSEC.
חשיפת '/ready '(עמוק) ו '/live' (שטחי); לקשור את בריכת DNS ל/מוכן.

6) ציבורי נגד פרטי DNS (אופק מפוצל)

אזור ציבורי - גישה ללקוח.
אזור פרטי - רזולוציה פנימית לנקודות קצה פרטיות (VPC/VNet, on-prem).
העברה מותנית ב-prem ↔ ענן, אזור ↔.
שמות: "Api. <brang>. <region> .internal. ”תעשיות” אפי. <brang>. com '.

7) ביטחון: מדיניות DNSSEC ודומיין

DNSSEC: אפשר חתימת אזור (KSK/ZSK), צג אחר סיבוב מפתחות ושרשרת אמון.
CAA: רשימה CAs תקף; כולל 'יודף' להתראות.
SPF/DMARC/DKIM: מוניטין של דואר והגנה מפני פישינג.
מנעול רשם ו-MFA לחשבונות ספק DNS; שינוי יומן (חנות תולעת).

8) עיצוב כשלים

8. 1 מודלים

פעיל-פעיל: שתי בריכות בריאות +; איזון דרך איזון/משקל, בדיקות בריאות שוללות לא בריא.
Active-Passive: main pool + reserve (0% משקל לפני התאונה).
טבעת אזורית: תנועה לאזור ”השכן” באסון מקומי.
מצב מושפל: כתוב לאתר ”קל ”/נחיתה אם אין מנוף אחורי.

8. 2 תרחיש צעד אחר צעד

1. ניטור רשומות השפלה של '/מוכן '.
2. DNS משנה תגובות (מחסל בריכה או משנה משקולות).
3. התנועה הולכת לאזור בריא, טי-טי-אל קובע את המהירות.
4. לאחר התייצבות - תקופת חסד (15-30 דקות) ורק אז חזרה של המאזניים.

9) דוגמאות הגדרות

9. 1 AWS כביש 53 - Latency + Health + משוקלל

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 Bloudflare - geo/ASN ו ־ Inclover pool (רעיון)

Load Balancer Pols c Health-Checks (HTTP/TCP), Load Balancer עם Geo Steering (יבשות/מדינות) ו-Session.
גיבוי: כלל עמוד/טרנספורמציה כלל לגב מפושט בפסגות 5xx.

9. 3 Azure/GCP

מנהל תנועה Azure: עדיפות/משוקלל/ביצועים/גאוגרפיים.
מדיניות Google Cloud Load Balancing + Cloud DNS: Geo-policy + health-checks country External HTTP (S) LB.

10) יכולת תצפית ו ־ DNS SLO

רזולוציית קצב הצלחה, 95 אחוז זמן רזולוציה, פרופורציה של תגובות טריות (לא מעופשות) בתוך TTL.
לדוגמא, 99. 95% מהתגובות המוצלחות מצוידות ב-100 ms.
מטריצות: NXDOMAIN-rate, SERVFAIL-RATS, בריכות בריאות-STATE, שיתוף תנועה באזור, נתח הכנרת.
מופת: לשייך SLI עם עקבות HTTP באמצעות "trace _ id' בסינתטיקה.

11) בדיקה ותפעול

סינתטיים מאזורים שונים (ASN/Atlas, Catchpoint, k6-DNS).
dnsviz/delv 'לבדוק DNSSEC; " לחפור עקבות + לחריגות.
אזור היערכות ('stg. דוגמא. com ') עבור חזרות פיילובר; חזרה תסריט משנה משקולות/סדרי עדיפויות וחוזר.
מדריך: מי ואיך באופן ידני מעלה משקולות, איך לכבות את הבריכה, איך לבצע ”הקפאה”.

12) תרופות אנטי ־ פטריות

TTL = 3000 + על קריטי A/AAAA = feilover איטי/כאוטי.
אין בדיקות בריאות או בדיקת טי-סי-פי בלבד ללא אנשי עסקים.
חבורה של שרשראות CNAME * החלטות איטיות, כאוס מטמון.
ספק ה-DNS היחיד ללא גיבוי משני/אקספר.
אזור לא חתום כאשר נדרש DNSSEC; קא "א לא רלוונטי.
כניסות המצביעות על ה IP הציבורי של גיבויים פרטיים/מסדי נתונים.

13) פרטים של iGaming/Finance

תחום שיפוט: ניתוב גאו/כפרי לציות (כיוון מחדש לתחום מקומי/חזית).
PSP/KYC: תת-דומים ייעודיים עם מדיניות TTL אישית; העברה מהירה ל-PSP המתנה.
משחק אחראי: תת-דומים עם דפים משפטיים תמיד זמינים (גיבוי סטטי/CDN).
ביקורת - אזור הרישום משתנה לחנות תולעת, חותמים על שינויים וסוקרים באופן קבוע.
רשימות בלוקים: כללי ציות DNS לפי אזור (סינון קצה + ניתוב DNS).

14) רשימת מוכנות תומכת

[ ] פרופילי TTL לפי כיתה; TL שלילי 300 S.

[ ] שתי רשתות DNS עצמאיות (ראשית/משנית), מנעול MFA/רשם.

[ ] מדיניות: Geo/latency/weight + בדיקות בריאות מאזורים מרובים.

[ ] DNSEC מאופשר, CAA/DMARC/DKIM/SPF עד היום.

[ ] אופק מפוצל (ציבורי/פרטי), אזורים פרטיים לתנועה פנימית.

[ ] Flyer/return book, חזרה תסריט, תחומים כנרית.

[ ] SLI/SLO ניטור, התראות על צמיחה NXDOMAIN/SERVFAIL/RTT.

[ אזור היערכות ] וכשלונות רגילים ”תרגילים”.

[ ] עבור iGaming: ניתוב על ידי תחום שיפוט, תחום נפרד עבור PSP/KYC, ביקורת בלתי ניתנת לשינוי.

15) TL; DR

לבנות מדיניות משולבת: Geo/latency + health-checks + rights, עם TTL 30-120 s על רמקול. הפרד ציבורי/פרטי (אופק מפוצל), אפשר DNSEC ו CAA, לשמור DNS משני. לעשות חזרה-פיילובר ולצפות SLI/SLO DNS. עבור iGaming, שקול סמכויות שיפוט והסתייגויות תחום PSP/KYC עם כללים נפרדים ורישום של שינויים בתולעת.