افزونه‌های امنیتی سامانه نام دامنه (DNSSEC) با پیوست امضاهای دیجیتال (RRSIG) به رکوردهای منبع، اصالت مبدأ و یکپارچگی رمزنگاری را برای پروتکل DNS به ارمغان آوردند تا ریزالورهای اعتبارسنج بتوانند هرگونه دستکاری داده‌ها و مسموم‌سازی حافظه کش را در مسیر انتقال شناسایی کنند.

با این وجود، اعتبارسنجی پاسخ‌های منفی—اثبات این‌که یک دامنه درخواستی وجود ندارد (NXDOMAIN) یا نوع رکورد درخواستی ثبت نشده است (NODATA)—معماری پروتکل را با یک چالش اساسی روبه‌رو ساخت. برای محافظت از کلیدهای خصوصی امضای زون (ZSK) در برابر نفوذ به سرورهای مقتدر، استانداردهای اولیه رویکرد امضای آفلاین را در دستور کار قرار دادند. مدیر دامنه کل زون را روی سیستمی جداگانه امضا کرده و امضاهای ثابت را به سرورهای عمومی ارسال می‌کرد.

این سازوکار امکان امضای بلادرنگ برای پرس‌وجوهای ناموجود را بدون قراردادن کلید خصوصی روی سرورهای آنلاین ناممکن می‌ساخت. برای اثبات عدم وجود به شکل ایستا، کارگروه IETF رکورد Next Secure (NSEC) را در قالب استاندارد RFC 4034 تعریف کرد. با وجود ساختار ریاضی دقیق، این رکورد یک کانال جانبی پنهان به نام پیمایش دامنه (DNSSEC Zone Walking) ایجاد کرد که به مهاجمان امکان می‌دهد ساختار شبکه سازمانی را در چند دقیقه ترسیم کنند.

معمای انکار احراز هویت شده: چرا پاسخ‌های منفی ساختار DNS را فاش می‌کنند

در سیستم سنتی DNS بدون اعتبارسنجی، سرور مقتدر در صورت پیدا نشدن نام، تنها یک پرچم هدر با کد پاسخ 3 (NXDOMAIN) ارسال می‌کند. اما ریزالورهای بازگشتی اعتبارسنج نیازمند اثبات ریاضی غیرقابل انکار هستند تا مطمئن شوند مهاجم با پاسخ جعلی یک سرویس قانونی را مسدود نکرده است.

امضای دیجیتال پویا برای هر پرس‌وجوی ناموجود مستلزم نگهداری دائم کلید ZSK روی سرورهای لبه شبکه است. در آغاز پیاده‌سازی DNSSEC، طراحان به دلیل خطرات افشای کلید این رویکرد را رد کردند و در RFC 4034 به سراغ اثبات بازه‌های از پیش امضاشده رفتند.

سرور به جای ادعای صریح مبنی بر عدم وجود یک رکورد، گزاره‌ای امضاشده صادر می‌کند: در این زون که به ترتیب حروف الفبا مرتب شده، بین دو نام معتبر A و B هیچ رکورد دیگری وجود ندارد. این بازه گرچه عدم وجود را ثابت می‌کند، اما نام دقیق هر دو رکورد مرزی را برای پرسش‌کننده آشکار می‌سازد.

کالبدشکافی RFC 4034: چگونه رکوردهای NSEC یک لیست پیوندی ناخواسته می‌سازند

یک رکورد NSEC با اشاره مستقیم به نام استاندارد بعدی در فایل زون، وظیفه انکار احراز هویت شده را انجام می‌دهد. بار داده این رکورد شامل دو بخش اصلی است: نام دامنه بعدی (Next Domain Name) و یک نقشه بیتی (Type Bit Maps) که انواع رکوردهای فعال در آن نام را نشان می‌دهد.

;; نمونه ترتیب متعارف در فایل زون سازمانی
alpha.example.com.     3600 IN NSEC  billing.example.com.   A RRSIG NSEC
billing.example.com.   3600 IN NSEC  db-cluster.example.com. A RRSIG NSEC
db-cluster.example.com. 3600 IN NSEC  example.com.           A RRSIG NSEC

این رکوردها یک لیست پیوندی حلقوی بسته تشکیل می‌دهند. آخرین رکورد NSEC به صورت دورانی مجدداً به رأس زون (example.com.) اشاره می‌کند. به این ترتیب، تمامی نام‌های میزبان داخلی در یک زنجیره قطعی به یکدیگر متصل می‌شوند.

ترتیب متعارف کانیکال و سازوکار پیمایش استاندارد دامنه

اسکنرهای امنیتی با ارسال پرس‌وجوهای بازگشتی معمولی از این ساختار زنجیره‌ای بهره‌برداری می‌کنند:

  1. پرس‌وجوی اولیه: اسکنر یک درخواست رکورد A برای نامی که دقیقاً قبل از رأس زون قرار می‌گیرد ارسال می‌کند، مانند 0.example.com.
  2. استخراج بازه: سرور مقتدر پاسخ NXDOMAIN را همراه با رکورد NSEC از رأس زون تا نخستین نام ارسال می‌کند: example.com. NSEC admin.example.com.
  3. پیشروی در زنجیره: اسکنر نام admin.example.com را ذخیره کرده و فوراً درخواست بعدی را می‌سازد: admin0.example.com.
  4. تکرار مرحله‌ای: سرور بازه بعدی را تحویل می‌دهد: admin.example.com NSEC api-gateway.example.com.
  5. اتمام حلقه: این فرایند آن‌قدر تکرار می‌شود تا رکوردی دریافت گردد که به example.com. بازگردد؛ بدین معنا که تمامی نام‌های زون استخراج شده‌اند.

شمارش زیردامنه‌ها: نقشه‌برداری از سطح حمله سازمانی در چند دقیقه

روش Zone Walking موانع سنتی شناسایی و رصد را بی‌اثر می‌کند. ابزارهای رایج کشف زیردامنه به حدس زدن با واژه‌نامه، گزارش‌های شفافیت گواهی یا موتورهای جستجو وابسته‌اند و هاست‌های داخلی را نادیده می‌گیرند.

با استفاده از ابزارهایی مانند ldns-walk در دامنه‌های مجهز به RFC 4034، مهاجمان فهرستی دست‌نخورده از پایگاه‌های داده داخلی، پنل‌های مدیریتی، کلاسترهای توسعه و سرورهای ورودی شبکه خصوصی استخراج می‌کنند. این داده‌ها الگوهای نام‌گذاری و زیرساخت نرم‌افزاری را فاش ساخته و زمینه نفوذ هدفمند را فراهم می‌آورند.

مصالحه مهندسی در RFC 5155: اثبات هش‌شده عدم وجود با رکوردهای NSEC3

در پاسخ به نگرانی‌های فزاینده حفظ حریم خصوصی، کارگروه IETF در سال 2008 استاندارد RFC 5155 را تحت عنوان NSEC3 (اثبات هش‌شده عدم وجود در DNSSEC) تصویب کرد.

هدف NSEC3 حفظ قابلیت انکار احراز هویت شده بدون نمایش نام‌های متنی بود. این استاندارد به جای مرتب‌سازی الفبایی رشته‌ها، هر نام را با الگوریتم SHA-1 هش کرده، نمک (salt) رمزنگاری به آن افزوده و تابع هش را چندین مرتبه تکرار می‌کند.

;; ساختار رکورد NSEC3: [الگوریتم] [پرچم‌ها] [تکرار] [نمک] [هش بعدی] [انواع رکورد]
2T8A7...example.com. 3600 IN NSEC3 1 0 10 A1B2C3D4 7K9P2... A RRSIG

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

شکستن سد NSEC3: حملات فرهنگ لغت با شتاب‌دهنده GPU و ابزار Hashcat

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

پس از جمع‌آوری داده‌ها، مهاجم کار خود را به صورت آفلاین ادامه می‌دهد. از آنجا که NSEC3 بر پایه SHA-1 با نمک ثابت کار می‌کند، این روند به یک حمله فرهنگ لغت آفلاین تبدیل می‌شود:

نام فرضی ("vpn") -> نمک ("A1B2C3D4") -> هش SHA-1 تکرارشونده -> مقایسه با حلقه هش‌ها

پردازنده‌های گرافیکی مدرن (GPU) توانایی اجرای ده‌ها میلیارد عملیات SHA-1 در ثانیه را دارند. نرم‌افزارهای تخصصی کرک مانند Hashcat دارای ماژول شتاب‌یافته بومی (Mode 8300: DNSSEC NSEC3) برای این ساختار هستند.

بستر سخت‌افزاری توان پردازش SHA-1 (GH/s) زمان واژه‌نامه 100k نام زمان فهرست 10M کلمه
1x NVIDIA RTX 4090 28.5 GH/s 0.0035 ثانیه 0.35 ثانیه
8x NVIDIA RTX 4090 228.0 GH/s 0.0004 ثانیه 0.04 ثانیه
32x NVIDIA H100 1,120.0 GH/s < 0.0001 ثانیه 0.009 ثانیه

پژوهش‌های امنیتی نشان می‌دهند حملات واژه‌نامه‌ای به حلقه‌های NSEC3 قادرند ظرف چند ساعت بین 65 تا 85 درصد نام‌های واقعی را بازیابی کنند، زیرا ساختارهای شرکتی معمولاً از پیشوندهای متداول (mail, vpn, api, auth, jira, dev) بهره می‌گیرند.

تله انکار سرویس محاسباتی: چرا تکرارهای بالای هش ریزالورها را فلج می‌کند

برای مقابله با پردازش سریع GPU، مدیران شبکه در گذشته پارامتر iterations در RFC 5155 را روی مقادیر بالا نظیر 500، 1000 یا حتی 2500 تنظیم می‌کردند.

این تصمیم خطای بزرگی بود و یک آسیب‌پذیری انکار سرویس (DoS) محاسباتی نامتقارن ایجاد کرد:

  • عدم تقارن: سرور مقتدر هنگام امضای آفلاین زون، هش‌ها را تنها یک بار محاسبه می‌کند.
  • بار سنگین ریزالور: با هر درخواست کاربر به نام‌های ناموجود، ریزالور اعتبارسنج مجبور است تمام 2500 دور هش SHA-1 را مجدداً حساب کند تا اثبات ریاضی را تأیید نماید.
  • تکثیر ترافیک مخرب: مهاجم با گسیل سیلابی از پرس‌وجوهای NXDOMAIN به ریزالورهای عمومی، 100 درصد توان پردازشی CPU سرور را درگیر محاسبات بیهوده می‌کند.

تحت این فشار، ریزالورها با کمبود رشته‌های پردازشی، افزایش تأخیر به بالای 1500 میلی‌ثانیه و اختلال در سرویس‌دهی مواجه می‌شوند.

مقاوم‌سازی نوین با RFC 9276: حذف نمک و محدودسازی تکرار به صفر

برای برطرف کردن خطر DoS محاسباتی و شفاف‌سازی امنیت شکننده پارامترها، کارگروه IETF استاندارد RFC 9276 (راهنمای تنظیم پارامترهای NSEC3) را ارائه کرد.

این سند چارچوب‌های سخت‌گیرانه‌ای برای مدیران زون وضع کرده است:

  1. تکرار باید صفر باشد: تکرار بیش از صفر مانعی در برابر GPUها نیست و فقط بار سنگینی بر دوش ریزالورها می‌گذارد. مقدار iterations = 0 الزامی است.
  2. حذف کامل نمک: نمک متغیر توانایی حفاظت از کلمات متداول را ندارد و کش ریزالور را در زمان بروزرسانی از کار می‌اندازد. استفاده از نمک خالی (با علامت -) توصیه می‌شود.
  3. محدودیت سقف محاسبات در ریزالور: نرم‌افزارهای ریزالور جدید سقف مشخصی برای تکرار در نظر می‌گیرند. اگر رکوردی از این سقف فراتر رود، پاسخ SERVFAIL ارسال می‌شود تا از فرسودگی پردازنده جلوگیری شود.
;; پیکربندی مدرن و استاندارد NSEC3 (مطابق RFC 9276)
;; الگوریتم = 1 (SHA-1)، پرچم‌ها = 0، تکرار = 0، نمک = -
U5G9E...example.com. 3600 IN NSEC3 1 0 0 - 8F3K2... A RRSIG

گام بعدی رمزنگاری: پروتکل NSEC5 و توابع تصادفی قابل تأیید (VRF)

به دلیل ناتوانی NSEC3 در دفع کامل حملات آفلاین، پژوهشگران رمزنگاری ساختار NSEC5 (انکار احراز هویت شده DNSSEC با توابع تصادفی قابل تأیید) را معرفی کردند.

پروتکل NSEC5 چالش پیمایش دامنه را با استفاده از ساختار نامتقارن VRF حل می‌کند:

  • سرور مقتدر کلید خصوصی VRF (sk_vrf) را در اختیار دارد.
  • ریزالور دارای کلید عمومی متناظر (pk_vrf) است.
  • برای تولید هش معتبر یک نام، داشتن sk_vrf الزامی است.
  • برای سنجش درستی اثبات، تنها کلید عمومی pk_vrf کفایت می‌کند.

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

امضای آنلاین در برابر امضای آفلاین: رویکرد راهکار "White Lies"

روش جایگزین دیگری که در شبکه‌های توزیع محتوای بزرگ اعمال می‌شود، NSEC با پوشش حداقلی (Minimal Covering NSEC) یا اصطلاحاً "White Lies" است (RFC 4470 و RFC 7129).

در این ساختار، سرور به جای ارائه لیست پیوندی ثابت، پاسخ را به صورت پویا در لبه شبکه امضا می‌کند:

  1. با ورود درخواستی برای نام ناموجود charlie.example.com، سرور در همان لحظه یک رکورد NSEC موقت می‌سازد که فقط بازه (charlie\000.example.com NSEC charlie\001.example.com) را شامل می‌شود.
  2. این رکورد عدم وجود دامنه را اثبات می‌کند بدون آن‌که کوچک‌ترین نشانه‌ای از نام‌های مجاور فاش سازد.
  3. این شیوه نیازمند وجود کلیدهای امضای فعال در گره‌های مرزی است که با ماژول‌های امنیتی سخت‌افزاری (HSM) به خوبی تأمین می‌شود.

تضمین‌های ریاضیاتی حریم خصوصی با ارزیابی نامتقارن توابع VRF

پروتکل NSEC5 امنیت امضای آفلاین را با محرمانگی سنتز بلادرنگ ترکیب می‌کند. مهاجم با هر درخواست شبکه تنها یک اثبات دریافت می‌نماید. جمع‌آوری یک میلیون زیردامنه مستلزم ارسال یک میلیون درخواست آنلاین است که فوراً توسط سیستم‌های نظارت شبکه شناسایی و مسدود می‌شود.

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

معماری DNS بازگشتی RiceGuard: مقابله بنیادین با شناسایی و رصد زون

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

فناوری RiceGuard در لایه 3 برای خنثی‌سازی ردیابی DNS و ایمن‌سازی دستگاه‌ها توسعه یافته است:

  • حداقل‌سازی درخواست‌ها (RFC 7816): ریزالورهای RiceGuard بخش‌های اضافی نام دامنه را حذف کرده و فقط بخش مورد نیاز برای واگذاری فعلی را ارسال می‌کنند.
  • ذخیره‌سازی هوشمند پاسخ‌های منفی: این سامانه پاسخ‌های NXDOMAIN را کش می‌کند (RFC 2308) تا به درخواست‌های تکراری درجا پاسخ داده و از اشباع سرورها جلوگیری کند.
  • کنترل خودکار تکرار هش: همگام با RFC 9276، ریزالور رکوردهای NSEC3 با تکرار غیرمعمول را مسدود یا تضعیف می‌کند تا مانع بارگذاری بیهوده پردازنده گردد.
  • جلوگیری ساختاری از نشت DNS: تمامی بسته‌ها از طریق تونل‌های احراز هویت شده WireGuard به سرورهای تفکیک‌شده هدایت می‌شوند تا آی‌پی کاربران پنهان بماند. صحت تنظیمات ارتباطی از طریق ابزار /what-is-my-ip قابل بررسی است.

علاقه‌مندان به بهره‌مندی از اتصالات پایدار می‌توانند برنامه‌های سازگار را از بخش /download دریافت کنند. مبانی رمزنگاری ترافیک DNS در مقاله /news/dnssec-vs-encrypted-dns-authenticity-privacy-architecture و راهکارهای جلوگیری از تحلیل زمانی در /news/dns-cache-snooping-non-recursive-query-timing-defense تشریح شده است.

ممیزی عملی و راهکارهای دفاعی: تشخیص پیمایش دامنه و پیکربندی ریزالورها

مدیران زیرساخت باید دامنه‌های سازمانی را پایش کنند تا رکوردهای کهنه NSEC موجب نشت اطلاعات شبکه نشوند. این فرایند ارزیابی سیاست‌های امضا را شامل می‌شود.

برای بررسی آسیب‌پذیری در RFC 4034 می‌توان از دستور dig +dnssec example.com NSEC یا ابزار ldns-walk @ns1.example.com example.com استفاده کرد. اگر خروجی لیستی از نام‌ها باشد، مهاجرت به NSEC3 طبق RFC 9276 ضروری است.

در سرویس BIND 9 تنظیمات را در فایل named.conf وارد کنید:

dnssec-policy "hardened-nsec3" {
    keys {
        ksk lifetime 365d algorithm ecdsap256sha256;
        zsk lifetime 60d algorithm ecdsap256sha256;
    };
    nsec3param {
        iterations 0;
        optout no;
        salt-length 0;
    };
};

در نرم‌افزار Knot DNS (knot.conf) مقادیر nsec3-iterations: 0 و nsec3-salt-length: 0 را در بخش policy درج نمایید. با اجرای دستور dig +dnssec +multiline nonexistent.example.com A اطمینان حاصل کنید که رکورد NSEC3 دارای تکرار 0 و نمک خالی - باشد. حذف تکرارهای غیرضروری و بهره‌گیری از ریزالورهای مستحکم، مانع افشای ساختار شبکه شده و اعتبار کامل DNSSEC را محفوظ نگه می‌دارد.