DNS مع Route 53 وResolver

دالة Lambda داخل الـ VPC لديك تنادي payments.corp.internal فتستقبل NXDOMAIN. والاسم نفسه يُترجم في 30 ميلي ثانية من حاسوبك عبر VPN الشركة. لم يتغيّر شيء في التطبيق، والسجلّ موجود، وDNS «يعمل» بكل فحص يخطر لك.

السجلّ سليم. الذي تغيّر هو من أجاب. فالاسم داخل الـ VPC يستطيع ترجمته ثلاثة أشياء مختلفة، وهي لا تتشاور فيما بينها. ومعرفة إلى أين يذهب الاستعلام هي معظم استكشاف أخطاء Route 53، وهي ما يختبره الامتحان فعلاً في هذا الجزء.

المناطق المستضافة: الوعاء الذي تجيب منه Route 53

المنطقة المستضافة تحمل سجلات نطاق واحد ونطاقاته الفرعية. أنشئ منطقة مستضافة لـ example.com فتحصل على وعاء تجيب Route 53 استعلاماته، وعلى خوادم الأسماء التي تجعل تلك الإجابة رسمية.

وهناك نوعان، والفرق بينهما هو من يحقّ له السؤال:

• المنطقة المستضافة العامة تجيب استعلامات الإنترنت. تخصّص Route 53 أربعة خوادم أسماء، وتوجّه مُسجِّل النطاق إليها بسجلات NS. وذلك التفويض هو ما يجعل Route 53 مرجعاً للنطاق.
• المنطقة المستضافة الخاصة تجيب استعلامات الـ VPCs التي تربطها بها وحدها. هي غير قابلة للوصول من الإنترنت، وسجلاتها لا تظهر في DNS العام أبداً.

والمناطق الخاصة تحصل على سجلات NS رغم ذلك، لأن بروتوكول DNS يفرض على كل منطقة أن تحملها، وهي دائماً الأسماء الأربعة المحجوزة نفسها:

ns-0.awsdns-00.com
ns-512.awsdns-00.net
ns-1024.awsdns-00.org
ns-1536.awsdns-00.co.uk

هذه الأسماء مرئية على الإنترنت، لكن استعلامها مباشرةً لا يعيد شيئاً عن منطقتك. والـ VPC Resolver لا يخاطبها أصلاً: هو يعرف أن الاستعلام يقع داخل مجال خاص من ارتباط الـ VPC بالمنطقة، فيصل إلى البيانات الخاصة مباشرةً. فعبارة «خوادم الأسماء عامة» صحيحة وغير ضارّة.

السجلات وTTL والاستعلام الذي لا تراه

السجلّ يربط اسماً ونوعاً بقيمة: www.example.com من النوع A إلى 203.0.113.10. ويحمل كل سجلّ TTL، وهو عدد الثواني التي يجوز لمُترجِم DNS تخزين الإجابة خلالها قبل أن يسأل من جديد.

وTTL أهم حقل تشغيلياً في السجلّ، ومن السهل الاستهانة به. اضبطه على 300 فالمُترجِم الذي أجاب عميلاً عند الساعة 10:00:00 سيواصل تقديم الإجابة نفسها حتى 10:05:00 بلا مخاطبة Route 53 إطلاقاً. ولذلك ثلاث نتائج ستقابلها مرة أخرى في هذا الموضوع:

• تغيير السجلّ أو التحوّل عند العطل لا يسري على العملاء الحاليين حتى تنتهي نسختهم المخزّنة.
• سجلات الاستعلامات تعدّ أقل من الحركة الحقيقية، أحياناً بفروق هائلة، لأن الإجابات المخزّنة لا تصل إلى Route 53 قطّ.
• خفض TTL قبل تحويل مخطّط له ثم رفعه بعده هو الأسلوب المعياري لعمليات الترحيل.

سجلات alias: الاختصار الخاص بـ AWS

تريد أن يصل example.com إلى Application Load Balancer. وموازن الحمل يحمل اسم DNS لا عنوان IP ثابتاً، فسجلّ A بعنوان مكتوب يدوياً يصير خاطئاً يوم تستبدل AWS عقدة. والجواب البديهي CNAME، وبروتوكول DNS يمنعه: لا يمكن إنشاء CNAME عند جذر النطاق، أي العقدة العليا في المجال.

وسجلّ alias هو امتداد Route 53 الذي يسدّ هذه الفجوة. يبدو للعميل سجلّ A أو AAAA، لكن هدفه مورد في AWS تترجمه Route 53 وقت الاستعلام.

وأهداف alias التي ينبغي أن تعرفها: موازنات Elastic Load Balancing بأنواعها الثلاثة، وتوزيعات CloudFront، وbuckets في S3 المضبوطة مواقع ثابتة، وواجهات API Gateway، ونقاط نهاية VPC من نوع interface، ومسرّعات Global Accelerator، وبيئات Elastic Beanstalk، وخدمات App Runner، وأسماء نطاقات AppSync، ونطاقات OpenSearch Service، وسجلّ آخر من النوع نفسه في المنطقة نفسها.

ونقطتان عمليتان. سجلات alias تتتبّع المورد وحدها، فإن تغيّرت عناوين موازن الحمل بدأت Route 53 تجيب بالجديدة بلا أي تدخّل منك. وسجلات alias تستطيع تفعيل Evaluate Target Health، وهذه هي الطريقة التي يعرف بها إعداد التحوّل عند العطل أن موازن الحمل ساقط بلا إنشاء فحص صحة له.

المناطق المستضافة الخاصة والخاصيّتان اللتان تعتمد عليهما

أنشئ منطقة مستضافة خاصة، واربط بها VPC، وأضف السجلات. فتترجم الـ instances في ذلك الـ VPC تلك الأسماء إلى عناوين خاصة.

وهي تفشل صامتةً إن لم يكن الـ VPC مضبوطاً لذلك. فالخاصيّتان التاليتان يجب أن تكونا true معاً:

• enableDnsSupport
• enableDnsHostnames

aws ec2 describe-vpc-attribute --vpc-id vpc-0a1b2c3d --attribute enableDnsSupport
aws ec2 describe-vpc-attribute --vpc-id vpc-0a1b2c3d --attribute enableDnsHostnames

aws ec2 modify-vpc-attribute --vpc-id vpc-0a1b2c3d --enable-dns-hostnames

والمنطقة الخاصة الواحدة تُربط بما يصل إلى 300 VPC، وعبر حسابات مختلفة أيضاً (والربط من حساب آخر تدفّق من خطوتين: تفويض ثم ربط). وبعد 300 تصير Route 53 Profiles هي الأداة المقصودة بدل طلب رفع الحصّة.

وفحوصات الصحة تتصرّف هنا بشكل مختلف. ففي المنطقة المستضافة الخاصة لا ترفق فحص صحة إلا بسجلات failover وmultivalue answer وweighted وlatency وgeolocation وgeoproximity. والتوجيه المبني على عناوين IP غير مدعوم في المنطقة الخاصة إطلاقاً.

DNS المنقسم وفخّ NXDOMAIN

DNS المنقسم هو النمط الذي يُترجم فيه اسم النطاق نفسه بشكل مختلف داخل شبكتك وخارجها. تنشئ منطقة عامة ومنطقة خاصة بالاسم نفسه، وتربط الخاصة بالـ VPCs لديك، وتملأ كلاً منهما بالسجلات المناسبة لجمهورها. فيصل المتّصلون الداخليون إلى 10.0.5.20، ويصل الإنترنت إلى توزيع CloudFront لديك.

وهنا الجزء الذي يفاجئ الناس. لنفترض أن منطقتك الخاصة هي example.com وتحوي سجلات لـ db.example.com وcache.example.com ولا شيء لـ reports.example.com الموجود فعلاً في DNS العام.

يقيّم الـ VPC Resolver بهذا الترتيب:

1. هل تطابق منطقة مستضافة خاصة مرتبطة بهذا الـ VPC اسمَ الاستعلام؟ والمطابقة تعني اسماً مطابقاً أو اسماً أباً للاستعلام. وexample.com أبٌ لـ reports.example.com، فالجواب نعم.
2. ابحث في تلك المنطقة عن سجلّ يطابق الاسم والنوع.
3. لا مطابقة. أعِد NXDOMAIN.

ولا يعود إلى DNS العام. فما إن تدّعي منطقة خاصة ملكية المجال حتى تملك المجال كاملاً داخل ذلك الـ VPC. وهذا ثاني أكثر حوادث المناطق الخاصة شيوعاً بعد خاصيّتي الـ VPC الناقصتين، والعَرَض واحد دائماً: اسم يعمل في كل مكان إلا داخل الـ VPC.

وحين تتداخل منطقتان خاصتان، تفوز المطابقة الأدقّ. فمع منطقتين مرتبطتين لـ example.com ولـ accounting.example.com، يُجاب استعلام seattle.accounting.example.com من accounting.example.com ومنها وحدها.

الـ VPC Resolver عند VPC+2

كل VPC يحصل على مُترجِم عند قاعدة نطاقه زائد اثنين. فالـ VPC الذي يستخدم 10.20.0.0/16 يضع مُترجِمه عند 10.20.0.2. وهذا العنوان أحد الخمسة التي تحجزها AWS في كل subnet، وهو الوجهة التي ترسل إليها الـ instances استعلامات DNS ما لم تقل مجموعة خيارات DHCP غير ذلك.

ويجيب الـ VPC Resolver ثلاث فئات:

• أسماء الـ instances الداخلية مثل ip-10-20-1-15.ec2.internal
• سجلات المناطق المستضافة الخاصة المرتبطة بالـ VPC
• الأسماء العامة، بإجراء بحث تكراري على خوادم الأسماء العامة نيابةً عنك

والفئة الثالثة مهمّة: الـ instances لا تخاطب DNS العام بنفسها، بل يقوم الـ VPC Resolver بالبحث التكراري. وهو يستطيع أيضاً التحقّق من DNSSEC على تلك الإجابات إن فعّلت التحقّق.

وإن شغّلت خوادم DNS خاصة بك على instances، وجب أن تمرّر إلى VPC+2 كي تصل إلى بيانات المناطق الخاصة. وتوجيهها إلى موجّه الـ VPC عند .1 لا يعمل.

وتوثيق AWS يسمّي هذا المكوّن الآن Route 53 VPC Resolver، بينما تسمّيه المواد الأقدم ودليل الامتحان Route 53 Resolver. وهما الشيء نفسه.

DNS الهجين: نقاط النهاية الواردة والصادرة

الـ VPC Resolver لا يعرف شيئاً عن corp.internal العامل على خوادم Active Directory في مركزك المحلي، والمُترجِم المحلي لديك لا يعرف شيئاً عن مناطقك المستضافة الخاصة. ونقاط نهاية Resolver تجسر بينهما، واسماها أكثر مصطلحين يُقلبان في هذا المجال.

والاسمان مكتوبان من زاوية الـ VPC:

• نقطة النهاية الصادرة ترسل الاستعلامات خارج الـ VPC إلى شبكتك. تقرنها بـ قواعد تمرير، واحدة لكل اسم نطاق، تقول: «استعلامات corp.internal تذهب إلى عناوين الهدف هذه».
• نقطة النهاية الواردة تستقبل الاستعلامات داخلة إلى الـ VPC من شبكتك. تعطي عناوينها للمُترجِم المحلي مُمرِّراً شرطياً.

ونقطة النهاية مجموعة من واجهات الشبكة المرنة توضع في subnets تختارها أنت، فهي تستهلك عناوين خاصة من الـ VPC لديك. ونتيجتان تتبعان ذلك:

• عناوين نقطة النهاية الصادرة خاصة، فلا يصل الاستعلام إلى مركز بياناتك إلا عبر Direct Connect أو Site-to-Site VPN أو NAT gateway. ولا يوجد مسار عام.
• كل عنوان هدف في القاعدة يجب أن يكون قابلاً للوصول من subnets نقطة النهاية. وحين يمرّر Resolver استعلاماً يختار عنوان هدف واحداً عشوائياً بلا أي تفضيل، ويعيد المحاولة على هدف عشوائي آخر إن لم يُجب الأول. فهدف واحد غير قابل للوصول ضمن ثلاثة ينتج ترجمة بطيئة متقطّعة لا عطلاً نظيفاً.

aws route53resolver create-resolver-endpoint \
  --name outbound-to-datacenter \
  --direction OUTBOUND \
  --security-group-ids sg-0a1b2c3d4e5f6a7b8 \
  --ip-addresses SubnetId=subnet-0aaa,SubnetId=subnet-0bbb

aws route53resolver create-resolver-rule \
  --name forward-corp-internal \
  --rule-type FORWARD \
  --domain-name corp.internal \
  --resolver-endpoint-id rslvr-out-0123456789abcdef0 \
  --target-ips Ip=192.168.10.53,Port=53 Ip=192.168.20.53,Port=53

والقاعدة لا تفعل شيئاً حتى تربطها بـ VPC. والقواعد موارد إقليمية يمكن مشاركتها مع حسابات أخرى عبر AWS RAM، وهذا هو النمط المعياري: حساب شبكات واحد يملك نقطة النهاية الصادرة والقواعد، وكل حساب عمل يربط القواعد المشاركة بالـ VPCs لديه.

حين تتعارض قاعدة مع منطقة مستضافة خاصة

لديك منطقة مستضافة خاصة لـ corp.internal، ويضيف أحدهم قاعدة تمرير للنطاق نفسه على الـ VPC نفسه. أيهما يجيب؟

تفوز قاعدة Resolver. فتُمرَّر الاستعلامات إلى شبكتك، ولا تُستشار السجلات الجالسة في المنطقة الخاصة أبداً.

ويستحقّ هذا أن يُقال صراحةً لأن العطل غير مرئي من وحدة تحكّم Route 53: المنطقة موجودة، والسجلات موجودة، والارتباط موجود، ولا شيء منها مستخدَم. فإن احتجت الاثنين، ضيّق القاعدة إلى اسم أضيق من المنطقة، أو افكك الارتباط.

تسجيل الاستعلامات: سجلّان مختلفان

المهارة 5.2.2 تسمّي تسجيل الاستعلامات صراحةً، وهناك ميزتان منفصلتان تحملان الكلمة نفسها في اسمهما. واختيار الخطأ منهما يُضيّع تحقيقاً كاملاً.

ومدخل سجلّ عام يبدو هكذا:

1.0 2026-08-11T08:16:02.130Z Z123412341234 example.com A NOERROR UDP DFW3 192.0.2.10 198.51.100.0/24

الإصدار، والطابع الزمني، ومعرّف المنطقة المستضافة، واسم الاستعلام، ونوعه، ورمز الاستجابة، وبروتوكول الطبقة الرابعة، وموقع الحافة، وعنوان المُترجِم، وشبكة العميل الفرعية من EDNS.

والسجلّان مشكَّلان بالتخزين المؤقت، وكلاهما يعدّ أقل من الواقع للسبب نفسه. فالسجلات العامة تفوّت كل ما قدّمه مُترجِم لاحق من ذاكرته. وسجلات Resolver تسجّل الاستعلامات الفريدة وحدها: إن سأل instance عن accounting.example.com مرتين داخل مدة التخزين المؤقت للـ VPC Resolver، لم يظهر البحث الثاني إطلاقاً. وقراءة أي منهما عدّاداً للطلبات ستضلّلك.

حصص تستحقّ الحفظ

نصائح الاختبار

• «وجّه جذر النطاق إلى موازن حمل أو توزيع CloudFront أو bucket موقع ثابت في S3» هو سجلّ alias دائماً. وCNAME عند الجذر ليس جواباً صحيحاً أبداً.
• استعلامات alias إلى موارد AWS مجانية، واستعلامات CNAME مُحاسَبة، وCNAME يشير إلى سجلّ آخر في Route 53 يُحاسَب مرّتين. وأسئلة DNS ذات النكهة المالية تنتهي عادةً عند alias.
• منطقة مستضافة خاصة لا تترجم شيئاً تعني enableDnsSupport وenableDnsHostnames. افحصهما قبل أي شيء آخر.
• «يعمل في كل مكان إلا داخل الـ VPC، والاسم نطاق فرعي لمنطقة مستضافة خاصة» هو فخّ NXDOMAIN. ولا يوجد رجوع إلى DNS العام.
• الوارد والصادر مسمّيان من زاوية الـ VPC. فالعملاء المحليون الذين يترجمون أسماء AWS يحتاجون نقطة نهاية واردة، والـ instances التي تترجم أسماء محلية تحتاج نقطة نهاية صادرة مع قاعدة تمرير.
• قاعدة Resolver تتفوّق على منطقة مستضافة خاصة لاسم النطاق نفسه.
• تسجيل الاستعلامات العامة يقتصر على us-east-1 ويغطّي المناطق العامة. ونسبة بحث إلى instance بعينه تحتاج تسجيل استعلامات Resolver.
• VPC+2 هو عنوان المُترجِم، وVPC+1 هو الموجّه. وخوادم DNS المخصّصة تمرّر إلى +2.

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