در تاریخ 3 ژوئیه 2026، سازمان ارتباطات آلبانی (AKEP)، که مدیریت دامنه کشوری .AL را بر عهده دارد، تلاش کرد یک DNSSEC key rollover انجام دهد؛ اما عملیات با مشکل مواجه شد و اعتبارسنجی DNSSEC شکست خورد ⚠️. هر resolverای که DNSSEC را اعتبارسنجی می‌کند، طبق مشخصه DNSSEC مجبور بود امضاهای نامعتبر را رد کند و به کاربر خطا برگرداند — از جمله 1.1.1.1، resolver عمومی تحت مدیریت Cloudflare.

دامنه سطح بالا .AL میزبان سرویس‌های دولتی، بانک‌ها و رسانه‌های آلبانی است و در رده‌بندی TLDها در Cloudflare Radar در جایگاه #191 قرار دارد. هر کسی که با یک resolver معتبرکننده تلاش می‌کرد به این سایت‌ها دسترسی پیدا کند، در طول حادثه آن‌ها را غیرقابل‌دسترس می‌یافت. این اختلال می‌توانست همه دامنه‌های .AL را تحت‌تأثیر قرار دهد، بی‌آنکه اهمیت میزبان یا nameserverهای authoritative تفاوتی داشته باشد 📉.

تنها دو ماه قبل، حادثه‌ای مشابه برای .DE (آلمان) رخ داده بود. پاسخ ما در آن زمان نصب یک Negative Trust Anchor (NTA) برای .DE بود تا موقتی DNSSEC را در 1.1.1.1 معلق کنیم و دامنه‌ها در دسترس بمانند تا رجیستری مشکل را حل کند. همین رویکرد را برای .AL هم اجرا کردیم.

نصب NTA معمولاً رزولوشن را بازمی‌گرداند، اما به‌صورت پنهان انجام می‌شود. یک کلاینت که پاسخ را دریافت می‌کند، از روی همان پاسخ قادر نیست بفهمد اعتبارسنجی DNSSEC دور زده شده یا نه؛ به عبارت دیگر نمی‌تواند پاسخ معتبر را از یک پاسخ جعل‌شده تمییز دهد. برای حادثه .AL، 1.1.1.1 برای اولین بار این خلا را با بازگرداندن یک EDE (Extended DNS Error) جدید همراه هر پاسخ متاثر، پر کرد تا اعلام کند پاسخ تحت NTA بوده و DNSSEC تایید نشده است 🔐.

نمودار زیر نرخ‌های SERVFAIL و NOERROR برای کوئری‌های .AL روی 1.1.1.1 را در طول 3 ژوئیه نشان می‌دهد. نرخ SERVFAIL بالا می‌رود چون رکوردهای کش‌شده منقضی می‌شوند و resolverها مجبور می‌شوند مجدداً اعتبارسنجی کنند. زمانی که NTA در ساعت 17:15 UTC اعمال شد، نرخ SERVFAIL به‌صورت ناگهانی افت کرد و رزولوشن بازیابی شد 📈.

چه اتفاقی برای .AL افتاد؟ خلاصه‌ای از DNSSEC: DNSSEC یک زنجیره اعتماد از root zone تا نام‌های دامنه فردی می‌سازد. در ریشه یک رکورد DS وجود دارد که fingerprint یا اثرانگشت DNSKEY آن TLD را نگه می‌دارد. یک resolver هنگام اعتبارسنجی .AL بررسی می‌کند که DNSKEY ارائه‌شده توسط nameserverهای .AL با DS موجود در روت مطابقت دارد یا نه؛ در صورت تطابق، پاسخ‌های .AL قابل‌اتکا شناخته می‌شوند. همین الگو در سطح پایین‌تر هم تکرار می‌شود؛ .AL برای child zones امضا شده نیز DS نگه می‌دارد که باید با DNSKEY مربوطه مطابقت کند. هر شکست در هر نقطه از این زنجیره—مثلاً DS ای که به کلیدی اشاره می‌کند که دیگر وجود ندارد—باعث می‌شود اعتبارسنجی برای همه چیز زیر آن شکست بخورد.

قبل از حادثه، روت یک رکورد DS داشت که با DNSKEY سرو‌شده توسط nameserverهای .AL تطابق داشت. حوالی ساعت 14:15 UTC، اپراتور .AL یک DNSKEY جدید منتشر کرد و کلید قدیمی را دیگر سرو نکرد. رکورد DS در روت هنوز به DNSKEY قدیمی اشاره می‌کرد (id=26319)، بنابراین هر resolverی که تلاش می‌کرد پاسخ‌های .AL را اعتبارسنجی کند، کلید مطابقت‌کننده را نمی‌یافت و اعتبارسنجی شکست می‌خورد.

نزدیک ساعت 17:00 UTC، اپراتور .AL DNSKEY جدید را حذف کرد بدون اینکه کلید قدیمی را بازگرداند. در این حالت، zone اصلاً هیچ رکورد DNSKEY نداشت، در حالی که رکورد DS در روت هنوز به id=26319 اشاره می‌کرد و رزولوشن همچنان با شکست مواجه بود.

حدود ساعت 19:15 UTC، اپراتور .AL رکورد DS را از روت حذف کرد. بدون وجود DS، resolverها دیگر از .AL انتظار DNSSEC نداشتند و رزولوشن بازگشت، با این حال تمام TLD اکنون unsigned شده بود. تا زمان انتشار این مطلب، .AL همچنان unsigned باقی مانده است و رکورد DS به روت بازنگشته است. بدون رکورد DS، هیچ یک از دامنه‌های .AL قادر به استفاده از محافظت‌های DNSSEC نیستند.

چرا از Negative Trust Anchor استفاده می‌شود؟ داشتن یک پیکربندی خراب DNSSEC می‌تواند دردسرساز باشد، به‌ویژه وقتی روی کل یک TLD تأثیر بگذارد. طبق RFC 7646، اپراتورهای recursive DNS می‌توانند یک NTA نصب کنند تا به resolver بگویند یک zone را unsigned در نظر بگیرد و اعتبارسنجی را دور بزند — این یک ابزار عملی برای بازیابی دسترسی است 🛠️.

قبل از نصب NTA، تلاش کردیم مستقیماً با اپراتور .AL تماس بگیریم و اطلاعیه‌ای در DNS-OARC Mattermost منتشر کردیم تا جامعه را آگاه کنیم. پاسخی دریافت نکردیم، بخشی از مشکل این بود که اطلاعات تماس اپراتور خود زیر دامنه .AL بود و در طول قطعی غیرقابل‌دسترسی شده بود.

ما NTA را برای .AL اعمال کردیم و آن را تا ساعت 17:15 UTC برای همه کاربران 1.1.1.1 منتشر کردیم — تقریباً سه ساعت پس از شکست زنجیره اعتبار.

معادله، مثل مورد .DE، این است که NTA اعتبارسنجی DNSSEC را معلق می‌کند؛ یعنی پاسخ‌ها دیگر در برابر DNS spoofing محافظت‌شده نیستند. ارزیابی ما این بود که در آن شرایط این ریسک قابل‌قبول است چون شکست آشکار، تأییدشده و روی همه validating resolverها به‌صورت یکسان اثر گذاشته بود.

NTA روز بعد حذف شد، وقتی که اپراتور .AL رکورد DS را از روت برداشت. با نبودن DS، resolverها دیگر انتظار DNSSEC برای .AL را نداشتند و NTA دیگر نیاز نبود.

مشکل Negative Trust Anchorها چیست؟ نصب NTA اقدام تهاجمی‌ای است: ما اعتبارسنجی DNSSEC را معلق می‌کنیم تا دامنه‌ها در دسترس بمانند، پذیرفتن اینکه پاسخ‌ها در طول این مدت دیگر از نظر رمزنگاری و اعتبار DNSSEC تایید نشده‌اند. کاربران پاسخ می‌گیرند به‌جای SERVFAIL، اما این پاسخ‌ها تضمین DNSSEC ندارند.

چالشِ بزرگ‌تر این است که تا پیش از این، هیچ چیزی در خود پاسخ DNS نبود که به کلاینت بگوید NTA فعال شده است؛ پاسخی که تحت NTA بود از نظر فرمت دقیقاً شبیه به یک پاسخ کاملاً تاییدشده به‌نظر می‌رسید. RFC 7646 این شکاف را می‌پذیرد و توصیه می‌کند اپراتورها علناً اعلام کنند کدام NTAها را دارند، اما آن افشای اطلاعات خارج از‌باند است. برای هر دوی حوادث .DE و .AL ما صفحات وضعیت منتشر کردیم، ولی صفحه وضعیت نیاز دارد کاربر خودش دنبال آن بگردد — یک اپلیکیشن، یک ابزار مانیتورینگ یا کاربری که مستقیماً 1.1.1.1 را کوئری می‌کند، تا قبل از EDE هیچ راهی نداشت از روی پاسخ بفهمد اعتبارسنجی دور زده شده یا نه 🔎.

برای آوردن شفافیت به NTAها، Extended DNS Error (EDE) codes که در RFC 8914 تعریف شده‌اند، به resolverها امکان می‌دهند تا همراه هر پاسخ DNS اطلاعات تکمیلی بفرستند، اعم از خطا یا پاسخ موفق. Babak Farrokhi از Quad9 یک Internet-Draft پیشنهاد داد تا حضور یک Negative Trust Anchor را مستقیماً در پاسخ DNS با یک EDE جدید سیگنال بدهد: Disclosure of Negative Trust Anchors in DNS Responses. ما به عنوان هم‌نویسنده به این پروژه پیوستیم و 1.1.1.1 حالا این قابلیت را پیاده‌سازی می‌کند ✅.

در جریان حادثه .AL، هر کوئری برای نامی در .AL هم پاسخ نهایی و هم کد EDE جدید را برمی‌گرداند در حالی که NTA نصب شده بود. این چیزی بود که شبیه به آن بود:

[pyaml]
$ kdig @1.1.1.1 google.al ;; ->>HEADER
[/yaml]

نکته عملی برای تیم‌های SRE/DevOps: اگر شما یک resolver عمومی یا داخلی را مدیریت می‌کنید، به لاگ‌های EDE و متادیتای resolver نگاه کنید تا به‌سرعت تشخیص دهید آیا NTA فعال شده است یا خیر. همچنین مانیتورینگ خارجی صرفاً روی کدهای پاسخ DNS (مثلاً NOERROR vs SERVFAIL) کافی نیست — پیداکردن EDEها و ثبت آن‌ها می‌تواند به تشخیص زودهنگام و تصمیم‌گیری آگاهانه در زمان رویدادهای DNSSEC کمک کند ⚙️.