‏مشکلِ «دامنه‌ی روح» تو DNS؛ سایتِ مُرده که سالم به‌نظر می‌رسه

نویسنده (Mattias Geniar) یه edge caseِ DNS رو معرفی می‌کنه که حتی آدم‌های واردِ DNS هم کمتر بهش خوردن: دامنه‌ای که registry از zone بیرونش کشیده، می‌تونه روزها بعد از رفتنش برای uptime checkerها سالم به‌نظر برسه. zoneِ .de این حالت رو وقتی تأییدِ اطلاعاتِ مالک شکست بخوره تریگر می‌کنه و registryهای دیگه هم نسخه‌ی خودشون رو دارن. اسمش «ghost domain»ه، تو محافلِ پژوهشیِ DNS مستند شده و یه پیش‌نویسِ فعالِ IETF (delegation revalidation) داره.

نویسنده توضیح می‌ده که مثلاً DENIC یه دامنه‌ی .de با اطلاعاتِ تأییدنشده رو اول از zone برمی‌داره و بعداً حذف می‌کنه؛ EURid و AFNIC و همین‌طور gTLDهایی مثل .com و .net هم نسخه‌های خودشون رو دارن. اسم‌ها فرق دارن ولی شکل یکیه: registry یا registrar نام رو از zoneِ والد بیرون می‌کشه، ولی nameserverهای authoritativeِ خودِ دامنه انگار هیچی نشده جواب می‌دن. برای کسی که resolverش دیگه رکوردهای سمتِ فرزند رو نداره، نتیجه NXDOMAINه؛ ولی برای uptime checkerی که پشتِ یه کشِ گرمِ recursive نشسته، ممکنه هیچ اتفاقی نیفته و سایت سالم به‌نظر برسه. فرق، مرورگر در برابر checker نیست؛ کشِ سرد در برابر کشِ گرمه.

نویسنده می‌گه باگ نه روی جعبه‌ی اونا زندگی می‌کنه نه مالِ خودِ checkerه؛ ذاتیِ نحوه‌ی کارِ recursive DNSه: همون لایه‌ی کشی که DNS رو سریع می‌کنه، همونیه که می‌تونه یه delegationِ مُرده رو گرم نگه داره. مکانیزمش قدم‌به‌قدم اینه: اولین lookup، resolver از سرورهای والد یه referral با لیستِ nameserverها می‌گیره؛ بعد از خودِ اون nameserverها می‌پرسه و اون‌ها معمولاً همون لیست رو از apexِ zoneِ خودشون برمی‌گردونن (apex NS RRset). طبقِ قوانینِ رتبه‌بندیِ RFC 2181، نسخه‌ی authoritativeِ فرزند بر نسخه‌ی referralِ والد اولویت داره و جاش رو تو کش می‌گیره. بعد که رکوردِ A منقضی می‌شه، resolver همون apex NS RRsetِ کش‌شده رو پیدا می‌کنه، از همون nameserverها می‌پرسه، اون‌ها هنوز مثبت جواب می‌دن (چون خبر ندارن delegation کشیده شده)، یه رکوردِ A تازه کش می‌شه و حلقه تکرار می‌شه. تا وقتی این RRset گرم بمونه، والد دیگه پرسیده نمی‌شه.

نویسنده می‌گه سراغِ مستنداتِ عمومیِ Pingdom، UptimeRobot، StatusCake، Site24x7، Datadog Synthetics و Better Stack رفته و دفاعِ مستندی علیهِ این مشکل تو هیچ‌کدوم پیدا نکرده؛ Pingdom حتی معماری‌ای رو مستند کرده که خودش مسببِ باگه (هر probe یه BIND کشِ خودش رو داره که defaultِ max-cache-ttlش یک هفته‌ست). تأکید می‌کنه این گیر انداختنِ کسی نیست؛ این مشکل به همون دلیلی از رادارِ همه دور مونده که از رادارِ خودشون: یه مشکلِ لایه‌ی DNS که زیرِ یه محصولِ لایه‌ی HTTP قایم شده.

کاری که Oh Dear داره می‌کنه عمداً محدوده: روی هر checker یه resolverِ recursiveِ محلی (Unbound) که خودش recursion کامل می‌کنه به‌جای forward به یه resolverِ اشتراکی. دو نوبِ مهم رو تنظیم می‌کنن: cache-max-ttl رو از یک روز به یک ساعت کم می‌کنن تا پنجره‌ای که یه apex NS RRsetِ کهنه می‌تونه دامنه رو ghost کنه کوتاه بشه، و harden-referral-path رو روشن می‌کنن تا resolver داده‌ی NS رو تو مسیرِ referral بازبینی کنه نه فقط از کش. نویسنده صادقانه می‌گه این ghost domainها رو غیرممکن نمی‌کنه، فقط پنجره‌ی خطا رو از روزها به حدودِ یک ساعت کم می‌کنه، و چون harden-referral-path آزمایشیه، DNSSEC رو کنارش تو حالتِ log-only اجرا می‌کنن. توصیه‌ی نهاییش به کاربرها اینه که DNS monitoring رو کنارِ uptime monitoring روشن کنن، چون هر کدوم مشکلی رو می‌گیره که اون‌یکی نمی‌گیره.

نکات کلیدی:

• مشکلِ ghost domain: دامنه‌ای که registry از zone بیرون کشیده، می‌تونه روزها برای uptime checkerهای پشتِ کشِ گرم سالم به‌نظر برسه ولی برای کاربر NXDOMAIN بده.
• ریشه، ذاتِ کشِ recursive DNSه: نسخه‌ی apex NS RRsetِ فرزند بر نسخه‌ی والد اولویت می‌گیره و تا گرم بمونه، والد دوباره پرسیده نمی‌شه.
• نویسنده تو مستنداتِ Pingdom، UptimeRobot و چند سرویسِ دیگه دفاعِ مستندی علیهِ این مشکل پیدا نکرد.
• Oh Dear روی هر worker یه Unboundِ محلی با cache-max-ttlِ یک‌ساعته و harden-referral-pathِ روشن گذاشته تا پنجره‌ی خطا از روزها به حدودِ یک ساعت برسه.
• توصیه: DNS monitoring رو کنارِ uptime monitoring روشن کنید تا مشکلاتِ لایه‌ی DNS دیده بشن.