برای سال‌های متمادی، سامانه نام دامنه (DNS) بر مبنای اصل شفافیت اداری فعالیت می‌کرد: هرگاه دستگاهی نشانی IP یک میزبان را درخواست می‌کرد، تفکیک‌کننده بازگشتی (Recursive Resolver) نشانی کامل مقصد را به تمام کارگزاران معتبر در طول زنجیره تفکیک ارسال می‌نمود. هرچند این طراحی در سال‌های اولیه اینترنت ساختار نرم‌افزار را ساده می‌کرد، اما نقص ساختاری مهمی در حوزه حریم خصوصی ایجاد کرد که الگوهای ارتباطی کاربران را برای ناظران بالادستی نمایان می‌ساخت.

حتی زمانی که ارتباط میان کلاینت و تفکیک‌کننده با استفاده از پروتکل‌های رمزنگاری‌شده نظیر DNS-over-HTTPS (DoH) یا DNS-over-TLS (DoT) محافظت می‌شود، تفکیک‌کننده بازگشتی همچنان باید سلسله‌مراتب عمومی اینترنت را برای یافتن دامنه‌های ناشناخته جستجو کند. بدون اعمال کنترل‌های داده‌ای، این پرس‌وجوهای متوالی نام دقیق میزبان‌ها را برای کارگزاران ریشه (Root Server)، مراجع ثبت دامنه‌های سطح بالا (TLD) و شبکه‌های ترانزیت ارسال می‌کنند.

کارگروه مهندسی اینترنت (IETF) این چالش را ابتدا در سند RFC 7816 و سپس در استاندارد تکمیلی RFC 9156 با عنوان DNS Query Name Minimisation to Improve Privacy برطرف نمود. این سازوکار با پیاده‌سازی اصل حداقل دسترسی در لایه بسته‌های DNS، تضمین می‌کند که مراجع بالادستی تنها برچسب‌هایی از دامنه را دریافت کنند که برای ارجاع و تفویض اختیار ضروری است.

[تفکیک سنتی: ارسال نام کامل دامنه به مراجع بالادستی]
Client ──> Recursive Resolver ──[QNAME: secure.corp.example.com]──> Root Server (.)
                              ──[QNAME: secure.corp.example.com]──> TLD Server (.com)
                              ──[QNAME: secure.corp.example.com]──> example.com Auth

[کمینه‌سازی طبق RFC 9156: ارسال محدود برچسب‌های لازم]
Client ──> Recursive Resolver ──[QNAME: com (Type: NS)]───────────> Root Server (.)
                              ──[QNAME: example.com (Type: NS)]───> TLD Server (.com)
                              ──[QNAME: secure.corp.example.com]──> example.com Auth

چالش حریم خصوصی در سامانه نام دامنه: افشای گسترده داده در تفکیک نام

اسناد پایه‌ای RFC 1034 و RFC 1035 از تفکیک‌کننده می‌خواهند که عبارت بخش Question Name (QNAME) را بدون هیچ تغییری در تمام پرس‌وجوهای خروجی درج کند. هنگامی که درخواستی برای workload.internal.cloud.example.com پردازش می‌شود، تفکیک‌کننده این رشته طولانی را مستقیما به کارگزاران ریشه بین‌المللی ([a-m].root-servers.net) ارسال می‌نماید.

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

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

در چرخه تفکیک نام بدون کمینه‌سازی، اطلاعات در هر گام به صورت غیرضروری منتشر می‌شود:

  1. کارگزاران ریشه: تفکیک‌کننده نام کامل و بدون نقص دامنه (FQDN) را برای مراجع ریشه ارسال می‌کند. ناحیه ریشه تنها رکورد تفویض اختیار (NS و رکوردهای پیوند A/AAAA) را برای پسوند .com برمی‌گرداند.
  2. کارگزاران TLD: تفکیک‌کننده همان نام کامل را به کارگزاران ثبت دامنه .com ارسال می‌نماید. پاسخ این مراجع نیز صرفا معرفی کارگزاران example.com است.
  3. کارگزاران معتبر میانی: در صورتی که دامنه مقصد دارای زیردامنه‌های تفویض‌شده بیشتری باشد، کارگزاران میانی نیز پیش از ارجاع به لایه‌های پایین‌تر، نام کامل میزبان نهایی را دریافت می‌کنند.

هر گره در این مسیر بسیار فراتر از نیاز عملیاتی خود داده دریافت می‌نماید.

خطرات شنود غیرفعال و گردآوری فراداده توسط ارائه‌دهندگان اینترنت

ارسال کامل FQDN تهدیداتی را ایجاد می‌کند که در سند RFC 7626 (DNS Privacy Considerations) تبیین شده‌اند. ارتباطات میان تفکیک‌کننده‌ها و مراجع عمومی در اینترنت معمولا به صورت متن آشکار روی پورت 53 از طریق پروتکل UDP منتقل می‌شوند.

مراکز پایش ترافیک و ناظران در نقاط تبادل ترافیک اینترنتی (IXP) می‌توانند الگوهای مصرف کاربران را استخراج نمایند:

  • شنود ترافیک متن آشکار بالادستی: حتی زمانی که کاربر از تونل‌های رمزنگاری‌شده استفاده می‌کند، اگر تفکیک‌کننده از کمینه‌سازی QNAME پشتیبانی نکند، ناظران بالادستی مقاصد وب را از پرس‌وجوهای خروجی تفکیک‌کننده شناسایی می‌کنند.
  • تحلیل رفتار در سطح ریشه و TLD: مراجع ثبت مرکزی با جمع‌آوری جریان پرس‌وجوهای جهانی می‌توانند الگوهای استفاده از خدمات ابری و ساختار تعاملات دیجیتال سازمان‌ها را ترسیم نمایند.
  • تطبیق زمانی پرس‌وجوها: پایشگران با مقایسه زمان رسیدن بسته‌ها به کارگزاران ریشه و TLD، پیوندهای کاری میان نهادها را بدون نیاز به رمزگشایی محتوای داده‌ها استخراج می‌کنند.

معماری و سازوکار پروتکل RFC 9156 برای کمینه‌سازی نام پرسش

استاندارد RFC 9156 با تغییر نحوه تنظیم فیلد QNAME در طول فرآیند جستجو، مانع از افشای فراداده می‌شود. اصل راهنمای این استاندارد روشن است: تفکیک‌کننده هرگز نباید از کارگزار معتبر نامی را بپرسد که عمیق‌تر از ناحیه‌ای است که آن کارگزار رسما مدیریت آن را بر عهده دارد.

حذف تدریجی برچسب‌های دامنه با کشف گام‌به‌گام تفویض اختیار

هنگام تفکیک یک دامنه جدید مانند api.dev.secure.example.com، تفکیک‌کننده برچسب‌ها را از راست به چپ بررسی می‌کند:

  1. پرس‌وجوی ریشه: تفکیک‌کننده متوجه نبود داده‌های .com می‌شود و درخواستی با تنها یک برچسب می‌فرستد: QNAME=com، QTYPE=NS.
  2. پاسخ ریشه: کارگزار ریشه نشانی کارگزاران .com را برمی‌گرداند. این کارگزار هیچ اطلاعی از مقصد نهایی پیدا نمی‌کند.
  3. پرس‌وجوی TLD: تفکیک‌کننده برای دریافت اطلاعات example.com از کارگزار .com سوال می‌کند: QNAME=example.com، QTYPE=NS.
  4. پاسخ TLD: مراجع ثبت دامنه پاسخ معتبر را ارائه می‌دهند، اما از زیردامنه‌ها کاملا بی‌خبر می‌مانند.
  5. ارزیابی لایه‌های میانی: تفکیک‌کننده برای secure.example.com از کارگزار اصلی دامنه پرس‌وجو می‌کند.
  6. درخواست نهایی: تفکیک‌کننده تنها زمانی نام کامل را ارسال می‌کند که مستقیما با کارگزار نهایی متصل شده باشد: QNAME=api.dev.secure.example.com، QTYPE=A.

انتخاب نوع پرس‌وجو: استفاده از رکوردهای NS و A برای ارزیابی ساختار

انتخاب نوع رکورد (QTYPE) در گام‌های میانی اهمیت امنیتی بالایی دارد. اگر تفکیک‌کننده عبارت QNAME=example.com را با نوع QTYPE=MX یا QTYPE=TXT به ریشه بفرستد، نوع درخواست هدف کاربر (مانند تبادل ایمیل یا تنظیمات دامنه‌ای) را فاش می‌کند.

استاندارد RFC 9156 پیشنهاد می‌کند از QTYPE=A یا QTYPE=NS استفاده شود. در محیط‌های عملیاتی امروزی، استفاده از نوع A رایج‌تر است، زیرا برخی کارگزاران به پرس‌وجوهای میانی NS پاسخ‌های ناقص می‌دهند، در حالی که پرس‌وجوی نوع A بدون افشای نیت کاربر، اطلاعات لازم را استخراج می‌نماید.

مدیریت حالت‌های خاص پروتکل و ساختارهای غیرمعمول در درخت دامنه

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

پیمایش گره‌های خالی غیرپایانی و مدیریت پاسخ‌های نادرست NXDOMAIN

گره خالی غیرپایانی (Empty Non-Terminal یا ENT) به نقطه‌ای در درخت دامنه گفته می‌شود که داده مستقلی ندارد اما زیردامنه‌های فعالی در زیر آن قرار دارند. برای نمونه در دامنه portal.internal.example.com:

               example.com (قله ناحیه - شامل رکوردهای SOA و NS)
                    |
              internal.example.com (گره خالی ENT: بدون رکورد A یا TXT)
                    |
           portal.internal.example.com (گره پایانی: دارای رکورد فعال A)

بر اساس RFC 1034، درخواست برای internal.example.com باید پاسخ RCODE=0 (NOERROR) بدون بخش داده بازگرداند. با این حال برخی کارگزاران قدیمی پاسخ اشتباه RCODE=3 (NXDOMAIN) می‌دهند.

اگر تفکیک‌کننده در برچسب‌های میانی کد NXDOMAIN دریافت کند، بر اساس سند RFC 8020 فرض می‌کند زیر آن گره هیچ نشانی‌ای وجود ندارد و روند را متوقف می‌سازد. بنابراین RFC 9156 روش‌های مشخصی برای کنترل این وضعیت در نظر گرفته است.

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

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

  1. کمینه‌سازی سخت‌گیرانه (Strict Minimisation): تفکیک‌کننده تنها برچسب‌به‌برچسب پیش می‌رود. در صورت دریافت پاسخ نادرست، فرآیند متوقف می‌شود. این حالت بیشترین حفاظت را ارائه می‌دهد، اما در دامنه‌های دارای پیکربندی ناقص ممکن است اختلال ایجاد کند.
  2. کمینه‌سازی منعطف (Relaxed Minimisation): تفکیک‌کننده ابتدا گام‌به‌گام بررسی می‌کند. در صورت بروز خطای NXDOMAIN یا انقضای زمان پاسخ، سیستم به طور خودکار نام کامل را مستقیما برای همان کارگزار ارسال می‌نماید.

الگوی منعطف پایداری ارتباط را حفظ می‌کند و در عین محافظت از داده‌ها در لایه‌های Root و TLD، مانع از بروز قطعی در اتصالات می‌شود.

کارایی، تاخیر شبکه و رفتار سامانه‌های ذخیره‌سازی موقت

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

سنجش زمان رفت‌وبرگشت اولیه در مقایسه با ذخیره‌سازی منفی پیشرفته

در شرایطی که حافظه موقت (Cache) کاملا خالی است، بررسی جداگانه برچسب‌ها زمان رفت‌وبرگشت (RTT) بیشتری نیاز دارد. با این حال، در کاربری واقعی این تفاوت عملا ناچیز است.

سناریو تفکیک نام سنتی کمینه‌سازی RFC 9156 (حافظه خالی) کمینه‌سازی RFC 9156 (حافظه فعال)
درخواست‌های ارسالی به ریشه ۱ بار (افشای نام کامل) ۱ بار (پرسش رکورد NS) ۰ بار (استفاده از حافظه موقت)
درخواست‌های ارسالی به TLD ۱ بار (افشای نام کامل) ۱ بار (پرسش رکورد NS) ۰ بار (استفاده از حافظه موقت)
بررسی زیردامنه‌های میانی ۰ بار (پرسش مستقیم) ۱ تا ۲ بار (ارزیابی گام‌ها) ۰ بار (استفاده از حافظه موقت)
درخواست نهایی از مرجع اصلی ۱ بار (نام کامل) ۱ بار (نام کامل) ۱ بار (نام کامل)
کل RTT در راه‌اندازی اول ۳ چرخه ۴ تا ۵ چرخه ۱ چرخه
میزان نشت فراداده به TLD ۱۰۰٪ افشای نام میزبان بدون هیچ‌گونه افشای میزبان بدون هیچ‌گونه افشای میزبان

از آنجا که اطلاعات مراجع ریشه و TLD دارای طول عمر بالا (TTL معمولا بین ۲۴ تا ۴۸ ساعت) هستند، تفکیک‌کننده آنها را در حافظه نگهداری می‌کند. در شرایط معمول، بیش از ۹۸ درصد درخواست‌ها از حافظه پاسخ داده می‌شوند و زمان پاسخ‌دهی تنها به یک رفت‌وبرگشت به کارگزار اصلی کاهش می‌یابد.

افزون بر این، تفکیک‌کننده‌های منطبق بر استاندارد ذخیره‌سازی منفی پیشرفته (RFC 8198) با تکیه بر رکوردهای DNSSEC NSEC عدم وجود دامنه‌ها را به شکل محلی و بدون نیاز به تبادل داده با بالادست تایید می‌کنند.

پیاده‌سازی سازمانی: معماری تفکیک نام بدون ثبت گزارش در RiceGuard

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

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

[دستگاه کاربر]
      │
      │  (تونل رمزگذاری‌شده ChaCha20-Poly1305 / AES-256-GCM)
      ▼
[درگاه لبه VPNRice]
      │
      │  (ارتباط لوپ‌بک داخلی / بدون انتقال متن آشکار)
      ▼
[تفکیک‌کننده بازگشتی اختصاصی RiceGuard]
   ├── کپی محلی ناحیه ریشه بر اساس RFC 8806 (بدون ارسال درخواست به بیرون)
   ├── موتور کمینه‌سازی دقیق QNAME طبق RFC 9156
   ├── حذف خودکار پیشوند کاربری EDNS Client Subnet (ECS)
   ├── کارکرد انحصاری در حافظه رم (بدون ذخیره بر دیسک)
   └── خروجی بالادستی امن از طریق DNS-over-QUIC / DNS-over-HTTPS
  1. نسخه محلی ناحیه ریشه (RFC 8806): گره‌های RiceGuard رونوشت معتبر ریشه را در رم نگهداری می‌کنند. پرس‌وجوهای سطح ریشه در کمتر از یک میلی‌ثانیه به شکل محلی و بدون برقراری ارتباط با مراجع خارجی پاسخ داده می‌شوند.
  2. کمینه‌سازی دقیق در لایه TLD: هنگام ارتباط با مراجع دامنه بین‌المللی، سیستم برچسب‌های اضافی را حذف می‌کند تا مراجع ثبتی به جزئیات میزبان‌ها دسترسی نداشته باشند.
  3. حذف اطلاعات EDNS Client Subnet (RFC 7871): کارگزاران عمومی معمولا بخشی از نشانی IP کاربر را به مراجع بالادستی ارسال می‌نمایند. RiceGuard این قابلیت را کاملا غیرفعال می‌کند تا موقعیت کاربر قابل ردگیری نباشد.
  4. کارکرد در حافظه موقت: تمام فرآیندها روی رم ناپایدار انجام شده و با پایان نشست پاک می‌شوند که امکان هرگونه بازخوانی بعدی را از میان می‌برد.

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

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

برای آزمایش سریع، می‌توانید دامنه‌های تحقیقاتی ویژه بررسی این قابلیت را فراخوانی نمایید:

# پرس‌وجو از دامنه آزمایشی NLnet Labs جهت سنجش عملکرد QNAME
dig @127.0.0.1 qnamemintest.internet.nl TXT +short

# در صورت کارکرد صحیح، پیام زیر نمایش داده می‌شود:
# "HOORAY - QNAME minimisation is enabled"

جهت مشاهده مستقیم بسته‌های ارسالی از تفکیک‌کننده داخلی (مانند Unbound) به شبکه، می‌توان پورت 53 را با tcpdump زیر نظر گرفت:

# پایش پرس‌وجوهای خروجی DNS از تفکیک‌کننده محلی
sudo tcpdump -nn -i eth0 dst port 53 and udp -v

بسته‌های خروجی را بررسی کنید: در صورت فعال بودن استاندارد، درخواست‌های ارسال‌شده به کارگزاران ریشه تنها شامل q=com? خواهند بود و درخواست‌های TLD تنها نام دامنه اصلی (مانند q=example.com?) را نمایش می‌دهند که نشان‌دهنده حفظ نام میزبان درون محدوده امن تفکیک‌کننده است.

دریافت VPNRice.