لماذا تُرجع منطقة Route 53 الخاصة استجابة NXDOMAIN للأسماء العامة

تستبدل مناطق Route 53 الخاصة الإجابة عن الاسم بدلًا من الدمج مع السجل العام، وهذا ما يفاجئ الناس في أسوأ لحظة. أضف سجلًا داخليًا واحدًا لـ api.example.net داخل منطقة خاصة لـ example.net، واربطها بـ VPC، وعندئذٍ تُجاب كل الأسماء الأخرى تحت ذلك الأصل من المنطقة الخاصة وحدها. أما العميل الذي كان يستطيع الوصول إلى www.example.net أمس فيحصل اليوم على إجابة سلبية. يبدأ الشرح أدناه من ذلك الاستعلام الفاشل ويتوسع نحو المنطقة التي أجابت عنه.

ابدأ من الاستعلام لا من وحدة التحكم

أعد إنتاج الفشل على العميل الذي أبلغ عنه، وسجّل الاسم ونوع السجل بدقة. فالاسم الذي يفشل من أجل A قد يُحلّ مع ذلك من أجل AAAA، كما أن متصفحًا يعيد محاولة اسم مخزّن مؤقتًا يخفي أي الاسمين تعطّل. نفّذ الاستعلام مرتين: مرة عبر المحلّل الذي يستخدمه العميل فعلًا، ومرة مع تتبّع يتجاوزه.

dig +short api.example.net
dig www.example.net +noall +comments +authority
resolvectl query www.example.net

الأمر الثاني هو المهم. فسطر الحالة وقسم السلطة فيه يذكران المنطقة التي أنتجت الإجابة، وهذا يتيح لك التمييز بين إجابة سلبية من المنطقة الخاصة وبين انتهاء المهلة أو منفذ محجوب أو محلّل لم يستقبل الاستعلام أصلًا. resolvectl يُظهر أي خادم أعلى سُئل، وهو غالبًا ليس المحلّل الذي افترضت أن الـ VPN دفع به.

إذا أرجع الاستعلام المتتبَّع العنوان العام بينما لا يفعل الاستعلام العادي ذلك، فالسجل العام سليم والعرض الخاص هو الذي يجيب. وهذه المقارنة الواحدة تحدد أي نصف من بقية هذه الصفحة ينطبق عليك.

اقرأ أي منطقة أجابت

في الاستجابة NXDOMAIN إذا وجدت مع SOA المنطقة الخاصة في قسم السلطة، فهي إجابة قاطعة من تلك المنطقة وليست فشلًا في البحث. اختار محلّل Route 53 المنطقة المستضافة الخاصة لأن اسمها طابق، ثم لم يجد سجلًا من النوع المطلوب، والسلوك الموثّق هو إرجاع الإجابة السلبية بدلًا من تمرير السؤال إلى DNS العام.

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

aws route53 list-hosted-zones-by-name --dns-name example.net.
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLEID --query "ResourceRecordSets[?Type=='A'].[Name,ResourceRecords[0].Value]"

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

لماذا تفوز المنطقة الخاصة

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

تداخل نطاقات الأسماء هو المصدر الثاني للارتباك. فمنطقة خاصة لـ example.net ومنطقة خاصة لـ api.example.net كلتاهما تطابق استعلام API، والأكثر تخصيصًا هي التي تجيب. وهذا مفيد عندما تريد نطاقًا داخليًا ضيقًا، وخطير عندما تفتقر المنطقة الضيقة إلى سجل موجود في المنطقة الأوسع. إن اعتبارات المنطقة المستضافة الخاصة في توثيق Route 53 تصف سلوك السقوط إلى المستوى الأوسع وأسبقية القواعد، ويستحق قراءتها قبل إضافة منطقة متداخلة ثانية.

لا شيء من هذا يغيّر المنطقة العامة. فالمحلّلات العامة ما زالت تجيب السجلات العامة بشكل صحيح، ولهذا يبدو الفشل لكل من هو خارج الـ VPC كأنه مشكلة عميل.

اختر نطاق الأسماء قبل أن تضيف سجلات

إذا كانت عائلة جديدة من الخدمات الداخلية وحدها تحتاج أسماء خاصة، فامنحها نطاقًا فرعيًا خاصًا مخصصًا واترك الأصل العام كما هو. فاسم مثل internal.example.net لا يمكن أن يحجب www.example.net، ونطاق تأثير سجل مفقود محدود بالأسماء التي ابتكرتها لهذا الغرض. أما التكلفة فهي أن عناوين URL والشهادات القائمة قد لا تطابق الاسم الجديد.

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

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

تتبّع مسار المحلّل ثم المسار

لا يرى الحاسوب المحمول العرض الخاص إلا إذا وصلت استعلاماته إلى المحلّل الذي يحمل الربط. فتحرير ملف hosts على خادم الـ VPN لا ينشر شيئًا إلى العملاء المتصلين، والعميل المهيأ بمحلّل عام سيظل يحصل على إجابات عامة ما دام النفق قائمًا. تحقق من عنوان المحلّل الذي استلمه العميل، ثم أعد الاستعلام من العميل لا من الخادم.

بعد أن يُحلّ الاسم، اختبر المسار إلى العنوان المُرجَع كخطوة منفصلة، مثلًا باستخدام ip route get مقابل العنوان الذي أرجعه الاستعلام. فالإجابة الخاصة الصحيحة دون مسار إلى العنوان مشكلة توجيه، والإجابة القائلة بغياب السجل مشكلة عرض DNS؛ والتعامل معهما كقضية واحدة ينتج إصلاحات لا تصمد. أبقِ فحوص اسم مضيف TLS والشهادة كما هي، لأن العنوان الخاص يغيّر وجهة الاتصال ولا يغيّر شيئًا في الشهادة الصالحة.

اختم بتسجيل المنطقة والربط والمحلّل والأسماء التي تحققت منها في ملاحظة التغيير. وبذلك يعرف الشخص التالي الذي يضيف سجلًا أي نطاق أسماء هو المرجع لجمهور العملاء ذلك.