سامانه نام دامنه (DNS) پایه و اساس آدرس‌دهی در اینترنت است که نام‌های دامنه را به آدرس‌های IP مقصد ترجمه می‌کند. برای دهه‌ها، پروتکل انتقال اصلی برای درخواست‌های دی‌ان‌اس، پروتکل UDP روی پورت ۵۳ بوده است. با این که UDP به دلیل حذف دست‌دادن سه‌مرحله‌ای، تأخیر تراکنش‌ها را به حداقل می‌رساند، ماهیت بدون اتصال آن یک ضعف ساختاری بزرگ ایجاد کرده است: جعل آدرس IP مبدا. مهاجمان همواره از سرورهای بازگشتی و نام‌سرورهای معتبر برای اجرای حملات انکار سرویس توزیع‌شده (DDoS) بازتابی و مسموم‌سازی حافظه پنهان خارج از مسیر سوءاستفاده می‌کنند. استانداردهای RFC 7873 با عنوان کوکی‌های سامانه نام دامنه و استاندارد مکمل RFC 9018 سازوکاری سبک و بدون نیاز به ذخیره وضعیت در ساختار EDNS(0) تعریف کرده‌اند تا اصالت دوجانبه تراکنش‌ها میان کلاینت و سرور دی‌ان‌اس تأیید شود.

درخواست سنتی UDP بدون اعتبارسنجی (آسیب‌پذیر در برابر جعل):
مهاجم (جعل آی‌پی قربانی) ─────── درخواست ───────> تحلیل‌گر دی‌ان‌اس
قربانی هدف <───────── پاسخ تقویت‌شده بازتابی ──── تحلیل‌گر دی‌ان‌اس

تراکنش محافظت‌شده با کوکی دی‌ان‌اس (RFC 7873 / RFC 9018):
کلاینت ────── درخواست + کوکی کلاینت (۸ بایت) ─────> سرور دی‌ان‌اس
کلاینت <── پاسخ + کوکی کلاینت + کوکی سرور ────── سرور دی‌ان‌اس
(تأیید هویت دوسویه؛ بسته‌های جعلی خارج از مسیر مسدود یا محدود می‌شوند)

بحران تقویت ترافیک در UDP: چرایی ناامنی دی‌ان‌اس سنتی

درخواست‌های استاندارد دی‌ان‌اس مبتنی بر پروتکل UDP هیچ مدرک ذاتی برای اثبات هویت ارسال‌کننده ارائه نمی‌دهند. هنگامی که یک نام‌سرور درخواستی را دریافت می‌کند، صرفاً فیلد آدرس مبدا را در هدر بسته IP بررسی می‌کند. از آنجا که UDP پیش از ارسال داده‌ها، دسترسی‌پذیری دوطرفه مسیر را نمی‌سنجد، مهاجم می‌تواند به سادگی بسته‌های حاوی آدرس IP جعلی قربانی را به سرورهای مختلف ارسال کند.

انتقال بدون حالت و جعل آدرس‌های مبدا آی‌پی

تفاوت فاحش اندازه میان درخواست‌های کوتاه دی‌ان‌اس و پاسخ‌های بزرگ حاوی اطلاعات رمزنگاری، ضریب تقویت ترافیک بسیار بالایی ایجاد می‌کند. یک درخواست ۶۴ بایتی برای دریافت رکوردهای ANY، امضاهای DNSSEC (شامل RRSIG و DNSKEY) یا رکوردهای حجیم TXT، پاسخ‌هایی با حجم بیش از ۳۰۰۰ بایت تولید می‌کند. چنانچه ارائه‌دهندگان بالادستی از فیلتر آدرس مبدا (BCP 38 / RFC 2827) استفاده نکنند، مهاجمان پهنای باند قربانی را با هدایت ترافیک هزاران سرور بازگشتی اشباع می‌کنند.

همچنین عدم احراز هویت مبدا، حملات مسموم‌سازی کش را تسهیل می‌کند. مهاجم با حدس زدن شناسه تراکنش و پورت مبدا، رکوردهای جعلی را پیش از رسیدن پاسخ واقعی به کش وارد می‌کند. با اینکه DNSSEC صحت داده‌های پاسخ را تضمین می‌کند، اما هویت درخواست‌کننده را بررسی نکرده و مانع از سوءاستفاده از سرور برای حملات بازتابی نمی‌شود.

هزینه‌ها و شکنندگی سازوکار محدودیت نرخ پاسخ RRL

برای جلوگیری از امواج حملات بازتابی، مدیران سرور سازوکار محدودیت نرخ پاسخ (RRL) را به کار گرفتند. RRL حجم درخواست‌ها را بر اساس پیشوند آی‌پی کلاینت (پیشوند ۲۴ برای IPv4 یا پیشوند ۵۶ برای IPv6) شمارش کرده و پاسخ‌های فراتر از حد مجاز را حذف یا کوتاه (TC=1) می‌کند.

با اینکه RRL ترافیک مخرب را تا حدی کاهش می‌دهد، مشکلات عملیاتی متعددی به همراه دارد:

  • کلاینت‌های پشت گیت‌وی‌های NAT اپراتورها (CGNAT) پیشوند مشترکی با دستگاه‌های آلوده دارند و پاسخ‌های قانونی آنها دور ریخته می‌شود.
  • کوتاه شدن پاسخ‌ها کلاینت را مجبور به بازگشت به TCP می‌کند که منجر به تأخیر دست‌دادن سه‌مرحله‌ای و افزایش مصرف منابع سوکت در سیستم‌عامل می‌شود.
  • در زمان اوج ترافیک معمول، نرخ پاسخ قانونی ممکن است اشتباهاً محدود شود و برنامه‌های کاربران با وقفه زمانی مواجه شوند.

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

معماری RFC 7873: دست‌دادن دوگانه کوکی از طریق EDNS(0)

استاندارد RFC 7873 توکن‌های احراز هویت را در ساختار مکانیزم‌های توسعه دی‌ان‌اس (EDNS(0), RFC 6891) تحت کد گزینه Option Code 10 تعریف می‌کند.

+-------------------------------+-------------------------------+
|       OPTION-CODE (10)        |     OPTION-LENGTH (16-40)     |
+-------------------------------+-------------------------------+
|                    Client Cookie (8 اککتت)                   |
+---------------------------------------------------------------+
|                    Server Cookie (8-32 اککتت)                 |
+---------------------------------------------------------------+

این پروتکل بر پایه یک تبادل دو مرحله‌ای میان کلاینت دی‌ان‌اس (تحلیل‌گر استاب یا بازگشتی) و سرور دی‌ان‌اس (سرور بازگشتی یا معتبر) عمل می‌کند.

کوکی کلاینت: تولید شناسه تصادفی موقت

کوکی کلاینت یک توکن شبه‌تصادفی ۸ بایتی است که توسط کلاینت ایجاد می‌شود. این توکن باید برای ناظران غیرقابل پیش‌بینی باشد، اما برای یک سرور خاص در یک بازه زمانی مشخص به طور یکسان محاسبه شود:

$$\text{Client Cookie} = \text{PRF-64}(\text{Client IP}, \text{Server IP}, \text{Client Secret})$$

کلید مخفی کلاینت شامل ۱۲۸ بیت انتروپی است که در حافظه موقت نگهداری می‌شود. چرخش دوره‌ای این کلید (معمولاً هر ۲۴ ساعت) توکن‌های قدیمی را بدون نیاز به ذخیره‌سازی دائمی باطل می‌کند. پیوند زدن آی‌پی کلاینت و سرور مانع از آن می‌شود که مهاجم کوکی شنود شده را برای سرور دیگری ارسال کند.

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

هنگامی که سرور درخواستی شامل کوکی کلاینت دریافت می‌کند، مراحل زیر را طی می‌کند:

  1. درخواست اولیه: کلاینت تنها کوکی ۸ بایتی خود را ارسال می‌کند و طول گزینه برابر با ۸ است.
  2. محاسبه در سرور: سرور وضعیت اولیه را تشخیص داده و یک کوکی سرور بر پایه کوکی کلاینت، آدرس آی‌پی کلاینت و کلید مخفی داخلی سرور تولید می‌کند.
  3. پاسخ با دو کوکی: سرور هر دو کوکی کلاینت و کوکی تولیدشده سرور را در فیلد EDNS(0) OPT به کلاینت بازمی‌گرداند.
  4. ذخیره در کش کلاینت: کلاینت صحت کوکی خود را بررسی کرده و کوکی سرور را بر اساس آدرس سرور در حافظه ذخیره می‌کند.
  5. درخواست‌های بعدی: کلیه درخواست‌های بعدی هر دو کوکی را ارسال می‌کنند (مجموعاً ۱۶ تا ۴۰ بایت). سرور با محاسبه مجدد هش، هویت کلاینت را فوراً تصدیق می‌کند.

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

مشخصات کوکی سرور تعامل‌پذیر بر اساس RFC 9018

پیش از تدوین RFC 9018، ساختار داخلی کوکی سرور به صورت سلیقه‌ای توسط توسعه‌دهندگان نرم‌افزار پیاده‌سازی می‌شد. در شبکه‌های انی‌کست چندسازنده‌ای که از نرم‌افزارهای گوناگون (نظیر BIND، NSD، Knot DNS و PowerDNS) استفاده می‌کردند، نودها قادر به درک توکن‌های یکدیگر نبودند.

استاندارد RFC 9018 با تعیین یک قالب ثابت ۱۶ بایتی برای کوکی سرور این ناسازگاری را حل کرد.

+---------------+---------------+-------------------------------+
| Version (0x01)|       Reserved (0x000000)                     |
+---------------+---------------+-------------------------------+
|                      Timestamp (4 اککتت)                      |
+---------------------------------------------------------------+
|                      Hash (8 اککتت)                           |
+---------------------------------------------------------------+

فیلدهای این ساختار عبارتند از:

  • Version (۱ بایت): شناسه نسخه فرمول محاسبه که برابر با 0x01 است.
  • Reserved (۳ بایت): فیلد رزرو شده که در ارسال 0x000000 بوده و در دریافت نادیده گرفته می‌شود.
  • Timestamp (۴ بایت): عدد صحیح ۳۲ بیتی نشان‌دهنده برچسب زمانی یونیکس بر حسب ثانیه.
  • Hash (۸ بایت): کد تأیید اصالت رمزنگاری‌شده برش‌خورده در ۶۴ بیت.

ساختار SipHash-2-4 و هش کوتاه شده ۶۴ بیتی

استاندارد RFC 9018 از تابع شبه‌تصادفی SipHash-2-4 برای تولید فیلد هش استفاده می‌کند. این الگوریتم برای داده‌های ورودی کوتاه عملکردی بسیار سریع داشته و در برابر حملات تبانی هش کاملاً مقاوم است.

فرمول تولید هش به شرح زیر است:

$$\text{Hash} = \text{SipHash-2-4}(\text{Server Secret}, \text{Client Cookie} ,|, \text{Version} ,|, \text{Reserved} ,|, \text{Timestamp} ,|, \text{Client IP})$$

سرور دو گام بررسی را اجرا می‌کند:

  1. اعتبارسنجی زمان: تأیید شرط $|T_{\text{کنونی}} - T_{\text{کوکی}}| \le 3600 \text{ ثانیه}$. پنجره یک‌ساعته نوسانات شبکه را پوشش داده و فرصت سوءاستفاده از بسته‌های تکراری را محدود می‌سازد.
  2. بررسی امضای رمزنگاری: محاسبه مجدد SipHash-2-4 با کلید فعال و مقایسه ثابت‌زمان برای جلوگیری از حملات مبتنی بر زمان.

درخواست‌های معتبر تایید شده و از اعمال محدودیت‌های RRL معاف می‌شوند و پاسخ کامل مطابق با بافر EDNS ارسال می‌گردد.

مدیریت توپولوژی‌های انی‌کست و چرخش کلیدهای امنیتی

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

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

  • کلید فعال ($K_{\text{active}}$): برای تولید کوکی‌های جدید سرور و ارزیابی درخواست‌های ورودی.
  • کلید پیشین ($K_{\text{previous}}$): در دوره جابجایی کلیدها (بین ۲ تا ۲۴ ساعت) برای پذیرش کوکی‌های ایجادشده با کلید قبلی حفظ می‌شود.

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

مدیریت خطای BADCOOKIE و سازوکار سازگاری به عقب

اگر سروری با درخواستی حاوی کوکی منقضی، خراب یا نامعتبر مواجه شود، فرآیند بازیابی استاندارد RFC 7873 فعال می‌گردد:

  1. جلوگیری از تقویت ترافیک: سرور از فرستادن پاسخ کامل خودداری می‌کند.
  2. اعلام خطا: یک پاسخ خالی با کد وضعیت RCODE=9 (BADCOOKIE) همراه با حفظ شناسه تراکنش ارسال می‌شود.
  3. تزریق کوکی جدید: در بخش EDNS(0) OPT، کوکی اولیه کلاینت همراه با یک کوکی تازه سرور قرار داده می‌شود.
  4. تلاش مجدد کلاینت: کلاینت با دریافت پاسخ خطا، اطلاعات را به‌روزرسانی کرده و فوراً درخواست اصلی را دوباره ارسال می‌نماید.

اگر تجهیزات واسط شبکه قابلیت EDNS(0) را حذف کنند، کلاینت با مشاهده عدم بازگشت کوکی، به حالت سنتی دی‌ان‌اس سوئیچ کرده تا پایداری ارتباط قطع نشود.

یکپارچگی با RiceGuard: معماری دی‌ان‌اس با اعتماد صفر و ایمن‌سازی ترافیک

مجموعه امنیتی RiceGuard در ساختار VPNRice استانداردهای کوکی‌های دی‌ان‌اس را در لایه‌های کلاینت و سرورهای بازگشتی ادغام کرده تا چارچوب Zero-Trust پایداری شکل گیرد.

معماری دی‌ان‌اس Zero-Trust در سامانه RiceGuard:
دستگاه کاربر (برنامه کاربردی VPNRice)
  │
  ├── تونل رمزگذاری‌شده WireGuard / IPsec (ChaCha20-Poly1305 / AES-256-GCM)
  ▼
نودهای ورودی لبه انی‌کست RiceGuard
  │  - بررسی اجباری کوکی‌های سرور RFC 9018 در ترافیک UDP
  │  - دفع تلاش‌های تقویت ترافیک جعلی در ورودی شبکه
  │  - همگام‌سازی کلیدهای SipHash-2-4 در تمام نقاط لبه جهان
  ▼
موتور بازگشتی امن
  │  - درج کوکی‌های کلاینت در استعلام از سرورهای ریشه و TLD
  │  - تأیید کوکی سرور در پاسخ‌های دریافتی از نام‌سرورهای خارجی
  │  - پایش مستمر زنجیره اعتبارسنجی DNSSEC
  ▼
زیرساخت جهانی سرورهای نام اینترنت
  1. انتقال درون تونل‌های رمزنگاری: درخواست‌های کاربران از طریق تونل‌های WireGuard یا IPsec مستقیماً به نودهای انی‌کست RiceGuard ارسال شده و از شنود در شبکه‌های عمومی وای‌فای در امان می‌مانند.
  2. سد دفاعی در لبه: واسط‌های عمومی انی‌کست کلیه بسته‌های ورودی UDP را با کوکی‌های RFC 9018 تطبیق می‌دهند و مانع از سوءاستفاده از سرور برای حملات می‌شوند.
  3. امنیت در کوئری‌های بالادستی: سرورهای بازگشتی هنگام پرس‌وجو از دامنه‌های اینترنتی، از کوکی‌های کلاینت استفاده کرده و بازگشت داده‌های صحیح را بررسی می‌کنند تا از نفوذ داده‌های جعلی به کش جلوگیری شود.

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

اعتبارسنجی عملیاتی: آزمایش کوکی‌های دی‌ان‌اس با ابزار Dig

مدیران شبکه می‌توانند پشتیبانی از استانداردهای کوکی دی‌ان‌اس را با استفاده از ابزار کاربردی dig بررسی نمایند.

ارسال درخواست همراه با مذاکره کوکی

نگارش‌های جدید dig این ویژگی را به طور خودکار فعال می‌کنند:

# استعلام از تحلیل‌گر انی‌کست با قابلیت فعال کوکی
dig @1.1.1.1 vpnrice.com +cookie

در بخش خروجی ترمینال در قسمت OPT PSEUDOSECTION می‌توان وضعیت را مشاهده کرد:

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 5a8e2b109c3d4f8a 01000000672c8410d9f82e14a7c3b901 (good)
;; QUESTION SECTION:
;vpnrice.com.			IN	A

;; ANSWER SECTION:
vpnrice.com.		300	IN	A	104.21.48.12

توضیح داده‌های نمایش داده شده:

  • 5a8e2b109c3d4f8a: کوکی کلاینت ۸ بایتی که توسط ابزار تولید شده است.
  • 01000000672c8410d9f82e14a7c3b901: کوکی سرور ۱۶ بایتی بر اساس استاندارد RFC 9018:
    • نسخه: 01
    • فیلد رزرو: 000000
    • زمان: 672c8410 (زمان یونیکس در مبنای شانزده)
    • مقدار هش: d9f82e14a7c3b901 (خروجی تابع SipHash-2-4)
  • عبارت (good) نشان‌دهنده تطابق و موفقیت اعتبارسنجی رمزنگاری است.

ارزیابی رفتار در صورت عدم تطابق کوکی

برای آزمایش صحت عملکرد بازیابی خطا می‌توان کوکی اشتباه ارسال کرد:

# ارسال کوکی نامعتبر ۱۶ بایتی به سرور
dig @1.1.1.1 vpnrice.com +cookie=5a8e2b109c3d4f8a0100000000000000ffffffffffffffff

سرور منطبق بر استاندارد با پاسخ status: BADCOOKIE و بدون بخش داده‌ها، یک کوکی تازه را در فیلد OPT برای تنظیم مجدد ارائه می‌دهد.

کوکی‌های دی‌ان‌اس شکاف میان سرعت انتقال پروتکل UDP و الزامات احراز هویت را پوشش می‌دهند. پیاده‌سازی RFC 7873 و RFC 9018 در سطح سرورهای معتبر و بازگشتی، تهدیدات مربوط به حملات تقویتی را در لایه انتقال برطرف ساخته و پایداری شبکه را حفظ می‌کند.

برای حفاظت از تبادلات اینترنتی و بهره‌گیری از شبکه امن سرورهای انی‌کست با استانداردهای نوین شبکه، می‌توانید اقدام به دریافت VPNRice نمایید.