GH GambleHub

توجيه DNS والفشل

1) دور DNS في تحمل الخطأ

DNS هو أول "جهاز توجيه للمستخدم. "يعتمد ما يلي على تصميمه:
  • التوافر (فشل سريع/موثوق) ؛
  • الأداء (التوجيه الجغرافي/زمن الانتقال) ؛
  • التكلفة (التقليل إلى أدنى حد من الخروج الأقاليمي ومكالمات الطرف الثالث) ؛
  • الأمن (DNSSEC، مكافحة الاختطاف، CAA/DMARC/SPF السيطرة).

المفتاح: TTLs قصيرة حيث الديناميكيات مهمة، وهندسة المنطقة المستقرة (العامة + الخاصة، الأفق المنقسم).

2) أنواع السجلات والممارسات

A/AAAA - العناوين الرئيسية ؛ تنشر دائما IPv6 حيثما أمكن ذلك.
CNAME vs ALIAS/ANAME: في جذور المجال، استخدم ALIAS/ANAME (أو التسطيح الرئيسي للمزود).
TXT-SPF/DMARC/DKIM، التحقق ؛ هيئة الطيران المدني - الحد من إصدار الشهادات.
SRV/NS - اكتشاف الخدمة وتفويضها.
SVCB/HTTPS هي آلية بديلة حديثة مع تحديد الأولويات والبارامترات (ALPN، الموانئ).

التوصية: إصلاح معايير TTL حسب الفئة (edge/API/static).

3) سياسات التوجيه

الأسهم المرجحة - الخاضعة للرقابة من حركة المرور (جزر الكناري/الأزرق الأخضر).
يعتمد على زمن الكمون - حدد المسبح الأقرب في زمن الكمون.
التوجيه الجغرافي - حسب البلد/القارة/المنطقة ؛ مهمة للإقامة في مجال البيانات.
الفشل (الابتدائي/الثانوي) - الرصد والتبديل النشطان.
متعدد القيمة - العديد من AAAA ؛ يختار العميل نفسه (لا يحل محل الفحوصات الصحية).
توجيه القرب/ASN - لبعض مقدمي الخدمة: عبر شبكة العميل.

اجمع بين: الكمون الجغرافي → → الوزن → الصحة.

4) TTL، التخزين المؤقت والانتشار

TTL API/مكبرات الصوت: 30-120 ثانية (التوازن بين سرعة التحميل والحمل).
Static/CDN: 1-24 ч.
TTL السلبي (SOA 'الحد الأدنى') - ≤ 60-300 ثانية، وإلا فإن NXDOMAIN سيكون «لزجًا».
تذكر: لا يُطلب من الحلول التخلص من المخبأ على الفور ؛ اعتبر «الذيل القذر».

5) نقاط النهاية الصحية والتفتيش

الفحوصات الصحية من مناطق متعددة: TCP/443 + HTTP 2xx/3xx وفحص معايير العمل اللامدا (على سبيل المثال ناجحة/صحة ؟ عميق = صحيح 'مع التحقق من التبعية).
Synthetic (RUM/active): عينات من واجهة برمجة التطبيقات على طول الطرق الرئيسية، وفحوصات TLS/OCSP، وفحوصات DNSSEC.
كشف '/جاهز '(عميق) و '/حي' (سطحي) ؛ اربط تجمع DNS بـ/جاهز.

6) Public vs private DNS (تقسيم الأفق)

المنطقة العامة - وصول العملاء.
المنطقة الخاصة - حل داخلي لنقاط النهاية الخاصة (VPC/VNet، on-prem).
الشحن المشروط между على البريم ↔ السحابة، المنطقة ↔ المنطقة.
التسمية: 'api. <العلامة التجارية>. <المنطقة> .internal. corp 'и' api. <العلامة التجارية> .com'.

7) الأمن: DNSSEC وسياسة المجال

DNSSEC: تمكين توقيع المنطقة (KSK/ZSK)، ورصد سلسلة التناوب والثقة الرئيسية.
CAA: قائمة CAs صالحة ؛ تشمل «اليود» للتنبيهات.
SPF/DMARC/DKIM: سمعة البريد والحماية من التصيد الاحتيالي.
قفل المسجل وحساب MFA لحسابات موفري DNS ؛ سجل التغيير (متجر WORM).

8) تصميم الفشل

8. 1 نماذج

النشاط النشط: بركتان صحيتان + ؛ التوازن من خلال زمن الوصول/الوزن، تستبعد الفحوصات الصحية عدم الصحة.
Active-Passive: تجمع رئيسي + احتياطي (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 (فكرة)

مجمعات موازين الأحمال c الفحوصات الصحية (HTTP/TCP)، موازن الأحمال مع التوجيه الجغرافي (القارات/البلدان) وتقارب الجلسة.
الاحتياطي: قاعدة الصفحة/قاعدة التحويل إلى الواجهة الخلفية المبسطة عند قمم 5xx.

9. 3 Azure/GCP

مدير المرور الأزور: الأولوية/المرجح/الأداء/الجغرافي.
Google Cloud Load Balancing + Cloud DNS policy: geo-policy + health-checks через External HTTP (S) LB.

10) قابلية الرصد و DNS SLO

SLI: حل معدل النجاح، 95 في المائة من وقت الاستبانة، نسبة الاستجابات الجديدة (غير القديمة) داخل TTL.
SLO: على سبيل المثال، 99. 95 في المائة من الردود الناجحة ≤ 100 مللي ثانية.
المقاييس: معدل NXDOMAIN، معدل SERVFAIL، حمامات السباحة الصحية، حصة حركة المرور حسب المنطقة، حصة الكناري.
النماذج: اربط SLI بآثار HTTP عبر 'trace _ id' في المواد التركيبية.

11) الاختبار والتشغيل

المواد التركيبية من مناطق/مناطق ASN مختلفة (أطلس RIPE، Catchpoint، k6-DNS).
dnsviz/' delv 'للتحقق من DNSSEC ؛' حفر + أثر 'للحالات الشاذة.
منطقة الانطلاق (stg. مثال على ذلك. com') للتدريبات الخبيثة ؛ يغير نص البروفة الأوزان/الأولويات والعوائد.
كتاب التشغيل: من وكيف يرفع/يخفض الأوزان يدويًا، وكيفية إيقاف تشغيل المسبح، وكيفية أداء «التجميد».

12) أنتيباترن

TTL = 3000 + على A/AAA الحرج → feilover البطيء/الفوضوي.
لا توجد فحوصات صحية أو فحوصات ميناء TCP فقط بدون ثوابت تجارية.
مجموعة من سلاسل CNAME → دقة بطيئة وفوضى مخبأة.
مزود DNS الوحيد بدون نسخة احتياطية ثانوية/أكسفر.
المنطقة غير الموقعة عندما تكون هناك حاجة إلى DNSSEC ؛ اتفاقات الطيران المدني غير ذات الصلة.
الإدخالات التي تشير إلى الملكية الفكرية العامة للنقاط الخلفية/قواعد البيانات الخاصة.

13) تفاصيل iGaming/Finance

الولايات القضائية: التوجيه الجغرافي/القطري من أجل الامتثال (إعادة التوجيه إلى المجال/الجبهة المحلية).
PSP/KYC: مجالات فرعية مخصصة لسياسات TTL الفردية وسياسات feilover ؛ الانتقال السريع إلى PSP الاحتياطي.
اللعب المسؤول: تتوفر دائمًا مناطق فرعية بها صفحات قانونية (النسخ الاحتياطي الثابت/CDN).
التدقيق - تغييرات منطقة تسجيل الدخول إلى متجر WORM، وتوقيع التغييرات، والمراجعة بانتظام.
قوائم الكتلة: قواعد امتثال DNS حسب المنطقة (تصفية الحافة + توجيه DNS).

14) قائمة التحقق من الاستعداد

  • موجزات TTL حسب الفئة ؛ TTL ≤ 300 s.
  • شبكتان مستقلتان لنظام DNS (ابتدائي/ثانوي)، قفل MFA/المسجل.
  • السياسات: geo/latency/weight + الفحوصات الصحية من مناطق متعددة.
  • تم تمكين DNSSEC، تحديث CAA/DMARC/DKIM/SPF.
  • تقسيم الأفق (عام/خاص)، المناطق الخاصة لحركة المرور الداخلية.
  • Flyer/return runbook، prehearsal script، canary domains.
  • رصد SLI/SLO، تنبيهات حول نمو NXDOMAIN/SERVFAIL/RTT.
  • منطقة انطلاق وفشل منتظم في «التدريبات».
  • بالنسبة إلى iGaming: التوجيه حسب الاختصاص، مجالات منفصلة لـ PSP/KYC، تدقيق غير قابل للتغيير.

15) TL ؛ د

قم ببناء سياسة مشتركة: geo/latency + health-checks + weights، مع TTL 30-120 s على مكبر الصوت. منفصل عام/خاص (تقسيم الأفق)، تمكين DNSSEC و CAA، والحفاظ على DNS الثانوية. قم بعمل بروفة ومراقبة SLI/SLO DNS. بالنسبة إلى iGaming، ضع في اعتبارك الولايات القضائية وحجوزات مجال PSP/KYC مع قواعد منفصلة وتسجيل التغييرات في WORM.

Contact

اتصل بنا

تواصل معنا لأي أسئلة أو دعم.نحن دائمًا جاهزون لمساعدتكم!

Telegram
@Gamble_GC
بدء التكامل

البريد الإلكتروني — إلزامي. تيليغرام أو واتساب — اختياري.

اسمك اختياري
البريد الإلكتروني اختياري
الموضوع اختياري
الرسالة اختياري
Telegram اختياري
@
إذا ذكرت تيليغرام — سنرد عليك هناك أيضًا بالإضافة إلى البريد الإلكتروني.
WhatsApp اختياري
الصيغة: رمز الدولة + الرقم (مثال: +971XXXXXXXXX).

بالنقر على الزر، فإنك توافق على معالجة بياناتك.