سال‌ها پروتکل‌های سنتی رمزنگاری سامانه نام دامنه، به‌ویژه DNS-over-TLS (استاندارد RFC 7858) و DNS-over-HTTPS (استاندارد RFC 8484)، نقشی اساسی در حراست از ترافیک متن‌باز درگاه ۵۳ در برابر شنود ارائه‌دهندگان اینترنت ایفا کرده‌اند. با این وجود، اتکای هر دو فناوری به لایه انتقال مبتنی بر پروتکل TCP، چالش ساختاری بزرگی به نام «قفل شدن سر صف» (Head-of-Line Blocking یا HoL) ایجاد کرده است.

در مه سال ۲۰۲۲، کارگروه مهندسی اینترنت (IETF) پروتکل رسمی RFC 9250: DNS over Dedicated QUIC Connections (DoQ) را به تصویب رساند. این استاندارد نوین پرس‌وجوهای دامنه را بر بستر پروتکل مدرن QUIC هدایت می‌کند و محدودیت‌های سنتی TCP را پشت سر می‌گذارد.

+-------------------------------------------------------------+
|             مقایسه لایه‌های انتقال پروتکل‌های DNS            |
+-------------------------------------------------------------+
| Do53: [ DNS Payloads ] -> UDP Port 53 (متن آشکار بدون رمز)  |
| DoT:  [ DNS Payloads ] -> TLS 1.3 -> TCP Socket (درگاه 853) |
| DoH:  [ DNS Payloads ] -> HTTP/2 / HTTP/3 -> TLS -> TCP/QUIC|
| DoQ:  [ DNS Payloads ] -> Dedicated QUIC Streams (درگاه 853)|
+-------------------------------------------------------------+

چالش‌های بنیادین معماری مبتنی بر TCP در DoT و DoH

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

۱. قفل شدن سر صف در جریان‌های TCP (Head-of-Line Blocking)

پروتکل TCP جریان داده‌ها را به صورت توالی پیوسته‌ای از بایت‌ها منتقل می‌کند. هنگامی که یک مرورگر وب به طور هم‌زمان چندین درخواست DNS برای المان‌های یک وب‌سایت ارسال می‌کند، اگر یک بسته مربوط به درخواست اول بر اثر اختلال رادیویی از بین برود، تمامی درخواست‌های بعدی در پشته شبکه منتظر دریافت مجدد آن بسته می‌مانند؛ حتی اگر داده‌های آن‌ها به‌طور کامل دریافت شده باشد.

۲. تأخیر زمانی در دست‌تکانی اولیه (Handshake Latency)

برقراری ارتباط امن در پروتکل DoT مستلزم یک تبادل سه مرحله‌ای TCP (معادل 1 RTT) و سپس تبادل کلید TLS 1.3 (معادل 1 RTT دیگر) است. این فرآیند دست‌کم ۲ رفت‌وبرگشت کامل (بین ۸۰ تا ۳۰۰ میلی‌ثانیه) تأخیر پیش از ارسال اولین پرس‌وجو به همراه دارد:

کلاینت کاربر                                              سرور DoT
   | --- TCP SYN -----------------------------------------> |
   | <-- TCP SYN-ACK -------------------------------------- | (1 RTT)
   | --- TCP ACK + TLS ClientHello -----------------------> |
   | <-- TLS ServerHello + EncryptedExtensions + Finished - | (2 RTT)
   | === کانال امن آماده شد: ارسال درخواست DNS ===          |

۳. قطع نشست هنگام جابه‌جایی شبکه (Network Roaming)

سوکت‌های TCP با چهار مولفه (آدرس IP مبدأ، پورت مبدأ، آدرس IP مقصد، پورت مقصد) شناخته می‌شوند. هنگامی که کاربر از اتصال وای‌فای به داده همراه 4G یا 5G جابه‌جا می‌شود، آدرس IP محلی تغییر می‌کند و سوکت با بسته RST بسته می‌شود. در نتیجه، دستگاه ناچار است فرآیند اتصال را از ابتدا انجام دهد.

۴. سربار لایه وب در DoH

پروتکل DoH داده‌ها را در قالب چارچوب‌های HTTP/2 یا HTTP/3 و هدرهای سفارشی (:method, :path, Content-Type) کپسوله‌سازی می‌کند. همچنین اشتباهات پیکربندی می‌تواند موجب نشت متادیتاهایی نظیر کوکی‌ها یا User-Agent گردد.

نوآوری‌های کلیدی در پروتکل DNS-over-QUIC (RFC 9250)

پروتکل DoQ با حذف لایه‌های زائد و استقرار مستقیم روی بستر UDP، کارایی و امنیت را ارتقا می‌دهد:

       QUIC Connection (Single UDP Datagram Session)
+-------------------------------------------------------+
|  Stream 0: DNS Query A (example.com)      - فعال      |
|  Stream 4: DNS Query B (api.service.org)  - بسته مفقود| <- بسته مفقود شد
|  Stream 8: DNS Query C (cdn.media.net)    - پاسخ فوری | <- بدون تأخیر تحویل شد
+-------------------------------------------------------+

۱. تفکیک کامل جریان‌ها و حذف گلوگاه HoL

در پروتکل DoQ، هر پرس‌وجوی DNS در یک جریان مستقل دوطرفه (Bidirectional Stream) مخابره می‌شود. مفقود شدن بسته‌ها در یک جریان به هیچ وجه پردازش یا تحویل داده‌های جریان‌های دیگر را متوقف نمی‌سازد.

۲. کاهش زمان دست‌تکانی و قابلیت 0-RTT

پروتکل QUIC لایه امنیت TLS 1.3 را در پروتکل انتقال ادغام کرده است:

  • اتصال اولیه (1-RTT): تبادل کلید و احراز هویت هم‌زمان در یک رفت‌وبرگشت انجام می‌شود.
  • اتصال مجدد (0-RTT): با تکیه بر سازوکار Early Data، کلاینت می‌تواند پرس‌وجوی DNS را درون نخستین بسته ارسالی جاسازی کند و بدون انتظار برای پاسخ سرور، داده را ارسال نماید.
کلاینت                                                 سرور DoQ
  | --- QUIC Initial [Crypto ClientHello + 0-RTT Query] -> |
  | <-- QUIC Handshake [ServerHello] + 0-RTT Response ---- | (پاسخ در زمان 0 RTT!)

۳. پایداری نشست با قابلیت Connection Migration

اتصالات QUIC به جای آدرس IP، با یک شناسه ۶۴ بیتی مستقل به نام Connection ID مدیریت می‌شوند. هنگام سوییچ از وای‌فای به شبکه همراه، بسته با همان شناسه اما از IP جدید ارسال شده و ارتباط بدون قطعی یا تکرار دست‌تکانی حفظ می‌شود.

۴. پدگذاری رمزی برای مقابله با تحلیل ترافیک (RFC 8467)

تحلیل‌گران شبکه حتی بدون دسترسی به متن پرس‌وجو، با بررسی اندازه دقیق بسته‌ها قادرند دامنه‌های احتمالی مورد بازدید را حدس بزنند. پروتکل DoQ با پیاده‌سازی پدگذاری داده‌ها بر پایه استاندارد RFC 8467، اندازه بسته‌ها را به مضارب ثابت (مانند ۱۲۸ یا ۴۶۸ بایت) ارتقا می‌دهد و از شناسایی الگوهای ترافیکی ممانعت به عمل می‌آورد.

راهنمای آزمایش عملیاتی DoQ

اکنون نرم‌افزارهای مدرن نظیر AdGuard Home و CoreDNS و کلاینت‌های مستقل از این استاندارد پشتیبانی می‌کنند.

۱. تست با ابزار خط فرمان q

ابزار متن‌باز q امکانی ساده برای محک زدن پروتکل DoQ فراهم می‌سازد:

# ارسال پرس‌وجوی آزمایشی DoQ به سرور عمومی روی پورت 853
q A example.com @quic://dns.adguard-dns.com:853

# مشاهده جزئیات دست‌تکانی QUIC و جریان‌های فعال
q A example.com @quic://dns.adguard-dns.com:853 -v

۲. پیکربندی در سرور CoreDNS

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

quic://.:853 {
    tls /etc/coredns/certs/fullchain.pem /etc/coredns/certs/privkey.pem
    forward . 1.1.1.1 8.8.8.8 {
        prefer_udp
    }
    cache 300
    log
}

نقش DoQ در پشته امنیتی VPNRice RiceGuard

در زیرساخت امنیتی VPNRice، لایه RiceGuard پرس‌وجوهای سامانه‌های کاربران را محافظت می‌کند:

[دستگاه کاربر]
      |
      v (DoQ / RFC 9250 از طریق پورت UDP 853)
[فیلتر محلی RiceGuard]
      |
      v (تونل رمزنگاری‌شده اختصاصی WireGuard / Anycast)
[سرورهای بازگشتی نام دامنه مبتنی بر RAM بدون ذخیره لاگ]
  • جلوگیری از نشت اطلاعات DNS: تمام استعلام‌ها از بسترهای محلی ایزوله شده و از مسیرهای نامطمئن اینترنت دور نگه داشته می‌شوند.
  • عدم ثبت گزارش (Zero Logging): سرورهای بازگشتی RiceGuard تماماً بر حافظه موقت (RAM-only) اجرا می‌شوند و داده‌های هویتی یا پیشوند کلاینت (ECS) را به سرورهای مرجع ارسال نمی‌کنند.
  • ثبات پیوسته در ارتباطات همراه: هم‌افزایی قابلیت انتقال نشست QUIC با چابکی پروتکل WireGuard موجب می‌شود اتصال کاربر هنگام جابه‌جایی میان دکل‌های مخابراتی دچار مکث یا قطعی نگردد.