زیرشبکه کلاینت EDNS (ECS) و مکان‌یابی: افشای موقعیت مکانی با RFC 7871 در DNS

برای چندین دهه، معماری سنتی سامانه نام دامنه (Domain Name System - DNS) لایه‌ای ناخواسته اما کارآمد از حریم خصوصی را برای کاربران فراهم می‌کرد. هنگامی که یک دستگاه درخواستی برای ترجمه نام دامنه ارسال می‌نمود، این درخواست از طریق یک حل‌کننده بازگشتی میانی (Recursive Resolver)—که توسط ارائه‌دهنده خدمات اینترنت (ISP) یا خدمات عمومی DNS مدیریت می‌شد—هدایت می‌گردید. سرور معتبر نام دامنه (Authoritative Nameserver) تنها آدرس IP حل‌کننده بازگشتی را مشاهده می‌کرد و آدرس واقعی کلاینت در پشت حافظه موقت (Cache) توزیع‌شده پنهان می‌ماند.

گسترش چشمگیر شبکه‌های توزیع محتوا (Content Delivery Networks - CDNs) این تعادل را بر هم زد. زیرساخت‌های مدرن اینترنت به مسیریابی Anycast و سیستم‌های GeoDNS متکی هستند تا ترافیک کاربران را به نزدیک‌ترین گره لبه‌ای (Edge Node) از نظر جغرافیایی و فاصله شبکه هدایت نمایند. با این حال، هنگامی که کاربران حل‌کننده‌های بازگشتی متمرکز در مراکز داده دوردست را پیکربندی می‌کنند، سیستم‌های GeoDNS به اشتباه کاربر را به سرورهایی در فاصله چند هزار کیلومتری متصل می‌سازند که موجب افزایش شدید تأخیر (RTT) و افت سرعت تبادل داده می‌شود.

برای حل مشکل مسیریابی در شبکه‌های توزیع محتوا و در عین حال حفظ کارایی حافظه موقت، کارگروه مهندسی اینترنت (IETF) در مه ۲۰۱۶ استاندارد RFC 7871 را تحت عنوان «زیرشبکه کلاینت در پرس‌وجوهای سامانه نام دامنه» یا همان EDNS Client Subnet (ECS) تصویب کرد. اگرچه RFC 7871 بهینه‌سازی موثری برای ترافیک شبکه‌های ابری به ارمغان آورد، اما حفره امنیتی گسترده‌ای در زمینه حریم خصوصی ایجاد نمود. طبق این استاندارد، حل‌کننده‌های بازگشتی پیشوند زیرشبکه کاربر را مستقیماً درون بسته‌های DNS بالادستی قرار می‌دهند؛ در نتیجه موقعیت جغرافیایی کاربر برای سرورهای معتبر در سراسر جهان آشکار می‌شود—حتی اگر ترافیک با پروتکل‌های رمزگذاری نظیر DNS over HTTPS (DoH) یا DNS over TLS (DoT) محافظت شده باشد.

[معماری سنتی DNS بازگشتی: آدرس IP کلاینت پنهان است]
کلاینت (203.0.113.88) ───> حل‌کننده بازگشتی (198.51.100.1) ───> سرور معتبر نام
                               [تنها IP بازگشتی دیده می‌شود: 198.51.100.1]

────────────────────────────────────────────────────────────────────────────────────────

[معماری RFC 7871 EDNS Client Subnet (ECS): زیرشبکه کلاینت افشا می‌شود]
کلاینت (203.0.113.88) ───> حل‌کننده بازگشتی (198.51.100.1)
                                │
                                ├─ افزودن EDNS0 Option 8: پیشوند زیرشبکه 203.0.113.0/24
                                ▼
                           سرور معتبر نام دامنه (CDN / رهگیر تبلیغاتی)
                                [ثبت دامنه هدف + پیشوند شبکه خانگی 203.0.113.0/24]

ساختار فنی پروتکل RFC 7871: فیلد EDNS0 Option Code 8

برای شناخت دقیق شیوه درز اطلاعات مکانی از طریق ECS، باید ساختار داده باینری تدوین‌شده در استانداردهای RFC 6891 (EDNS0) و RFC 7871 را ارزیابی کرد.

پیام‌های استاندارد DNS در بستر پروتکل UDP دارای محدودیت اندازه ۵۱۲ بایت هستند. سند RFC 6891 سازوکارهای گسترش سامانه نام دامنه (EDNS0) را از طریق یک شبه‌رکورد تحت عنوان OPT Resource Record معرفی نمود. این رکورد به کلاینت‌ها و سرورها اجازه می‌دهد اندازه بافر را تا ۴۰۹6 بایت افزایش دهند و گزینه‌های سفارشی با اندازه متغیر را در بخش رکوردهای تکمیلی ارسال نمایند.

استاندارد RFC 7871 کد گزینه 8 (Option Code 8) را به فیلد client-subnet اختصاص داده است. هنگامی که یک حل‌کننده بازگشتی درخواستی را به سمت دامنه‌ای با قابلیت پشتیبانی از ECS ارسال می‌کند، رکورد OPT شامل چهار مؤلفه اصلی تشکیل می‌دهد:

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-------------------------------+-------------------------------+
 |          OPTION-CODE          |         OPTION-LENGTH         |
 |            (0x0008)           |           (متغیر)             |
 +-------------------------------+-------------------------------+
 |            FAMILY             |SOURCE-NETMASK | SCOPE-NETMASK |
 +-------------------------------+---------------+---------------+
 |                           ADDRESS                             |
 |                      (بایت‌های آدرس شبکه)                     |
 +---------------------------------------------------------------+

• FAMILY (۱۶ بیت): خانواده پروتکل آدرس شبکه را تعیین می‌کند (1 برای IPv4 یا 2 برای IPv6).
• SOURCE-NETMASK (۸ بیت): طول ماسک زیرشبکه کلاینت که توسط سرور بازگشتی به جلو ارسال می‌شود. برای IPv4، استاندارد RFC 7871 پیشوند /24 (پنهان‌سازی ۸ بیت پایانی) و برای IPv6 پیشوند /56 را پیشنهاد می‌نماید.
• SCOPE-NETMASK (۸ بیت): مقداری که توسط سرور معتبر در پاسخ بازگردانده می‌شود تا تعیین کند این پاسخ برای چه دامنه‌ای از زیرشبکه معتبر بوده و قابلیت نگهداری در حافظه موقت (Cache) را دارد.
• ADDRESS (اندازه متغیر): نمایش باینری کوتاه شده از آدرس شبکه کلاینت (به عنوان نمونه ۳ بایت برای پیشوند /24).

اگرچه کوتاه کردن آدرس به پیشوند /24 به عنوان راهکاری میانه برای حفظ حریم خصوصی از طریق ادغام ۲۵۶ آدرس IP مطرح شد، اما تحقیقات میدانی نشان می‌دهند که در شبکه‌های خانگی و فیبر نوری، بلوک‌های /24 دقیقاً بر محله‌های شهری، کدهای پستی خاص یا ساختمان‌های اداری منطبق هستند.

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

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

1. بی‌اثر شدن رمزنگاری مسیر اول: بسیاری از کاربران پروتکل‌های DoH یا DoT را در دستگاه‌های خود فعال می‌کنند به این تصور که کلیه ترافیک پرس‌وجوی آن‌ها غیرقابل مشاهده است. اما DoH و DoT فقط مسیر نخست میان دستگاه و حل‌کننده بازگشتی را محافظت می‌کنند. طبق طراحی RFC 7871، حل‌کننده بازگشتی درخواست را رمزگشایی کرده و سپس داده‌های حاوی ECS را بدون رمزنگاری از طریق درگاه UDP 53 به سمت سرورهای معتبر خارجی می‌فرستد.
2. جمع‌آوری داده‌های تله‌متری توسط سرورهای معتبر: سرورهای نام متعلق به شرکت‌های تبلیغاتی و تحلیل داده روزانه میلیاردها پرس‌وجو را پردازش می‌نمایند. با ثبت پیشوند ECS همراه با نام هر دامنه، این مجموعه‌ها جدول زمانی دقیقی از وب‌سایت‌های مورد استفاده در یک محله یا شرکت را در طول شبانه‌روز ترسیم می‌کنند.
3. تغذیه پایگاه‌های داده Passive DNS (pDNS): تیم‌های اطلاعات امنیت شبکه با استفاده از حسگرهای pDNS ترافیک دامنه‌ها را ثبت و ذخیره می‌کنند. ثبت فیلد ECS در کنار نام دامنه به تحلیل‌گران امکان می‌دهد سابقه فعالیت یک زیرشبکه خاص را به صورت گذشته‌نگر ردیابی کنند.

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

به دلیل تضاد ذاتی استاندارد RFC 7871 میان عملکرد مسیریابی و حفظ محرمانگی کاربران، ارائه‌دهندگان بزرگ زیرساخت راهکارهای متفاوتی را در پیش گرفته‌اند:

• Google Public DNS (8.8.8.8): برای تضمین نهایت کارایی در توزیع ترافیک، داده‌های ECS را به سرورهای معتبر همکار ارسال می‌کند، گرچه امکان ارسال درخواست با پیشوند صفر (0.0.0.0/0) را برای حذف داده‌ها فراهم ساخته است.
• OpenDNS / Cisco Umbrella: از نخستین توسعه‌دهندگان فناوری ارسال زیرشبکه کلاینت بوده و همچنان اطلاعات مکانی ECS را برای بهینه‌سازی مسیرها مخابره می‌نماید.
• Cloudflare (1.1.1.1): به طور قاطع با پیاده‌سازی RFC 7871 مخالفت کرده است. تعهدات امنیتی کلودفلر ارسال پیشوند کلاینت را متوقف ساخته و ترجیح می‌دهد اندکی افت در مسیریابی CDN را بپذیرد اما از تشکیل پرونده هویتی برای کاربران جلوگیری کند.
• Quad9 (9.9.9.9): با تکیه بر اصول بنیادین حفاظت از حریم خصوصی، فیلد ECS را از کلیه پرس‌وجوهای ارسالی به سمت سرورهای بالادستی حذف می‌کند.

خنثی‌سازی نشت اطلاعاتی ECS با کپسوله‌سازی لایه ۳ و حل‌کننده اختصاصی

غیرفعال کردن دستی ECS در برنامه‌های کاربردی کافی نیست، زیرا کلاینت‌ها قادر به وادار کردن سرورهای بازگشتی ناشناس به حذف Option Code 8 نیستند. راهکار اساسی بر پایه معماری محافظت دو لایه شکل می‌گیرد:

[رایانه کاربر / دستگاه تلفن همراه]
                │
                ├─ ارسال درخواست DNS به درگاه داخلی تونل (مانند 10.8.0.1)
                ▼
[کارت شبکه مجازی: wg0 / tun0]
   کپسوله‌سازی در لایه ۳ شبکه از طریق پروتکل WireGuard / RiceGuard
   رمزنگاری احرازهویت‌شده: الگوریتم ChaCha20-Poly1305 (کلید ۲۵۶ بیتی)
                │
                ▼
[رابط فیزیکی شبکه Wi-Fi / اینترنت اپراتور]
   تبادل بسته‌های مات UDP؛ اپراتور محلی هیچ آدرس یا پرس‌وجویی مشاهده نمی‌کند
                │
                ▼
[دروازه امن Anycast و حل‌کننده بازگشتی VPNRice]
   ۱. پالایش و حذف کامل اطلاعات زیرشبکه کلاینت (FAMILY=0, SOURCE=0)
   ۲. حل بازگشتی مستقل با تکیه بر سرورهای ریشه محلی
   ۳. سرور معتبر خارجی تنها آدرس خروجی مرکز داده VPN را مشاهده می‌نماید

هنگام بهره‌گیری از زیرساخت ارتباطی VPNRice و پروتکل مدرن RiceGuard:

• هدایت اجباری ترافیک به داخل تونل: کلیه درخواست‌های ارسالی روی درگاه‌های ۵۳، ۸۵۳ و مسیرهای DoH توسط دیواره آتش متوقف شده و مستقیماً به حل‌کننده داخلی تونل هدایت می‌شوند. اپراتور محلی هیچ دسترسی به داده‌های نام دامنه ندارد.
• حذف قطعی گزینه‌های ECS: سرورهای بازگشتی VPNRice فیلد زیرشبکه RFC 7871 را حذف می‌نمایند. در صورت درخواست سرورهای معتبر خارجی برای دریافت پارامترهای ECS، مقدار FAMILY=0 و SOURCE-NETMASK=0 ارسال می‌گردد.
• تثبیت نشانی خروجی Anycast: سرورهای معتبر تنها نشانی خروجی Anycast مرکز داده VPNRice را ثبت می‌کنند؛ در نتیجه فرآیند GeoDNS نزدیک‌ترین سرورهای CDN به نقطه خروج VPN را انتخاب کرده و از افشای محل سکونت کاربر جلوگیری به عمل می‌آید.

دستورالعمل‌های کاربردی برای پایش و مهار درز اطلاعاتی ECS

مدیران سیستم و کارشناسان امنیت می‌توانند وضعیت نشت زیرشبکه را با استفاده از دستورات خط فرمان بررسی کنند:

# ۱. ارزیابی ارسال پیشوند زیرشبکه کلاینت توسط حل‌کننده به سرور گوگل
dig +subnet=0.0.0.0/0 TXT o-o.myaddr.l.google.com @8.8.8.8 +short

# ۲. رصد وجود گزینه Option Code 8 در بسته‌های دریافتی با ابزار Wireshark / tshark
# فیلتر جستجوی بسته در Wireshark: dns.edns0.opt.code == 8

# ۳. مسدودسازی ارسال فیلد ECS در فایل تنظیمات سرویس Unbound (unbound.conf):
# server:
#     send-client-subnet: no
#     max-udp-size: 1232

# ۴. غیرفعال‌سازی ارسال زیرشبکه در تنظیمات نرم‌افزار BIND 9 (named.conf):
# options {
#     ecs-server no;
#     ecs-client no;
# };

• انتخاب حل‌کننده‌های بدون ارسال ECS: در مواقع عدم دسترسی به تونل شبکه، دستگاه را بر روی سرویس‌هایی نظیر Quad9 یا Cloudflare تنظیم نمایید.
• فعال نگه‌داشتن همیشگی تونل شبکه: از ارتباطات پایدار بر بستر پروتکل‌های WireGuard یا RiceGuard استفاده کنید تا فرآیند حل نام درون محیط ایزوله Anycast و بدون ثبت لاگ انجام پذیرد.
• پایش رابط‌های شبکه دوگانه Dual-Stack: رابط‌های IPv6 را به گونه‌ای مسدود سازید که پیشوندهای آدرس /56 یا /64 ناشی از فرآیند SLAAC به شبکه‌های عمومی نشت پیدا نکنند.