شراء حساب AWS: تحليل Amazon Cloud DNS للدليل المتعمق لاستكشاف الشذوذ وحل المشكلات!

في بنية الحوسبة السحابية ، يشبه DNS (نظام اسم المجال) ملاح العالم الرقمي. بمجرد أن يكون تحليل DNS على AWS غير طبيعي ، قد تقع خدمات المؤسسة على الفور في حالة "فقدان الاتصال": لا يمكن لمثيل EC2 الوصول إلى واجهات برمجة التطبيقات الخارجية ، واستدعاء الخدمة المصغرة الداخلية مهلة ، وواجه المستخدم

NXDOMAIN

أو

SERVFAIL

خطأ.

نظرًا لأن بنية شبكة AWS تدمج VPC (سحابة خاصة افتراضية) و Route 53 و VPC Resolver(.2 محلل) وهياكل سحابة هجينة محلية محتملة ، فإن حل DNS غالبًا ما يكون له تعقيد معين. هذه المادة سوف تبدأ من

تحليل الشبكة العامة

،

تحليل داخلي VPC

،

الهندسة المعمارية السحابية الهجينة

و

اختناقات الأداء

أربعة أبعاد بالنسبة لك لتفكيك عملية حل وحل الشذوذ في تحليل AWS DNS.

1. صندوق أدوات التحقيق الأساسي: "سماعة الطبيب" في المرة الأولى

قبل التعمق في الهيكل ، عند مواجهة خلل في التحليل ، يجب عليك أولاً استخدام الأدوات الأصلية التالية على مثيلات EC2 المتأثرة أو المحطات المحلية للحصول على حالة الخطأ الأساسية:

يستخدم dig (Linux/macOS) أو nslookup (Windows) di g yourdomain.com لمراقبة Status التي يتم إرجاعها. تشمل الحالات الشائعة: NOERROR: تم تحليلها بنجاح ، وقد تكون المشكلة هي ذاكرة التخزين المؤقت لطبقة التطبيق أو عدم توصيل المنفذ. NXDOMAIN: اسم المجال غير موجود ، وعادة ما يكون خطأ في مطابقة السجل أو لم تتم مزامنته بعد. SERVFAIL: فشل معالجة خادم DNS ، وهو أكثر شيوعًا في أخطاء تكوين مفتاح DNSSEC أو فشل إعادة التوجيه الأولية.

حدد اختبار خادم DNS لفرض استخدام خادم الاسم الموثوق به AWS Route 53 للاستعلام ، لتحديد ما إذا كانت مشكلة حل العودية العالمية أم مشكلة على جانب AWS: Bashdig @ ns-xxxx.awsdns-xx.com yourdomain.com

2. بيئة الشبكة العامة: تحليل منطقة الوصاية العامة Route 53 غير طبيعي

إذا كنت مسؤولاً عن إدارة الحسابات المتعددة في التشغيل السحابي للمؤسسة ، فقد تحتاج إلى تعديل أصول اسم المجال بشكل متكرر. تأكد من أن حسابك يتمتع بسلطات إدارية كافية قبل إجراء تحقيق رسمي. إذا كان النشر على نطاق واسع على مستوى المؤسسة ، فمن خلال قنوات متوافقة ومستقرة

شراء حساب AWS

الصيانة للحصول على خطة دعم المؤسسة (Enterprise Support) ، وهو أمر بالغ الأهمية عند مواجهة فشل أساسي في فئة غير التكوين.

يحدث فشل تحليل الشبكة العامة عادة بسبب الأسباب الثلاثة التالية:

1. Name Servers (NS) في السجل لا يتوافق مع Route 53

هذا هو الخطأ البشري الأكثر شيوعا. عند إنشاء منطقة استضافة عامة جديدة في Route 53 ، A

يقوم WS بتعيين 4 خوادم اسم بشكل عشوائي.

طريقة التحقيق: تحقق من سلسلة ترخيص اسم المجال الجذر من خلال e yourdomain.com dig trac ، أو استخدم أداة Whois لعرض سجلات NS التي يملأها المسجل.

الحل: قم بتسجيل الدخول إلى خلفية مسجل اسم المجال الخاص بك ، وقم بتعديل سجلات NS بالكامل ودقة إلى خوادم أسماء AWS الأربعة المعروضة في منطقة استضافة Route 53 الحالية.

2. DNSSEC تكوين توقيع السلسلة المكسورة

من أجل السلامة ، قامت العديد من الشركات بتشغيل DNSSEC. إذا لم يتم تحديث سجلات DS(Delegation Signer) في المسجل عند نقل اسم المجال أو تغيير منطقة الاستضافة ، فسيعود المحلل العودية في جميع أنحاء العالم مباشرة لأنه لا يمكنه التحقق من التوقيع.

فشل الخدمة

.

الحل: إذا لم تكن هناك حاجة ، فقم أولاً بإيقاف تشغيل DNSSEC على جانب المسجل و Route 53 ؛ إذا لزم الأمر ، تأكد من تصدير معلومات KSK (مفتاح التوقيع الرئيسي) لـ Route 53 ، ثم انتقل إلى خلف المسجل لإعادة إنشاء سجل DS المطابق.

3. الربط بين الموقع الجغرافي/التوجيه المتأخر والفحص الصحي يؤدي إلى "القتل غير العمد"

يدعم Route 53 استراتيجيات التوجيه المتقدمة. إذا تم تكوين "تقييم صحة الهدف" ، فلن يعود Route 53 إلى IP بمجرد فشل الفحص الصحي للطرف الخلفي المرتبط (مثل ALB أو EC2).

الحل: انتقل إلى وحدة التحكم Route 53 للتحقق من حالة الفحص الصحي المرتبط. إذا كانت الخدمة الخلفية طبيعية ولكن الفحص يحدد الوفاة ، يرجى ضبط العتبة الصحية أو وقت العمل الإضافي للفحص الصحي.

3. البيئة الداخلية لـ VPC: AmazonProvidedDNS غير طبيعي

داخل VPC ، يستخدم EC2 قاعدة الشبكة الحالية بشكل افتراضي

2

عنوان IP (على سبيل المثال

10-0.0.2

) كخادم DNS ، وهذا هو

AmazonProvidedDNS

(أو Route 53 Resolver).

1. لم يتم فتح خصائص VPC

إذا وجدت أن مثيل EC2 غير قادر تمامًا على تحليل اسم نطاق الخدمة الداخلية AWS (مثل

*. Amazonaws.com

) أو اسم مجال استضافة خاص (منطقة استضافة خاصة) ، قم بالتحقق من تكوين VPC أولاً.

استكشاف الأخطاء وإصلاحها: افتح وحدة تحكم Amazon VPC. اختر VPC الخاص بك ، انقر فوق الإجراءات-> تحرير إعدادات VPC (Edit VPC settings). تأكد من تمكين حل DNS وتمكين اسم المضيف DNS (Enabl)

E DNS hostnames) تم وضع علامة على هذين الخيارين.

2. تم العبث بمجموعة خيارات DHCP (DHCP Options Sets)

إذا كانت المؤسسة تستخدم خادم Active Directory (AD) أو BIND تم إنشاؤه ذاتيًا داخليًا ، فقد يتم تعديل مجموعة خيارات DHCP الخاصة بـ VPC. إذا لم يتمكن Custom DNS من تحليل اسم المجال العام أو AWS الداخلي ، فسيتم مقاطعة التحليل.

الحل: تحقق من domain-name-servers في مجموعة خيارات DHCP المرتبطة بـ VPC. إذا قمت بتكوين DNS مخصص ، فيجب عليك التأكد من أن خادم DNS المخصص مزود بمستجيب مشروط ، وسيتم إعادة توجيه الطلبات لأسماء النطاقات الداخلية والخارجية AWS إلى خادم VPC. 2.

4. السحابة المختلطة وبيئة الحساب المتقاطع: فشل عقدة محطة Resolver

في السيناريوهات السحابية المختلطة التي تتصل بها مراكز البيانات المحلية مع AWS VPC عبر AWS Direct Connect (DX) أو VPN ، يتم نشرها عادةً

Route 53 Resolver عقدة المحطة الطرفية (Endpoints)

.

[DNS مركز البيانات المحلي] ──(VPN/DX)──> [ Inbound Endpoint (.2 Resolver) ] ──> [منطقة استضافة VPC الخاصة]

عند انقطاع تحليل السحابة المختلطة ، اتبع بدقة الخطوات التالية للتحقق من الشبكة مقابل الأذونات:

1. التحقق من اتصال الشبكة: تأكد من أن الطبقة المادية/طبقة الشبكة سلسة.

على خادم DNS المحلي ، استخدم

Telnet <Inbound-Endpoint-IP> 53

أو

Nc-puv 53 <Inbound-Endpoint-IP>

اختبار منافذ 53 من TCP و UDP ، على التوالي. إذا كان هناك مهلة ، فهذا يعني أن التدفق الأساسي لم يصل.

2. تحقق من مجموعة الأمان والشبكة ACL: حركة المرور المفرج عنها.

ستشغل العقدة الطرفية الواردة ENI (بطاقة الشبكة المرنة) في الشبكة الفرعية. تحقق من مجموعة الأمان المرتبطة بـ ENI (مجموعة الأمان) والشبكة الفرعية ACL(NACL) للتأكد من أنها تسمح بالخروج من قسم شبكة خادم DNS المحلي

UDP/TCP Port 53

حركة المرور الواردة ، وفي نفس الوقت إطلاق حركة مرور المنفذ المؤقت (1024-65535) لرحلة العودة.

3. التحقق من جدول التوجيه وبوابة NAT: تحقق من المسار الخارج.

إذا كانت العقدة الطرفية الصادرة (Outbound Endpoint) لا يمكنها حل اسم المجال المحلي ، تحتاج إلى تأكيد: Outbou

ما إذا كان جدول توجيه الشبكة الفرعية حيث يوجد nd Endpoint يحتوي على توجيه إلى قسم الشبكة المحلية (عبر البوابة الخاصة الافتراضية VGW أو بوابة Transit). إذا كان الهدف الخارجي هو DNS العام (مثل 8.8.8.8) ، فيجب أن تكون الشبكة الفرعية شبكة فرعية خاصة وأن جدول التوجيه مزود ببوابة NAT.

4. ارتباط منطقة الاستضافة الخاصة عبر الحساب: تحقق من IAM وأذونات المشاركة.

في بنية الحساب المتعدد ، إذا كان اسم المجال في منطقة الاستضافة الخاصة للحساب A ، و EC2 في VPC للحساب B ، فيجب تنفيذه من خلال AWS CLI أو SDK

Associate-vpc-with-hosted-zone

قم بإجراء ارتباط عبر الحساب ، وإلا فلن يتمكن VPC الخاص بالحساب B من إدراك وجود اسم المجال حتى لو كانت الشبكة سلسة.

خمسة ، القاتل غير المرئي: VPC DNS لكل حد في الثانية (Throttling)

في بعض الأحيان ، يظهر تحليل DNS غير طبيعي

فقدان الحزمة المتقطع ، العمل الإضافي أو التأخير العالي

، واضحة بشكل خاص في ذروة الأعمال. من المحتمل أن يكون هذا هو الحد الأقصى لحزم البيانات في الثانية (PPS) لـ AWS.

⚠قيود الحصص الرئيسية: تنص AWS على أن استعلام DNS الذي بدأته كل واجهة شبكة (مستوى ENI لكل مثيل EC2 على مستوى بنية الشبكة) إلى Amazon ProvidedDNS (خادم. 2) بحد أقصى 1024 PPS. سيتم تجاهل طلبات DNS التي تتجاوز هذا الحد بلا رحمة من قبل النظام ، وهذا أمر صعب ، ولا يمكن زيادة الحصة من خلال إرسال أوامر العمل.

كيفية تأكيد حد معدل DNS ؟

نظرًا لأن حركة المرور المرفوضة يتم التخلص منها في طبقة واجهة الشبكة ، فهي

لن يكون ممكنًا

تم تسجيله في سجل الاستعلام الخاص بـ Route 53.

طريقة التشخيص: استخدم tcpdump للاستيلاء على حركة المرور من منفذ 53 على مثيلات Linux EC2 المتأثرة ، أو استخدم وظيفة مرآة حركة المرور لممثيلات بنية AWS Nitro لاستيراد حركة المرور في Wireshark للتحليل. إذا تم العثور على طلبات DNS كثيفة ومساحات كبيرة من الموانئ غير المسبوق ، فيمكن تشخيصها على أنها Throttling.

الحل:

قم بتشغيل ذاكرة التخزين المؤقت المحلية لـ DNS: قم بنشر nscd أو dnsmasq أو النظام المحلي-resolved على مثيلات Linux. دع الغالبية العظمى من طلبات DNS المكررة يتم هضمها محليًا في نظام التشغيل ولم يعد يتم تقديمها إلى AWS.

تحسين تجمع توصيل طبقة التطبيق: تحتوي بعض لغات التطوير (مثل Java) على إعدادات أقصر لذاكرة التخزين المؤقت DNS الافتراضية TTL (وقت البقاء) ، أو تؤدي اتصالات عالية التزامن وقصيرة بشكل متكرر إلى تحليل DNS. يوصى بتحسين بنية الاتصال الطويلة ، أو إطالة وقت انتهاء صلاحية ذاكرة التخزين المؤقت لـ DNS للتطبيق بشكل مناسب.

الملخص والتوصيات

شراء حساب AWS

في مواجهة تحليل AWS DNS غير الطبيعي ، لا تقم بتعديل التكوين بشكل أعمى. يوصى باتباع مبدأ "من الداخل إلى الخارج ، من الضحلة إلى العميقة": انظر أولاً إلى ذاكرة التخزين المؤقت المحلية وتعليقات الأداة ، ثم انظر إلى السمات الأساسية لـ VPC DNS ، ثم تحقق من مجموعة الأمان ومسار السحابة المختلطة ، وأخيراً فكر في حد حصة 1024 PPS تحت مشهد حركة المرور الكبيرة. في الوقت نفسه ، يمكن أن يساعدك إنشاء بنية تحتية جيدة ، أي عادات إدارة الكود (IaC ، مثل Terraform) ، وتوحيد تدفق إدارة الحسابات المتعددة للمؤسسات ، في منع معظم كوارث DNS الناتجة عن سوء التشغيل من المصدر.