برای چندین دهه، سامانه نام دامنه (DNS) به‌صورت متن ساده روی پورت UDP 53 تبادل می‌شد. این فقدان سازوکارهای حفاظتی باعث می‌شد ارائه‌دهندگان اینترنت، گردانندگان هات‌اسپات‌های عمومی و مسیرهای میانی شبکه بتوانند کلیه دامنه‌ها و سرویس‌های مورد فراخوانی کاربران را ثبت و پایش کنند.

پیدایش پروتکل‌های DNS-over-TLS (DoT, RFC 7858)، DNS-over-HTTPS (DoH, RFC 8484) و DNS-over-QUIC (DoQ, RFC 9250) رمزنگاری پایداری را در لایه انتقال ارائه کرد. با این حال، پیاده‌سازی‌های اولیه متکی بر تنظیمات دستی و ایستا برای آدرس‌های IP سرورهای عمومی (مانند 1.1.1.1 یا 8.8.8.8) بودند.

این مدل پیکربندی ایستا در شبکه‌های خصوصی مجازی (VPN) و زیرساخت‌های سازمانی چالش‌های جدی به وجود می‌آورد؛ زیرا تفکیک دامنه‌های داخلی سازمان (Split-Horizon برای نام‌هایی نظیر intranet.internal) را مختل ساخته، باعث نشت ترافیک DNS به خارج از تونل شده و مانع از ارائه مستقیم سرویس‌های رمزنگاری محلی توسط گیت‌وی‌های شبکه می‌گردد.

کارگروه Adaptive DNS Discovery (ADD) در IETF جهت رفع این مشکل و تحقق ارتقای خودکار و بدون نیاز به پیکربندی دستی، دو استاندارد مکمل RFC 9462 (Discovery of Designated Resolvers, DDR) و RFC 9463 (Discovery of Network-designated Resolvers, DNR) را نهایی ساخت.

+--------------------------------------------------------------------------+
|            گردش کار کشف سرور مشخص شده در پروتکل RFC 9462 DDR             |
+--------------------------------------------------------------------------+
|                                                                          |
|    +------------+        1. پرس‌وجوی متن ساده (UDP 53)     +------------+ |
|    |            | --------------------------------------> | گیت‌وی     | |
|    |   کلاینت   |   QNAME: _dns.resolver.arpa (Type SVCB) | محلی یا    | |
|    | (سیستم‌عامل| <-------------------------------------- | بازگشتی VPN| |
|    | / ریزالور) |        2. پاسخ ساختاریافته SVCB         +------------+ |
|    +------------+   TargetName: dns.vpnrice.internal             |       |
|          |          Alpn: "h2,h3", Port: 443                     |       |
|          |          IPv4/IPv6 hints                              |       |
|          |                                                       |       |
|          | 3. اعتبارسنجی نشانی و بررسی گواهی دیجیتال TLS         |       |
|          |    برقراری ارتباط با IP گیت‌وی روی TCP 443 / UDP 443  |       |
|          |    SNI: dns.vpnrice.internal                          |       |
|          v    تأیید گواهی X.509 با مخزن ریشه سیستم‌عامل          v       |
|    +----------------------------------------------------------------+    |
|    |               تونل ارتقایافته خودکار رمزنگاری DNS              |    |
|    |            (DoH / DoT / DoQ بر بستر TLS 1.3 / QUIC)            |    |
|    |        جلوگیری قطعی از نشت DNS و حفظ یکپارچگی Split-Horizon    |    |
|    +----------------------------------------------------------------+    |
|                                                                          |
+--------------------------------------------------------------------------+

سازوکارهای فنی RFC 9462: Discovery of Designated Resolvers (DDR)

پروتکل DDR یک سازوکار درون‌باندی (in-band discovery) است. این استاندارد به ریزالور کلاینت که در ابتدا از طریق کانال بدون رمزنگاری با سرور گیت‌وی (مانند آدرس 10.8.0.1 تخصیص‌یافته توسط VPN) تبادل می‌کند، اجازه می‌دهد بررسی کند آیا همان سرور از ارتباطات امن پشتیبانی می‌نماید یا خیر.

این فرایند بر پایه رکوردهای اتصال سرویس Service Binding (SVCB) طبق استاندارد RFC 9460 استوار است:

۱. کاوش نام دامنه با کاربرد خاص

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

  • نام پرس‌وجو (QNAME): _dns.resolver.arpa
  • نوع رکورد (QTYPE): SVCB (کد نوع ۶۴)
  • لایه انتقال: پورت پیش‌فرض ۵۳ در پروتکل UDP یا TCP

دامنه _dns.resolver.arpa یک دامنه اختصاصی طبقه‌بندی‌شده توسط IANA است. ریزالورهای بازگشتی محلی موظف هستند مستقیماً و با مرجعیت به آن پاسخ داده و از بازفروارد آن به سمت سرورهای ریشه اینترنت اکیداً خودداری نمایند.

۲. ساختار پاسخ رکورد SVCB

در صورت پشتیبانی سرور از رمزنگاری، اطلاعات مربوطه در قالب رکورد SVCB برگشت داده می‌شود:

_dns.resolver.arpa. 3600 IN SVCB 1 dns.vpnrice.internal. (
    alpn="h2,h3"
    port=443
    dohpath="/dns-query{?dns}"
    ipv4hint=10.8.0.1
)
_dns.resolver.arpa. 3600 IN SVCB 2 dns.vpnrice.internal. (
    alpn="doq"
    port=853
    ipv4hint=10.8.0.1
)

پارامترهای ارائه‌شده شامل موارد زیر است:

  • TargetName (دامنه احرازشده، ADN): دامنه کاملی که برای اعتبارسنجی هویت در دست‌تکانی TLS به کار می‌رود (dns.vpnrice.internal).
  • alpn: شناسه‌های مذاکره پروتکل در لایه کاربرد (h2 و h3 برای DoH، و dot برای DoT، و doq برای DoQ).
  • port: درگاه میزبان سرویس رمزنگاری‌شده.
  • dohpath: الگوی مسیر URI برای ارسال درخواست‌های DoH.

۳. اعتبارسنجی امنیتی و ممانعت از تنزل پروتکل

در شبکه‌های عمومی امکان دارد عامل مخربی اقدام به ارسال پاسخ‌های جعلی SVCB نماید. استاندارد RFC 9462 با الزامات اعتبارسنجی چندلایه این تهدید را خنثی می‌سازد:

۱. انطباق دقیق آدرس IP: اتصال امن TLS کلاینت الزاماً باید به همان آدرس IP هدایت شود که پرس‌وجوی اولیه به آن ارسال شده بود. اگر آدرس اولیه 10.8.0.1 بوده، دست‌تکانی TLS نیز دقیقاً روی 10.8.0.1 صورت می‌گیرد. ۲. صحت‌سنجی گواهی X.509: گواهی ارائه‌شده در اتصال TLS باید حاوی مقدار ADN در فیلد Subject Alternative Name (SAN) باشد و با مراجع مورد اعتماد سیستم‌عامل تأیید گردد. ۳. بررسی دوطرفه IPهای عمومی: برای سرورهای عمومی، تطابق آدرس در فیلد IPAddress گواهی یا همخوانی با پاسخ PTR الزامی است.

در صورت عدم تطابق، فرآیند ارتقا رد شده و انتقال ایمن از کانال‌های تاییدنشده مسدود می‌شود.

+--------------------------------------------------------------------------+
|                     ماتریس پارامترهای ارتقای پروتکل در DDR               |
+--------------------------------------------------------------------------+
| پروتکل رمزنگاری   | شناسه ALPN | پورت پیش‌فرض     | لایه انتقال          |
+--------------------+------------+------------------+----------------------+
| DNS-over-HTTPS/2   | h2         | 443              | TCP + TLS 1.3        |
| DNS-over-HTTPS/3   | h3         | 443              | UDP + QUIC (RFC 9000)|
| DNS-over-TLS       | dot        | 853              | TCP + TLS 1.3        |
| DNS-over-QUIC      | doq        | 853              | UDP + QUIC (RFC 9250)|
+--------------------------------------------------------------------------+

پروتکل RFC 9463: Discovery of Network-designated Resolvers (DNR)

در مقایسه با DDR که کشف را درون پروتکل DNS انجام می‌دهد، استاندارد RFC 9463 (DNR) یک مسیر برون‌باندی (out-of-band discovery) بر پایه پروتکل‌های پیکربندی شبکه ارائه می‌کند:

  • گزینه DHCPv4 شماره 162 (OPTION_V4_DNR)
  • گزینه DHCPv6 شماره 144 (OPTION_V6_DNR)
  • گزینه Router Advertisement در IPv6 شماره 144

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

پیکربندی عملی: فعال‌سازی DDR در نرم‌افزار Unbound

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

server:
    interface: 10.8.0.1@53       # درگاه اولیه متن ساده UDP/TCP
    interface: 10.8.0.1@853      # درگاه DNS-over-TLS (DoT)
    interface: 10.8.0.1@443      # درگاه DNS-over-HTTPS (DoH)
    
    tls-service-key: "/etc/unbound/certs/dns.key"
    tls-service-pem: "/etc/unbound/certs/dns.crt"
    tls-port: 853
    https-port: 443

    local-zone: "_dns.resolver.arpa." static
    local-data: '_dns.resolver.arpa. 3600 IN SVCB 1 dns.vpnrice.internal. alpn="h2" port="443" dohpath="/dns-query{?dns}"'
    local-data: '_dns.resolver.arpa. 3600 IN SVCB 2 dns.vpnrice.internal. alpn="dot" port="853"'

    local-zone: "vpnrice.internal." transparent
    local-data: 'dns.vpnrice.internal. 3600 IN A 10.8.0.1'

آزمایش پاسخ‌دهی سرور از سوی کلاینت:

delv @10.8.0.1 _dns.resolver.arpa SVCB

تعامل معماری با RiceGuard و خدمات VPNRice

در هسته شبکه اختصاصی RiceGuard که در VPNRice به کار گرفته شده، به‌کارگیری استانداردهای RFC 9462 و RFC 9463 مزیت‌های ساختاری چشمگیری پدید می‌آورد:

۱. پیشگیری قطعی از نشت داده‌های DNS: سیستم‌های عامل مدرن بالاترین اولویت را به کانال‌های ارتقایافته از طریق DDR می‌دهند و از ارسال تصادفی پرس‌وجوها روی رابط‌های فیزیکی ناامن جلوگیری می‌کنند. ۲. تثبیت مسیریابی دامنه‌های Split-Horizon: برخلاف سرورهای رمزنگاری عمومی، ریزالور محلی گیت‌وی دسترسی به سرویس‌های شبکه داخلی را پایدار نگه می‌دارد. ۳. پایداری ارتباط در شبکه‌های محدود: هدایت ترافیک DNS روی پورت‌های استاندارد ۴۴۳ و ۸۵۳ مانع از مسدودسازی ناشی از بستن پورت UDP 53 می‌شود.

ملاحظات اجرایی و چشم‌انداز آینده

در پیاده‌سازی سازمانی این استانداردها نکات زیر دارای اهمیت است:

  • مدیریت چرخه گواهی‌ها: گواهی ADN باید توسط مرجع معتبر صادر شود یا از طریق پروفایل‌های MDM در سازمان نصب گردد.
  • انتخاب سیاست امنیتی: فعال‌سازی حالت سخت‌گیرانه (Strict Mode) در گیت‌وی مانع از تنزل پروتکل به حالت متن ساده در صورت بروز اختلال در دست‌تکانی TLS خواهد شد.

استانداردهای RFC 9462 و RFC 9463 تحولی اساسی در معماری نام‌گذاری اینترنت پدید آورده و محرمانگی را بدون ایجاد اختلال در شبکه‌های محلی فراهم می‌کنند.