نشانی‌های resolver که ظاهری خارجی دارند پیوسته در نتایج آزمون‌های DNS دیده می‌شوند و نتیجه‌ای که مردم می‌گیرند همیشه یکی است: پرس‌وجوها باید از تونل خارج شده باشند. گاهی واقعاً خارج شده‌اند. بیشتر اوقات گزارش توصیف می‌کند که کدام سرویس بازگشتی پاسخ داده و پایگاه داده کجا فکر می‌کند آن نشانی قرار دارد، و این سخنی دربارهٔ زیرساخت است نه دربارهٔ بسته‌های شما. جدا کردن مشاهده از استنتاج سه واقعیت لازم دارد: چه کسی پاسخ داد، نام چگونه سفر کرد و چه سیاستی را واقعاً پیکربندی کردید.

بخوانید آزمون واقعاً چه چیزی را مشاهده کرد

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

آزمونی که نشانی resolver را نشان می‌دهد از نشان کشور سودمندتر است، زیرا می‌توان نشانی را با فهرست resolverهایی که کارخواه واقعاً دریافت کرده مقایسه کرد.

anycast و ارسال بیشتر شگفتی‌ها را توضیح می‌دهند

resolverهای عمومی بزرگ همان نشانی را از مکان‌های بسیاری اعلام می‌کنند و شبکه هر پرس‌وجو را به نزدیک‌ترین سایت از نظر مسیریابی می‌فرستد. سپس یک پایگاه دادهٔ مکان‌یابی آن نشانی را به یک مکان نگاشت می‌کند که می‌تواند نشانی ثبت شرکتی در قاره‌ای دیگر باشد یا مرکز داده‌ای که همان پاسخ‌دهنده نیست. RFC 4786 رویهٔ عملیاتی سرویس‌های anycast و دشواری پیوند دادن چنین نشانی‌ای به یک مکان فیزیکی را پوشش می‌دهد. نقشه ساده‌سازی یک تصمیم مسیریابی است و در جهتی ساده می‌کند که نتیجه‌های نگران‌کننده می‌دهد.

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

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

چه کسی نام را دریافت کرد و از کدام مسیر

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

resolvectl query example.com
resolvectl status | grep -A3 'DNS Servers'
dig +short TXT whoami.akamai.net

فرمان نخست نشان می‌دهد کدام سرور برای یک نام پاسخ داد، دومی فهرست پیکربندی‌شده و دامنهٔ آن را نشان می‌دهد و سومی نشانی resolver را همان‌گونه که یک سرویس عمومی می‌بیند گزارش می‌کند. وقتی هر سه هم‌خوان باشند، سیاست همان کاری را می‌کند که برایش پیکربندی شده، هر چه برچسب کشور بگوید.

با سیاستی که برگزیدید مقایسه کنید

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

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

آزمون‌ها را باریک و ایمن نگه دارید

پرسیدن از یک سرویس آزمون عمومی دربارهٔ نام میزبان داخلی، آن نام را به طرفی افشا می‌کند که کاری با دیدنش ندارد، و پاسخ چیزی به شما نمی‌گوید که خواندن محلی فهرست resolverها نمی‌گفت.

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

مقالات مرتبط