‏۱.۱.۱.۱ حالا اعلام می‌کنه کِی DNSSEC رو دور زده

تو گزارش کلادفلر اومده که سوم جولای ۲۰۲۶، نهاد ارتباطات آلبانی (AKEP) — متولی دامنهٔ ملی .al — سعی کرد کلید DNSSEC خودش رو عوض کنه و کار خراب شد. نتیجه‌ش شکست اعتبارسنجی DNSSEC بود و طبق خودِ استاندارد، هر ریزالوری که اعتبارسنجی می‌کنه موظفه چنین پاسخ‌هایی رو رد کنه و خطا برگردونه. یعنی سایت‌های دولتی، بانک‌ها و رسانه‌های آلبانی یک‌جا از دسترس خارج شدن.

برای اینکه بدونید چرا یه اشتباه کوچیک این‌قدر بزرگ می‌شه: DNSSEC یه زنجیرهٔ اعتماد از روت تا تک‌تک دامنه‌هاست. روت برای هر TLD امضاشده یه رکورد DS نگه می‌داره که در واقع اثرانگشت DNSKEY همون TLDـه. ریزالور چک می‌کنه DNSKEYی که نیم‌سرورهای .al می‌دن با DS توی روت جور دربیاد. هر جای این زنجیره بشکنه، همهٔ چیزی که زیرش قرار داره از کار می‌افته.

خط زمانی ماجرا رو گزارش این‌طور می‌ده: حدود ۱۴:۱۵ به‌وقت UTC اپراتور یه DNSKEY جدید منتشر کرد و قدیمی رو برداشت، در حالی که DS توی روت هنوز به کلید قدیمی (id=26319) اشاره می‌کرد. حدود ۱۷:۰۰ کلید جدید رو هم برداشت و زون عملاً بدون هیچ DNSKEY موند. حدود ۱۹:۱۵ بالاخره خودِ رکورد DS رو از روت حذف کرد و ریزالوری‌ها دیگه انتظار DNSSEC نداشتن — رفع مشکل، ولی به قیمت اینکه کل TLD حالا امضانشده‌ست.

کلادفلر تا اون موقع صبر نکرد. مثل حادثهٔ مشابه .de که دو ماه قبلش اتفاق افتاده بود، یه Negative Trust Anchor (تعریف‌شده در RFC 7646) روی .al گذاشت؛ یعنی به ریزالور گفت این زون رو امضانشده فرض کن و از اعتبارسنجی رد شو. ساعت ۱۷:۱۵ این تغییر روی همهٔ کاربرهای ۱.۱.۱.۱ اعمال شد، حدود سه ساعت بعد از شکستن زنجیره. جالب اینکه قبلش تلاش کرده بودن با اپراتور تماس بگیرن، ولی آدرس‌های تماس اون‌ها هم زیر همون .al بود و در دسترس نبود.

مشکل NTA اینه که خیلی خشنه و در سکوت انجام می‌شه: تا وقتی فعاله، پاسخ‌ها دیگه تضمین رمزنگاری‌شده ندارن و کلاینت هم از خود پاسخ نمی‌تونه بفهمه اعتبارسنجی دور زده شده. RFC 7646 فقط توصیه می‌کنه اپراتور بیرون از DNS اعلام عمومی کنه، ولی صفحهٔ وضعیت رو باید کاربر بره پیدا کنه؛ یه اپلیکیشن یا ابزار مانیتورینگ از خود پاسخ چیزی دستگیرش نمی‌شه.

راه‌حل، کد خطای گسترش‌یافتهٔ جدیدیه که بابک فرخی از Quad9 پیشنهادش داده و کلادفلر هم به‌عنوان هم‌نویسنده بهش پیوسته: EDE 33 (Negative Trust Anchor). حالا ۱.۱.۱.۱ کنار هر پاسخی که زیر یه NTA فعال سرو می‌شه این کد رو هم می‌فرسته. توی حادثهٔ .al خروجی این‌شکلی بود:

$ kdig @1.1.1.1 google.al
;; EDE: 9 (DNSKEY Missing): 'no SEP matching the DS found for al.'
;; EDE: 33 (Negative Trust Anchor): 'a Negative Trust Anchor has been applied for this query (see RFC 7646)'
google.al.              300    IN    A    142.251.142.196

پاسخ NOERRORه و آدرس هم درست برگشته، ولی دو تا کد کنارش داستان کامل رو می‌گه: EDE 9 می‌گه زنجیرهٔ اعتماد شکسته و اعتبارسنجی شکست خورده، و EDE 33 می‌گه ۱.۱.۱.۱ با NTA جواب رو به‌هرحال سرو کرده. این کد روی هر پاسخی زیر NTA فعال برمی‌گرده، حتی برای دامنه‌ای که اصلاً از DNSSEC استفاده نمی‌کنه — چون NTA کل زون رو پوشش می‌ده و شفافیت باید یکسان باشه.

EDE 33 توسط IANA تخصیص داده شده، ابزار kdig از پروژهٔ Knot دیگه اسمش رو می‌شناسه و یه pull request هم برای Unbound در حال بررسیه. پیش‌نویس اینترنتی‌اش هم به کارگروه DNSOP در IETF رفته. نتیجهٔ اخلاقی گزارش اینه که خرابی DNSSEC در سطح TLD نادره ولی وقتی می‌افته همهٔ دامنه‌های زیرش رو هم‌زمان می‌بره، و NTA ابزار لازمیه که تا امروز برای کاربرهاش نامرئی بود.

نکات کلیدی:

• تعویض ناموفق کلید DNSSEC در دامنهٔ ملی .al باعث شد همهٔ سایت‌های آلبانی برای ریزالورهای اعتبارسنج از دسترس خارج بشن
• علت: DS توی روت به کلید قدیمی اشاره می‌کرد ولی اون کلید دیگه سرو نمی‌شد
• کلادفلر با Negative Trust Anchor اعتبارسنجی رو موقتاً کنار گذاشت تا دسترسی برگرده
• هزینهٔ NTA اینه که پاسخ‌ها دیگه در برابر جعل DNS محافظت‌شده نیستن
• کد جدید EDE 33 این وضعیت رو مستقیم توی خود پاسخ DNS اعلام می‌کنه
• .al تا زمان انتشار گزارش هنوز رکورد DS رو به روت برنگردونده و امضانشده مونده