على مدى عقود طويلة، اعتمد نظام أسماء النطاقات (DNS) على نقل البيانات في صيغة نص صريح غير مشفر عبر منفذ UDP 53. وتسبب هذا الغياب للحماية في تمكين مشغلي الشبكات ومزودي نقاط اتصال Wi-Fi العامة وعقد التوجيه الوسيطة من تسجيل واستطلاع كافة أسماء النطاقات التي يحاول المستخدم الاتصال بها.
جاءت بروتوكولات 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. التحقق الأمني ومطابقة الشهادة والمصافحة | |
| | الاتصال بـ IP البوابة عبر TCP 443 / UDP 443 | |
| | SNI: dns.vpnrice.internal | |
| v التحقق من صحة شهادة X.509 عبر مستودع النظام v |
| +----------------------------------------------------------------+ |
| | نفق DNS مشفر تمت ترقيته تلقائياً | |
| | (DoH / DoT / DoQ عبر TLS 1.3 / QUIC) | |
| | حماية كاملة من التسريب والحفاظ على Split-Horizon | |
| +----------------------------------------------------------------+ |
| |
+--------------------------------------------------------------------------+
آليات عمل معيار RFC 9462: Discovery of Designated Resolvers (DDR)
يعمل معيار DDR كبروتوكول اكتشاف ضمن النطاق (in-band discovery). يتيح هذا البروتوكول للمحلل الطرفي على جهاز المستخدم، المتصل حالياً بخادم غير مشفر (مثل عنوان البوابة 10.8.0.1 الممنوح عبر نفق VPN)، الاستفسار عما إذا كان الخادم نفسه يوفر واجهات اتصال مشفرة.
تعتمد عملية الاكتشاف على سجلات ربط الخدمات Service Binding (SVCB) المحددة في معيار RFC 9460:
1. استطلاع النطاق المخصص للأغراض الخاصة
بمجرد اكتمال الربط الشبكي، يرسل العميل استعلام DNS قياسياً إلى خادمه المعين:
- اسم النطاق (QNAME):
_dns.resolver.arpa - نوع السجل (QTYPE):
SVCB(الرمز 64) - بروتوكول النقل: منفذ UDP/TCP 53 القياسي
النطاق _dns.resolver.arpa هو نطاق استخدام خاص مسجل لدى هيئة IANA. تلتزم خوادم التحليل بالإجابة عليه بسلطة مباشرة ويُحظر عليها توجيهه إلى خوادم الجذر العالمية.
2. بنية استجابة سجل 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.
3. التحقق الأمني والحماية من خفض مستوى التشفير
لمنع أي مهاجم على شبكة Wi-Fi محلية من تزوير سجلات SVCB لتوجيه البيانات نحو خوادم خبيثة، يفرض RFC 9462 قيوداً أمنية صارمة:
- مطابقة عنوان IP بدقة: يلتزم العميل بإنشاء اتصال TLS مع نفس عنوان IP الذي تلقى الاستعلام غير المشفر الأصلي. إذا كان العنوان
10.8.0.1، فيجب أن تتجه مصافحة TLS إلى10.8.0.1تحديداً. - التحقق من شهادة X.509: يجب أن تتضمن شهادة الخادم المقدمة أثناء المصافحة اسم ADN في حقل Subject Alternative Name (SAN)، وأن تكون صادرة من جهة معتمدة لدى نظام التشغيل.
- التحقق المتبادل للعناوين العامة: بالنسبة للخوادم ذات العناوين العامة، تشترط المواصفات إدراج العنوان ضمن حقل 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 Option 162 (
OPTION_V4_DNR) - خيار DHCPv6 Option 144 (
OPTION_V6_DNR) - خيار إعلانات موجه IPv6 Option 144
يتلقى الجهاز إعدادات ADN والمنافذ وعناوين الخادم المشفر لحظة حصوله على عنوان IP، مما يمكنه من تأسيس الاتصال المشفر قبل إرسال أول حزمة بيانات، ويلغي الحاجة للاستطلاع الأولي النصي.
التطبيق العملي: إعداد خادم Unbound لدعم معيار DDR
على بوابات Linux وخوادم VPN، يمكن تفعيل DDR في خادم Unbound بإضافة النطاق المخصص وربط الشهادات الرقمية:
server:
interface: 10.8.0.1@53 # واجهة التشغيل المبدئي غير المشفرة
interface: 10.8.0.1@853 # واجهة DoT
interface: 10.8.0.1@443 # واجهة 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: تمنح أنظمة التشغيل الحديثة الأولوية القصوى للقنوات المشفرة المكتشفة، مما يمنع إرسال استعلامات متوازية عبر محولات Wi-Fi المادية.
- الحفاظ على استقرار نطاقات Split-Horizon: يحل الخادم المشفر المحلي أسماء النطاقات الداخلية للمؤسسات دون انقطاع، بخلاف الخوادم العامة الخارجية.
- المرونة في البيئات الشبكية المقيدة: يتيح توجيه الاستعلامات عبر منفذي 443 و853 تجاوز قيود حظر منفذ UDP 53 بكفاءة وموثوقية.
التوصيات التشغيلية والآفاق المستقبلية
عند اعتماد هذه البروتوكولات في البيئات المؤسسية، ينبغي مراعاة:
- إدارة الشهادات الرقمية: يجب إصدار شهادة ADN من سلطة معتمدة عالمياً أو نشر شهادة المؤسسة عبر أنظمة MDM.
- سياسة الترقية: يُفضل تفعيل النمط الصارم (Strict Mode) في بوابات VPN لمنع التراجع التلقائي إلى النصوص غير المشفرة عند حدوث أي خلل أمني.
يقدم معيارا RFC 9462 وRFC 9463 إطاراً عصرياً ينهي حقبة الاستعلامات المكشوفة، ويجمع بين أمان النقل ومرونة إدارة الشبكات.



