رفتن به محتوای اصلی
توضیح کوهستانزیرساخت اینترنتتوضیح فنی۸ شهریور ۱۴۰۵، ۸:۴۴· 5 دقیقه مطالعه· در راهنماها

سازوکار سیستم نام دامنه: چگونه سلسله مراتب، کشینگ و DNSSEC اینترنت را ایمن می‌کنند

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

به قلم شیرین کریمی

مدیران شبکه 35%حامیان حریم خصوصی 35%ارائه‌دهندگان زیرساخت 30%
مدیران شبکه
تمرکز بر بار عملیاتی و پیچیدگی مدیریت چرخه‌های کلید DNSSEC و فایل‌های منطقه (Zone Files).
حامیان حریم خصوصی
استدلال می‌کنند که DNSSEC احراز هویت را فراهم می‌کند اما در ارائه محرمانگی شکست می‌خورد و بر پروتکل‌های DNS رمزگذاری‌شده تأکید دارند.
ارائه‌دهندگان زیرساخت
اولویت‌بندی کارایی کشینگ، کاهش تأخیر (Latency) و مدیریت هزینه‌های پهنای باند امضاهای رمزنگاری‌شده بزرگ.

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

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

این فرآیند جستجو یک کوئری پایگاه داده واحد نیست. بلکه یک سیستم واگذاری سلسله مراتبی و سخت‌گیرانه است. تفکیک‌کننده ابتدا یکی از سرورهای ریشه منطقی اینترنت را جستجو می‌کند. این سرورها آدرس IP نهایی را نمی‌دانند، اما می‌دانند کدام سرورها دامنه سطح بالا (TLD) مانند «.com» یا «.org» را مدیریت می‌کنند.

سپس سرور TLD، تفکیک‌کننده را به سرور نام معتبر (Authoritative Nameserver) برای دامنه خاص هدایت می‌کند. این سرور نهایی رکورد واقعی آدرس IP را در اختیار دارد. این سفر چند مرحله‌ای در میلی‌ثانیه‌ها اتفاق می‌افتد، اما تکرار آن برای هر تصویر، اسکریپت و بارگذاری صفحه، زیرساخت جهانی اینترنت را فلج خواهد کرد.

فرآیند تفکیک سلسله مراتبی در صورتی که یک رکورد به صورت محلی کش نشده باشد، نیازمند چندین مرحله است.

برای حل این مشکل تأخیر، اینترنت به شدت به کشینگ DNS متکی است. کشینگ به طور موقت نتایج جستجوی DNS را نزدیک‌تر به کاربر ذخیره می‌کند—اغلب در سیستم عامل خود کاربر، روتر خانگی او یا سرورهای محلی ارائه‌دهنده خدمات اینترنت (ISP).[4]

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

مدت زمانی که یک رکورد در کش باقی می‌ماند توسط مقدار «زمان زندگی» (TTL) آن تعیین می‌شود که توسط مالک دامنه تنظیم شده است. TTL کوتاه تضمین می‌کند که اگر وب‌سایتی به سرور جدیدی منتقل شود، مسیرهای ترافیک جهانی به سرعت به‌روز می‌شوند. TTL طولانی تأخیر جستجو را کاهش می‌دهد، اما به این معنی است که انتشار تغییرات در سطح جهانی زمان بیشتری می‌برد.[4]

کشینگ، آدرس‌های IP را نزدیک‌تر به کاربر ذخیره می‌کند تا تأخیر ناشی از جستجوهای مکرر جهانی را حذف کند.
مدت زمانی که یک رکورد در کش باقی می‌ماند توسط مقدار «زمان زندگی» (TTL) آن تعیین می‌شود که توسط مالک دامنه تنظیم شده است.

با این حال، این سازوکار کشینگ یک آسیب‌پذیری امنیتی جدی ایجاد می‌کند. از لحاظ تاریخی، DNS برای محیطی با اعتماد بالا طراحی شده بود. هنگامی که یک تفکیک‌کننده آدرس IP را درخواست می‌کرد، اولین پاسخی را که دریافت می‌کرد کورکورانه می‌پذیرفت. بازیگران مخرب از این موضوع سوءاستفاده کردند و تفکیک‌کننده‌ها را با آدرس‌های IP جعلی پر کردند—تکنیکی که به عنوان مسمومیت کش (Cache Poisoning) یا جعل DNS شناخته می‌شود.[1][4]

اگر یک مهاجم با موفقیت کش ISP را مسموم کند، هر کاربری در آن شبکه که سعی در دسترسی به یک سایت بانکی یا ایمیل قانونی دارد، بی‌صدا به یک سرور جعلی هدایت می‌شود. از آنجا که URL در مرورگر صحیح باقی می‌ماند، کاربر تقریباً هیچ نشانه بصری از ربوده شدن ترافیک خود ندارد.[4]

برای رفع این آسیب‌پذیری، کارگروه مهندسی اینترنت (IETF) افزونه‌های امنیتی سیستم نام دامنه (DNSSEC) را توسعه داد. DNSSEC درخواست‌های DNS را رمزگذاری نمی‌کند، اما امضاهای رمزنگاری‌شده را به خود رکوردهای DNS اضافه می‌کند.[1]

هنگامی که DNSSEC فعال می‌شود، سرور نام معتبر، رکوردهای آدرس IP خود را با استفاده از یک کلید رمزنگاری خصوصی امضا می‌کند. سپس کلید عمومی مربوطه را در یک رکورد ویژه DNSKEY، در کنار امضا در یک رکورد RRSIG، منتشر می‌نماید.[2]

هنگامی که یک تفکیک‌کننده تأییدکننده آدرس IP را دریافت می‌کند، از کلید عمومی برای تأیید امضا استفاده می‌کند. اگر امضا مطابقت داشته باشد، تفکیک‌کننده می‌داند که آدرس IP معتبر است و در طول مسیر دستکاری نشده است. اگر امضا ناموفق باشد یا در جایی که انتظار می‌رود وجود نداشته باشد، تفکیک‌کننده اتصال را مسدود می‌کند و کاربر را از کش مسموم محافظت می‌نماید.[1][2]

این تأیید بر یک «زنجیره اعتماد» متکی است. کلید عمومی دامنه توسط سرور TLD امضا می‌شود و کلید سرور TLD توسط سرور ریشه امضا می‌شود. این زنجیره رمزنگاری ناگسستنی تضمین می‌کند که پارامترهای امنیتی یک دامنه را می‌توان تا منطقه ریشه اینترنت تأیید کرد.[1]

DNSSEC به یک زنجیره اعتماد رمزنگاری‌شده متکی است که از منطقه ریشه اینترنت سرچشمه می‌گیرد.

پیاده‌سازی DNSSEC نیازمند انتخاب دقیق الگوریتم برای ایجاد تعادل بین امنیت و عملکرد است. پیاده‌سازی‌های مدرن در حال فاصله گرفتن از استانداردهای رمزنگاری قدیمی‌تر به سمت الگوریتم‌های قوی‌تری مانند ECDSA و EdDSA هستند که امنیت قوی را با اندازه‌های امضای کوچک‌تر ارائه می‌دهند و پهنای باند مورد نیاز برای پاسخ‌های DNS را کاهش می‌دهند.[3]

با وجود قدرت DNSSEC، این یک راه‌حل کامل نیست. تحلیل ما از معماری این پروتکل، یک آسیب‌پذیری پایدار «مایل آخر» را نشان می‌دهد. در حالی که DNSSEC زنجیره را از سرور ریشه تا تفکیک‌کننده تأییدکننده ایمن می‌کند، اتصال نهایی بین آن تفکیک‌کننده و دستگاه شخصی کاربر اغلب احراز هویت نشده باقی می‌ماند.[5]

سخت‌افزار شبکه محلی اغلب بخش نهایی و رمزگذاری‌نشده یک درخواست DNS را مدیریت می‌کند.

اگر مهاجمی شبکه محلی—مانند یک هات‌اسپات وای‌فای عمومی—را به خطر اندازد، همچنان می‌تواند پاسخ نهایی DNS را که پس از تأیید اعتبار به لپ‌تاپ یا تلفن کاربر ارسال می‌شود، رهگیری و تغییر دهد. برای ایمن‌سازی کامل این مسیر، DNSSEC باید با پروتکل‌هایی مانند DNS over HTTPS (DoH) یا DNS over TLS (DoT) جفت شود که اتصال مایل آخر را رمزگذاری می‌کنند.[5]

نکات کلیدی

  • DNS نام‌های دامنه قابل خواندن توسط انسان را به آدرس‌های IP عددی تبدیل می‌کند که کامپیوترها برای مسیریابی ترافیک از آن‌ها استفاده می‌کنند.
  • برای جلوگیری از کندی شدید اینترنت، DNS به شدت به کشینگ محلی برای ذخیره نتایج جستجوهای اخیر متکی است.
  • کشینگ DNS ناامن در برابر مسمومیت آسیب‌پذیر است و به مهاجمان اجازه می‌دهد کاربران را بی‌صدا به سایت‌های جعلی هدایت کنند.
  • DNSSEC این مشکل را با افزودن امضاهای رمزنگاری‌شده به رکوردهای DNS حل می‌کند و یک زنجیره اعتماد قابل تأیید ایجاد می‌نماید.
  • DNSSEC داده‌ها را احراز هویت می‌کند اما آن‌ها را رمزگذاری نمی‌کند؛ برای حفظ حریم خصوصی، پروتکل‌هایی مانند DNS over HTTPS مورد نیاز است.

بررسی عمیق دیدگاه‌ها

مدیران شبکه

تمرکز بر بار عملیاتی و پیچیدگی مدیریت DNSSEC.

برای مهندسانی که زیرساخت اینترنت را نگهداری می‌کنند، DNSSEC شمشیری دو لبه است. در حالی که زیرساخت را ایمن می‌کند، شکنندگی عملیاتی قابل توجهی را به وجود می‌آورد. کلیدهای رمزنگاری باید به طور منظم چرخانده شوند (Key Rollovers)، و یک خطای پیکربندی می‌تواند باعث شود یک دامنه به طور کامل از اینترنت ناپدید شود، زیرا تفکیک‌کننده‌های تأییدکننده امضاهای نادرست را رد خواهند کرد. مدیران باید این نیاز امنیتی سخت‌گیرانه را در برابر خطر قطعی‌های خودتحمیلی متعادل کنند.

حامیان حریم خصوصی

استدلال می‌کنند که DNSSEC احراز هویت را حل می‌کند اما محرمانگی کاربر را نادیده می‌گیرد.

متخصصان فناوری متمرکز بر حریم خصوصی اشاره می‌کنند که DNSSEC برای جلوگیری از ربودن ترافیک طراحی شده است، نه نظارت. از آنجا که رکوردهای DNSSEC به صورت متن ساده (plaintext) منتقل می‌شوند، ارائه‌دهندگان خدمات اینترنت، دولت‌ها و اپراتورهای شبکه محلی همچنان می‌توانند دقیقاً نظارت کنند که کاربر از کدام وب‌سایت‌ها بازدید می‌کند. این گروه استدلال می‌کند که در حالی که DNSSEC برای یکپارچگی زیرساخت ضروری است، حفاظت واقعی از کاربر مستلزم رمزگذاری خود درخواست‌ها با استفاده از پروتکل‌هایی مانند DNS over HTTPS (DoH) یا DNS over TLS (DoT) است.

ارائه‌دهندگان زیرساخت

اولویت‌بندی کارایی کشینگ و مدیریت هزینه‌های پهنای باند امضاهای رمزنگاری‌شده.

شرکت‌هایی که شبکه‌های جهانی عظیمی را اداره می‌کنند، مانند شبکه‌های تحویل محتوا (CDNs)، DNS را از منظر تأخیر و پهنای باند بررسی می‌کنند. افزودن امضاهای DNSSEC (رکوردهای RRSIG و DNSKEY) به طور قابل توجهی اندازه پاسخ‌های DNS را افزایش می‌دهد. این نه تنها پهنای باند بیشتری مصرف می‌کند، بلکه خطر حملات تقویت DNS (DNS Amplification Attacks) را نیز افزایش می‌دهد، جایی که مهاجمان از اندازه‌های بزرگ پاسخ برای غلبه بر شبکه‌های هدف استفاده می‌کنند. ارائه‌دهندگان از الگوریتم‌های رمزنگاری مدرن و سبک مانند ECDSA برای کاهش این افزایش حجم حمایت می‌کنند.

چرا مهم است

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

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

آیا DNSSEC سابقه مرور من را پنهان می‌کند؟

خیر. DNSSEC فقط امضاهای رمزنگاری‌شده را اضافه می‌کند تا تأیید کند آدرس IP که دریافت می‌کنید معتبر است. خود درخواست را رمزگذاری نمی‌کند، به این معنی که ارائه‌دهنده خدمات اینترنت شما همچنان می‌تواند ببیند که شما قصد بازدید از کدام وب‌سایت‌ها را دارید.

چرا ساعت‌ها طول می‌کشد تا یک به‌روزرسانی وب‌سایت نمایش داده شود؟

این به دلیل کشینگ DNS است. اگر «زمان زندگی» (TTL) دامنه روی ۲۴ ساعت تنظیم شده باشد، ارائه‌دهندگان خدمات اینترنت محلی آدرس IP قدیمی را به مدت یک روز کامل نگه می‌دارند قبل از اینکه برای به‌روزرسانی، سرور معتبر را بررسی کنند.

چگونه می‌توانم بفهمم که DNS من امن است؟

می‌توانید سیستم عامل یا مرورگر خود را طوری تنظیم کنید که از یک تفکیک‌کننده عمومی تأییدکننده (مانند ۱.۱.۱.۱ کلودفلر یا ۸.۸.۸.۸ گوگل) استفاده کند و DNS over HTTPS (DoH) را در تنظیمات مرورگر خود فعال کنید تا اتصال نهایی رمزگذاری شود.

منابع

پوشش منابع

5 منبع

3 دیدگاه شناسایی‌شده

مدیران شبکه 35%حامیان حریم خصوصی 35%ارائه‌دهندگان زیرساخت 30%
  1. [1]IETFمدیران شبکه

    DNS Security Introduction and Requirements

    مطالعه در IETF
  2. [2]IETFمدیران شبکه

    Resource Records for the DNS Security Extensions

    مطالعه در IETF
  3. [3]IETFمدیران شبکه

    Algorithm Implementation Requirements and Usage Guidance for DNSSEC

    مطالعه در IETF
  4. [4]Akamaiارائه‌دهندگان زیرساخت

    What Is DNS Caching?

    مطالعه در Akamai
  5. [5]تیم سردبیری کوهستانحامیان حریم خصوصی

    تحلیل تیم سردبیری کوهستان

    مطالعه در تیم سردبیری کوهستان

نظرات

همیشه در جریان باشید

هر زاویه. هر روز.

دریافت راهنماها اخبار همراه با پوشش کامل منابع و تحلیل دیدگاه‌ها، مستقیم در صندوق ورودی شما.