DNSSEC چیست و چگونه عمل می‌کند؟ - حلقه ارتباطی ابر آروان

ابر آروان

زیرساخت یکپارچه ابری

۱۰ مهر ۱۳۹۸

DNSSEC چیست و چگونه عمل می‌کند؟

در مقاله‌ی «تاریخچه DNS : پیش‌درآمدی بر ظهور DNSSEC» در رابطه با عملکرد DNS، تهدیدات و مشکلاتی که بر سر راه آن وجود داشت، به‌طور مفصل توضیح داده شد. روشی که درنهایت برای حل مشکل امن نبودن DNS به‌وسیله‌ی جامعه‌ی اینترنت به رسمیت شناخته شد، DNSSEC نام داشت. اما پیش از پرداختن به این موضوع که DNSSEC چیست و چگونه عمل می‌کند، بهتر است نخست مروری بر مفاهیم رمزنگاری و امضای دیجیتال داشته باشیم.

 

رمزنگاری (Cryptography)

Cryptography روشی برای رمزنگاری داده‌هاست. با استفاده از رمزنگاری می‌توان امنیت و/یا تایید و تصدیق داده‌ها را فراهم کرد. گاهی هدف از رمزنگاری، تنها مخفی کردن محتویات پیام‌ها نیست. برای نمونه در DNSSEC از رمزنگاری در فرآیند احراز هویت رکوردها استفاده می‌شود.

روش‌های مختلفی برای رمزنگاری وجود دارند که متداول‌ترین آن‌ها، رمزنگاری کلید عمومی یا Public Key Cryptography  است. در این روش از یک جفت کلید، یعنی کلید خصوصی (private key) و کلید عمومی (public key)، استفاده می‌شود. اطلاعاتی که به‌وسیله‌ی یک کلید رمزنگاری می‌شوند، تنها با جفت کلید دیگر رمزگشایی می‌شوند. به بیان بهتر اگر اطلاعاتی به‌وسیله‌ی کلید عمومی رمزنگاری شده باشند، تنها به‌وسیله‌ی کلید خصوصی رمزگشایی می‌شوند.

 

امضای دیجیتال

در امضای دیجیتال، داده‌ها نخست به یک تابع هش داده می‌شوند. خروجی حاصل از این تابع به همراه داده‌ی اصلی به‌وسیله‌ی private key، امضا (sign) و سپس این امضا برای دریافت‌کننده‌ ارسال می‌شود. دریافت‌کننده‌ی امضا اگر public key را در اختیار داشته باشد قادر به رمزگشایی پیام و دست‌یابی به داده‌های اصلی است. حال اگر داده‌های اصلی را به تابع هش بدهد و هش خروجی با هشی که دریافت کرده یک‌سان باشد، به معنای دستکاری نشدن داده‌ها به‌وسیله‌ی یک شخص سوم و احراز هویت موفق است.

 

DNSSEC چیست : اصطلاحات و مفاهیم پایه

DNSSEC با امضای دیجیتال رکوردهای DNS یک دامنه، امکان احراز هویت این رکوردها و در امان بودن آن دامنه از حمله‌ی DNS spoofing را فراهم می‌کند. این امضاهای دیجیتال یا در اصطلاح digital signatureها مانند سایر انواع رکوردهای DNS (هم‌چون A،  AAAA یا CNAME) در سرورهای DNS ذخیره می‌شوند. با بررسی امضای اختصاص یافته به یک رکورد می‌توان مطمین شد که رکورد DNS دریافت شده از یک DNS سرور مجاز است، یا رکوردی جعلی است که به‌وسیله‌ی یک حمله‌ی man-in-the-middle تزریق شده است.

DNSSEC برای انجام عملکرد خود، RRهای جدیدی را تعریف می‌کند که مهم‌ترین آن‌ها عبارت‌اند از:

  • RRset
    رکوردهایی با نام، نوع و class یک‌سان درون یک RRset قرار می‌گیرند. برای نمونه تمام رکوردهای NS موجود برای یک دامنه داخل یک RRset قرار می‌گیرند.
  • RRSIG
    دربردارنده‌ی امضای دیجیتال یک RRset
  • DNSKEY
    حاوی کلید عمومی مربوط بهZSK یا KSK
  • ZSK
    مسوول امضای رکوردهایی جز رکوردهای DNSKEY مرتبط با یک zone
  • KSK

مسوول امضای رکوردهای DNSKEY مرتبط با یک zone

  • DS
    دربردارنده‌ی hash رکورد DNSKEY حاوی public KSK است. از رکوردهای DS برای ایجاد زنجیره‌ای از اعتبارسنجی در ساختار سلسله مراتبی DNS استفاده می‌شود.

 

عملکرد DNSSEC

نخستین گام در امن‌سازی یک zone، قرار گرفتن رکوردهایی با نوع (type) یک‌سان داخل یک RRset است. برای نمونه اگر داخل یک zone چهار NS record وجود داشته باشد، همه‌ی آن‌ها داخل یک RRset قرار می‌گیرند.

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

 

Zone signing Key (ZSK)

در DNSSEC برای هر zone یک جفت کلید وجود دارد که به آن ZSK گفته می‌شود؛ از private ZSK، برای امضای  RRsetهای داخل zone و از public ZSK برای تایید این امضاها استفاده می‌شود.

امضای مربوط به هر RRset، درون یک رکورد RRSIG قرار می‌گیرد. دریافت‌کننده‌ی رکوردهای RRSIG (برای نمونه Recursive Resolver)، تا زمانی‌که راهی برای رمزگشایی آن‌ها نداشته باشد، نمی‌تواند به داده‌های این رکوردها دست پیدا کند. پس کلید عمومی ZSK نیز باید برای دریافت‌کننده ارسال شود. این کلیدها داخل DNSKEY recordها ذخیره و برای Recursive Resolver ارسال می‌شوند.

DNSSEC چیست؟ - ZSK

زمانی‌که recursive resolver درخواست دسترسی به یک نوع رکورد خاص را می‌دهد، name server برای آن، RRSIG مربوط به آن رکورد را ارسال می‌کند. Recursive Resolver با دریافت این رکورد از name server رکورد DNSKEY را درخواست می‌کند. مجموع RRSet ،RRSIG و رکوردهای DNSKEY با هم، یک پاسخ معتبر را تشکیل می‌دهند.

اگر public ZSK موجود در یک DNSKEY record تایید شود، تمام رکوردهای داخل آن zone تایید می‌شوند. پس نیاز به راهی برای تایید اعتبار public ZSK است.

 

Key Signing Key (KSK)

وظیفه‌ی KSK، امن کردن رکوردهای DNSKEY حاوی public ZSK است. KSK نیز مشابه ZSK یک جفت کلید است: private KSK و Public KSK. باز هم مشابه آن‌چه برای ZSK شرح داده شد، public KSKها درون رکوردهای DNSKEY ذخیره می‌شوند.

همانند انواع رکوردها، رکوردهای DNSKEY (که یا شامل public ZSK هستند یا public KSK) نیز در یک RRset قرار می‌گیرند. RRset مربوط به رکوردهای DNSSKEY به‌وسیله‌ی private KSK امضا و این امضا درون یک رکورد RRSIG ذخیره می‌شود. Recursive Resolver از public KSK برای تایید اعتبار public ZSK استفاده می‌کند.

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

  1. ابتدا RRset مربوط به رکورد مورد نظر از name server درخواست می‌شود و name server در پاسخ، رکورد RRSIG مربوط به آن RRset را برای resolver ارسال می‌کند.
  2. Resolver با دریافت این امضاها برای تایید اعتبار آن‌ها نیازمند کلیدهای عمومی است. پس از name server رکورد DNSKEY حاوی public ZSK و public KSK را درخواست می‌کند و name server نیز در پاسخ، رکورد RRSIG مربوط به رکوردهای DNSKEY را ارسال می‌کند.
  3. در گام بعد resolver با استفاده از public KSK، اعتبار RRSIGهای مربوط به DNSKEY RRset را بررسی می‌کند.
  4. اگر DNSKEY RRset تایید اعتبار شود، در واقع اعتبار Public ZSK تایید می‌شود و به این ترتیب resolver با استفاده از public ZSK، اعتبار RRSIG مربوط به RRset درخواست شده را بررسی می‌کند.

اما چگونه resolver قادر خواهد بود که رکورد RRSIG مربوط به رکوردهای DNSKEY را تایید اعتبار کند؟ به بیان بهتر، resolver چگونه می‎تواند public KSK را اعتبارسنجی کند؟

آن‌چه تا به این‌جا بررسی شد، شیوه‌ی ایجاد trust در یک zone بود اما DNS دارای ساختاری سلسله مراتبی است و به‌ندرت پیش می‌آید که یک zone به‌شکل مستقل عمل کند.

راهکار DNSSEC برای ایجاد trust بین child zoneها و parent zoneهای مربوط به آن‌ها، استفاده از رکورد DS است. در واقع DNS با استفاده از رکوردهای DS، Public KSKها را تایید اعتبار می‌کند. بدون وجود رکوردهای DS ،DNS resolverها باید میلیون‌ها Public Key را ذخیره کنند!

 

رکورد Delegation Signer (DS)

هر زمان resolver قصد ارجاع به یک child zone را داشته باشد، از جانب parent zone مربوط به آن child zone، یک رکورد DS دریافت می‌کند. در این رکورد، hash مربوط به public KSK قرار دارد و برای resolver مشخص‌کننده‌ی آن است که برای child zone مورد درخواست، DNSSEC فعال شده است.

resolver برای آن‌که بتواند اعتبار Public KSKهای مربوط به child zone را مورد بررسی قرار دهد، رکورد DNSKEY دریافت کرده از جانب child zone که حاوی Public KSKهاست را hash کرده و آن را با محتوای رکورد DS که از parent zone دریافت کرده، مقایسه می‌کند. اگر این دو مقدار با هم یک‌سان باشند، به‌معنای معتبر بودن Public KSK است و تمام رکوردهای child-zone تایید اعتبار می‌شوند. به‌این‌ترتیب DNSSEC زنجیره‌ای از اعتماد را در دامنه‌ی DNS فراهم می‌کند.

چون KSK و DS record کاملن به هم وابسته هستند، هر تغییری در KSK نیازمند تغییر در رکورد DS مربوط به parent zone است. تغییر رکورد DS در parent zone یک فرآیند چند مرحله‌ای است که اگر ناقص یا به‌درستی انجام نشود، می‌تواند سبب تفکیک یک zone شود. به همین دلیل، تغییر ZSK بسیار آسان‌تر از KSK است.

تا به این‌جا شیوه‌ی برقراری ارتباط و اطمینان از معتبر بودن رکوردها در یک zone و مابین یک child zone و parent zone بررسی شد. اما چه‌طور می‌توان مطمین شد که DS record ارسالی از جانب parent zone معتبر است؟

رکورد DS نیز مانند سایر RRSetها امضا می‌شود و دارای RRSIG record ویژه‌ی خود است. تمامی مراحل اعتبارسنجی تا زمانی‌که Public KSK از parent دریافت شود، تکرار خواهد شد. پس به بیان بهتر، برای اعتبارسنجی یک رکورد، یک زنجیره از ارتباطات با سطوح بالاتر برقرار می‌شود. در نهایت آخرین سطح اعتبارسنجی در این زنجیره، بررسی DS record مربوط به root DNS server است. اما مشکلی که در این‌جا وجود دارد آن است که هیچ parent DS record برای root DNS server به‌منظور انجام این اعتبارسنجی وجود ندارد، چرا که DNS serverهای root هیچ parent یا سطح بالاتری ندارند.

برای حل این مشکل، نشستی تحت عنوان Root Signing  (یا Root Signing Ceremony) برای امضای DNSKEY RRset مربوط به root DNS serverها، به‌وسیله‌ی ICANN برگزار می‌شود. در این مراسم یک رکورد RRSIG تولید می‌شود که با استفاده از آن public KSK  و  public ZSK مربوط به root name server را می‌توان اعتبارسنجی کرد.

نکته‌ی مهم آن است که در هر مرحله‌ای در طول این اعتبارسنجی زنجیره‌وار، اعتبار کلیدی تایید نشود، این زنجیره شکسته و کل عمل اعتبارسنجی با شکست مواجه می‌شود. همین عامل سبب می‌شود تا DNSSEC قادر به جلوگیری از حملات Man-In-The-Middle باشد.

 

ابر آروان و DNSSEC

ابر آروان در جایگاه یک Authoritative DNS server یک رکورد DS در اختیار مشتریانی که از محصول DNS ابری آروان استفاده می‌کنند، قرار می‌دهد. بنابراین اگر registrar و TLD که مشتری دامنه‌ی خود را از آن تهیه کرده، از DNSSEC پشتیبانی کنند، ساختار سلسله مراتبی اعتبارسنجی رکوردها برای آن دامنه لحاظ و به‌این‌ترتیب آن دامنه در برابر حملات DNS spoofing امن می‌شود.

برای درک بهتر روندی که اتفاق می‌افتد، تصویر زیر را در نظر بگیرید:

DNSSEC چیست؟ - عملکرد ابر آروان

  1. کاربر در مرورگر خود نشانی example.com را وارد می‌کند. مرورگر نخست Cache خود را برای یافتن آدرس IP متناظر با آن بررسی می‌کند. اگر این IP را در Cache خود پیدا نکند، درخواستی را برای DNS server که برای آن تنظیم شده (Recursive Resolver) می‌فرستد.
  2. Recursive Resolver که می‌تواند DNS server باشد که ISP برای شما فراهم کرده است، نخست Cache خود را برای یافتن آدرس IP متناظر با آن نام جست‌وجو می‌کند. اگر آدرسی پیدا نکند، درخواستی را برای Root server می‌فرستد.
  3. Root server با دریافت این درخواست، در پاسخ، آدرس IP مربوط به TLD آن دامنه به همراه DS record مرتبط با آن را برای recursive resolver می‌فرستد.
  4. Recursive Resolver با دریافت این IP، درخواستی را مبنی‌بر دریافت آدرس IP دامنه، برای TLD می‌فرستد.
  5. TLD با دریافت این درخواست، آدرس IP مربوط به DNS serverهای ابر آروان که رکوردهای دامنه‌ی مورد نظر در آن ذخیره شده‌اند، به همراه DS record مرتبط با آن را برای Recursive Resolver می‌فرستد.
  6. Recursive Resolver برای DNS server ابر آروان درخواستی را برای دسترسی به رکوردهای دامنه‌ی موردنظر می‌فرستد.
  7. DNS server ابر آروان نیز در پاسخ برای recursive resolver، رکوردهای RRSIG  و DNSKEY را می‌فرستد.
  8. Recursive resolver که اکنون به تمام رکوردهای مورد نظر خود دست یافته و تمام سرورهای بالادستی را نیز احراز هویت کرده است، درنهایت آدرس IP دامنه‌ی example.com را برای مرورگر می‌فرستد و به‌این‌ترتیب مرورگر می‌تواند به محتوای دامنه دسترسی داشته باشد.

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

 

 

× برای اطلاع از آخرین اخبار و مقالات آروان عضو خبرنامه ما شوید