چرا یک زون خصوصی Route 53 برای نام‌های عمومی NXDOMAIN برمی‌گرداند

زون‌های خصوصی Route 53 پاسخ یک نام را جایگزین می‌کنند و با رکورد عمومی ادغام نمی‌شوند، و همین موضوع در بدترین لحظه باعث غافلگیری می‌شود. یک رکورد داخلی اضافه کنید برای api.example.net در یک زون خصوصی برای example.net، آن را به یک VPC متصل کنید، و از این پس هر نام دیگری زیر آن والد فقط از زون خصوصی پاسخ می‌گیرد. مشتری‌ای که دیروز می‌توانست به www.example.net برسد امروز پاسخ منفی می‌گیرد. بررسی زیر از همان پرس‌وجوی ناموفق آغاز می‌شود و به سمت زونی می‌رود که به آن پاسخ داده است.

از پرس‌وجو شروع کنید، نه از کنسول

خطا را روی همان مشتری‌ای بازتولید کنید که آن را گزارش کرده و نام دقیق و نوع رکورد را ثبت کنید. نامی که برای A شکست می‌خورد ممکن است برای AAAA هنوز حل شود، و مرورگری که نامی را از حافظه پنهان دوباره امتحان می‌کند پنهان می‌کند کدام یک خراب شده است. پرس‌وجو را دو بار اجرا کنید: یک بار از طریق resolver‌ای که مشتری واقعاً استفاده می‌کند و یک بار با ردیابی‌ای که آن را دور می‌زند.

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

دستور دوم مهم است. خط وضعیت و بخش authority آن زونی را نام می‌برند که پاسخ را تولید کرده، پس می‌توانید پاسخ منفی از زون خصوصی را از timeout، پورت مسدود یا resolver‌ای که هرگز پرس‌وجو را دریافت نکرده جدا کنید. resolvectl نشان می‌دهد از کدام سرور بالادست پرسیده شده، و اغلب آن resolver‌ی نیست که گمان می‌کردید VPN فرستاده است.

اگر پرس‌وجوی ردیابی‌شده آدرس عمومی را برگرداند و پرس‌وجوی عادی نه، رکورد عمومی سلامت است و نمای خصوصی پاسخ می‌دهد. همین یک مقایسه تعیین می‌کند کدام نیمه از بقیه این صفحه درباره شما صدق می‌کند.

بخوانید کدام زون پاسخ داده است

پاسخی که NXDOMAIN را حمل می‌کند و SOA زون خصوصی را در بخش authority دارد، پاسخ قطعی همان زون است، نه جست‌وجوی ناموفق. Route 53 Resolver زون میزبانی‌شده خصوصی را انتخاب کرد چون نام مطابقت داشت، سپس رکوردی از نوع درخواستی نیافت، و رفتار مستندشده این است که پاسخ منفی را برگرداند نه اینکه پرسش را به DNS عمومی بفرستد.

انتخاب از ویژگی پیروی می‌کند. با چند فضای نام خصوصی هم‌پوشان، مشخص‌ترین زون مطابق برنده می‌شود و والد خصوصی گسترده‌تر برای نامی که زون فرزند انتخاب‌شده ندارد شانس دوم نمی‌گیرد. قواعد ارسال لایه دیگری اضافه می‌کنند، چون یک قاعده Resolver مخصوص دامنه می‌تواند بر انجمن زون میزبانی‌شده خصوصی غلبه کند. پیش از آنکه نتیجه بگیرید زونی خالی است، انجمن‌ها و قواعد را فهرست کنید.

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 قابل مشاهده می‌کند، و resolver داخل آن VPC آن را اعمال می‌کند. زون خصوصی‌ای که به VPC‌ای که ترافیک مشتری از آن می‌آید متصل نیست هیچ اثری ندارد، در حالی که انجمن با VPC اشتباه پاسخی خصوصی برای جمعیت اشتباه تولید می‌کند. پیش از ویرایش رکوردها فهرست انجمن‌ها را بررسی کنید، چون یک زون می‌تواند درست باشد و باز هم دیده نشود.

فضاهای نام هم‌پوشان دومین منبع سردرگمی‌اند. زون خصوصی برای example.net و زون خصوصی برای api.example.net هر دو با یک پرس‌وجوی API مطابقت دارند و مشخص‌تر پاسخ می‌دهد. این وقتی مفید است که فضای نام داخلی باریکی می‌خواهید و وقتی خطرناک است که زون باریک رکوردی را ندارد که زون گسترده‌تر دارد. ملاحظات زون میزبانی‌شده خصوصی در مستندات Route 53 هم رفتار عبور به لایه پایین‌تر و هم اولویت قواعد را توصیف می‌کند و ارزش خواندن دارد پیش از آنکه زون هم‌پوشان دومی اضافه کنید.

هیچ‌یک از این‌ها زون عمومی را تغییر نمی‌دهد. resolver‌های عمومی همچنان به‌درستی به رکوردهای عمومی پاسخ می‌دهند و به همین دلیل برای همه بیرون از VPC این خطا شبیه مشکل مشتری به نظر می‌رسد.

پیش از افزودن رکوردها فضای نام را انتخاب کنید

اگر تنها خانواده‌ای تازه از سرویس‌های داخلی به نام‌های خصوصی نیاز دارد، به آن یک زیردامنه خصوصی اختصاصی بدهید و والد عمومی را رها کنید. نامی مانند internal.example.net نمی‌تواند www.example.net را سایه بیندازد، و شعاع اثر یک رکورد گمشده به نام‌هایی محدود می‌ماند که برای همین کار ساخته بودید. هزینه‌اش این است که URL‌ها و گواهی‌های موجود ممکن است با نام جدید جور درنیایند.

وقتی کاربران عمومی و خصوصی باید نام میزبان یکسانی را حفظ کنند، DNS با نمای تفکیک‌شده طراحی پشتیبانی‌شده است و لازم می‌داند رکوردها را در هر نما به‌صراحت نگه دارید. زون خصوصی گسترده‌ای که یک رکورد دارد وابستگی‌های عمومی زیر آن زون را حفظ نمی‌کند؛ آن‌ها را با زونی جایگزین می‌کند که یک رکورد دارد.

پیش از آنکه جمعیتی از مشتریان را به نمای خصوصی بفرستید، نام‌هایی را که یک برنامه واقعاً فراخوانی می‌کند فهرست کنید. میزبان‌های ورود، میزبان‌های دارایی‌های ثابت، مقصدهای تغییرمسیر و نقاط پایانی API نخستین چیزهایی هستند که می‌شکنند و معمولاً میان رکوردهای چند تیم پخش شده‌اند.

مسیر resolver و سپس مسیر شبکه را ردیابی کنید

یک لپ‌تاپ نمای خصوصی را فقط وقتی می‌بیند که پرس‌وجوهایش به resolver‌ای برسند که آن انجمن را دارد. ویرایش فایل hosts روی سرور VPN چیزی را برای مشتریان متصل منتشر نمی‌کند، و مشتری‌ای که با resolver عمومی تنظیم شده تا وقتی تونل بالاست پاسخ‌های عمومی می‌گیرد. آدرس resolver‌ی را که مشتری دریافت کرده تأیید کنید و بعد پرس‌وجو را از مشتری تکرار کنید نه از سرور.

وقتی نام حل شد، مسیر تا آدرس برگشتی را به‌عنوان گامی جداگانه بیازمایید، برای نمونه با ip route get در برابر آدرسی که پرس‌وجو برگردانده است. پاسخ خصوصی درست بدون مسیر تا آدرس یک مشکل مسیریابی است و پاسخ نبودِ رکورد یک مشکل نمای DNS؛ برخورد با آن‌ها به‌عنوان یک مسئله اصلاحاتی می‌سازد که دوام نمی‌آورد. بررسی‌های نام میزبان TLS و گواهی سرویس را بدون تغییر بگذارید، چون آدرس خصوصی تغییر می‌دهد اتصال کجا می‌رود و هیچ چیز درباره اینکه کدام گواهی معتبر است.

پایان کار را با ثبت زون، انجمن، resolver و نام‌هایی که بررسی کردید در یادداشت تغییر تمام کنید. آن‌گاه نفر بعدی که رکوردی اضافه می‌کند می‌داند کدام فضای نام برای آن جمعیت مشتری مرجع است.