DNSSEC

مقدمه

معرفی سامانه‌ی نام دامنه (DNS)

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

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

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

معرفی افزونه‌ی امن سامانه‌ی نام دامنه (DNSSEC)

تعریفش؟

سیستم نام دامنه (DNS) موقعی طراحی شده که اینترنت یه جای دوستانه و قابل اعتمادی بوده. پروتکل به خودی خودش محافظت کمی در برابر پاسخ‌های مخرب یا جعلی به کوئری‌ها، میکنه -یا حتی میتونیم بگیم محافظتی نمیکنه :)-. افزونه‌های امنیتی DNS (همون DNSSEC) در واقع، با اضافه کردن امضاهای دیجیتالی به داده‌های DNS، این نیاز به امن شدن رو تا حدودی، برطرف میکنن؛ بنابراین میشه هر پاسخ DNS رو از نظر یکپارچگی -یکی از اصلهای امنیته (یعنی پیام در حین انتقال تغییر نکرده)- تأیید کرد و همچنین از نظر صحت -اینم یه اصل دیگس (یعنی داده ها توسط منبع واقعی ایجاد و فرستاده شدن، نه از طریق هکری چیزی)-. در دنیای ایده آل وقتی DNSSEC به طور کامل مستقر بشه، هر پاسخ DNS قابل تأیید و اعتماده.

ساختارش؟

ولی دنیا ایده آل نیس:)) DNSSEC یک تونل کاملا امن رو ایجاد نمیکنه. داده‌های DNS رو رمزگذاری یا مخفی نمیکنه و حتی به طور مستقل از زیرساخت‌های کلید عمومی موجود (PKI) کار میکنه. به گواهینامه های SSL یا کلید مخفی مشترک احتیاج نداره. ولی با در نظر گرفتن backwards compatibility طراحی شده و میتونه بدون تأثیر بر dns "قدیمیِ" نا امن استفاده بشه.

چجوری کار میکنه؟

در سه مولفه اصلی زیرساخت DNS مستقر شده:

• سرور Recursive:

افراد(Clients) از سرورهای بازگشتی(Recursive) برای جستجوی نام دامنه های خارجی مانند www.example.com استفاده میکنن.

اپراتورهای سرورهای بازگشتی باید اعتبارسنجی DNSSEC رو فعال کنن. با فعال کردن validation، سرورهای بازگشتی یه سری تسک‌های اضافی روی هر پاسخ DNS که دریافت میکنن انجام میدن، تا از صحتش اطمینان حاصل بکنن.

• سرور Authoritative:

اپراتورهای سرورهای بازگشتی(Recursive) و TLDها از سرورهای معتبر(Authoritative) برای ریزالو دامنه‌هایی که پابلیش میکنن، استفاده میکنن.

اپراتورهای معتبری که داده‌های DNS رو بر روی dns سرورهاشون منتشر میکنن، باید داده‌هایی که انتشار میدن رو امضا کنن. این مستلزم ایجاد رکورد resourceهای اضافی، و انتشارشون در دامنه‌های والد در صورت لزومه. با فعال کردن DNSSEC، سرورهای Authoritative علاوه بر پاسخ‌های استانداردی که تا الان ارایه میدادن، به درخواست داده‌های DNS با اطلاعات اضافی مانند امضاها و کلیدهای دیجیتالی پاسخ میدن.

• اپلیکیشن:

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

چی به dns اضافه میکنه؟

شش نوع رکورد جدید معرفی میکنه:

• RRSIG (digital signature)

با فعال کردن DNSSEC ، تقریباً در هر جواب DNS (A ، PTR ، MX ، SOA ، DNSKEY و غیره) حداقل یک امضای RRSIG یا رکورد منبع وجود داره. این امضاها توسط سرورهای dns بازگشتی که به عنوان resolverهای معتبر شناخته میشن، برای تأیید پاسخ های دریافت شده استفاده میشه.

• DNSKEY (public key)

برای صحت داده‌ها DNSSEC به رمزنگاری کلید عمومی متکیه. چندین کلید در DNSSEC وجود داره، برخی خصوصی، برخی عمومی. کلیدهای عمومی به عنوان بخشی از داده‌های zone در جهان منتشر میشن و در نوع رکورد DNSKEY ذخیره میشن. به طور کلی، دو دسته کلید در DNSSEC وجود داره، از کلید Zone Signing (ZSK) برای محافظت از تمام داده های zone و از Key Signing Key (KSK) برای محافظت از کلیدهای دیگر استفاده میشه.

• DS (parent-child)

یکی از مولفه های مهم DNSSEC اینه که zone والد میتونه برای zone فرزند خود "ضمانت" کنه. رکورد DS اطلاعات قابل تأیید (تولید شده از یکی از کلیدهای عمومی یه فرزند)ه که zone والد در مورد فرزند خود به عنوان بخشی از زنجیره اعتماد منتشر میکنه.

• NSEC (proof of nonexistence)
• NSEC3 (proof of nonexistence)
• NSEC3PARAM (proof of nonexistence)

رکورد منابع NSEC ، NSEC3 و NSEC3PARAM با یک مسئله بسیار جالب روبرو هستن: اثبات اینکه همچین چیزی واقعاً وجود نداره.

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

چجوری جستجوی DNS رو تغییر میده؟

جستجوی DNS قدیمی (ناامن) ساده اس:

مثلا فرض کنیم که یه dns سرور بازگشتی از کلاینت درخواست رو میگیره تا نام www.isc.org رو جستجو کنه. dns سرور بازگشتی سرور(های) authoritative مسئول رو ردیابی میکنه، درخواست رو به یکی از dns سرورهای authoritative میفرسته و منتظر میمونه تا dns سرور authoritative مربوطه پاسخ بده.

توو جستجوی DNS امن:

با فعال کردن اعتبار سنجی DNSSEC، یک dns سرور (شناخته شده یا یک validating resolver) رکوردهای اضافی رو در جستجوی خود درخواست خواهد کرد، به این امید که dns سرورهای authoritative که remoteان بیش از پاسخ به سوالش بهش پاسخ بدن. در صورت دریافت پاسخ های DNSSEC در واقع، validating resolver محاسبات رمزنگاری رو برای تأیید صحت (مبدا داده درست باشه) و یکپارچگی (داده ها در حین انتقال تغییر نکرده باشه) پاسخ ها انجام میده، و حتی به zone والد به عنوان بخشی از تأییدش درخواست میده. این فرایند

get-key, validate, ask-parent, parent, and its parent, and its parent 

رو تکرار میکنه، تا زمانی که validating resolver به کلید مورد اعتماد برسه. در دنیای ایده آل که DNSSEC پیاده شده تووش، تمام validating resolver فقط باید به یک کلید اعتماد کنن: اونم کلید rootه.

نکته ریزه: زنجیره اعتماد چیه؟ هیچ zone اصلی برای root وجود نداره. ولی خب توو امنیت، بالاخره باید به یه کسی اعتماد کرد و در دنیای کاملاً محافظت شده DNSSEC (بعداً در مورد وضعیت ناقص فعلی صحبت میکنیم)، هر validating resolver فقط باید به یک نهاد اعتماد کنه، یعنی dns سرور root. هر validating resolver از قبل کلید root رو در فایل خودش داره. بنابراین پس از دریافت پاسخ، جواب دریافت شده رو اعتبار سنجی میکنه و با کلیدی که در فایلش داره مقایسه میکنه و این دو باید با هم مطابقت داشته باشن. اگر همه resolverها این مراحل رو انجام بدن یعنی که ما میتونیم به پاسخ root اعتماد کنیم، بنابراین میتونیم به .org اعتماد کنیم و بنابراین میتونیم به isc.org اعتماد کنیم. این به عنوان "زنجیره اعتماد" در DNSSEC شناخته میشه.

چرا DNSSEC مهمه؟

برخی از دلایلی که ممکنه مجابمون کنه DNSSEC رو در نظر بگیریم:

1. یه وب سایت خوب باشیم: با فعال کردن اعتبار سنجی DNSSEC بر روی سرورهای DNSمون، با بررسی پاسخ هایی که بهمون برمیگرده، از کاربران و سرورهای خودمون بیشتر محافظت میکنیم. با امضای zoneمون، این امکان رو برای افرادی که مرتبطن هم فراهم میکنیم تا داده های zone خودشون رو تأیید کنن. هرچی افراد بیشتری DNSSEC رو ساپورت کنن اینترنت به طور کلی برای همه امن تر میشه.
2. امنیت پیشرفته (C.Y.A.): در صورت نقض امنیت مبتنی بر DNS، مانند cache poisoning یا domain hijacking، بعد از تمام خسارت های مالی و تجاری که به نام دامنه مون وارد شده، ممکنه زیر نظر هم گرفته بشیم به خاطر هر اقدام پیشگیرانه ای که میتونستیم اجرا کنیم و نکردیم:( . مثه این میمونه که وب سایتمون فقط از طریق HTTP در دسترس باشه اما نه از طریق HTTPS.
3. ویژگی های جدید: DNSSEC نه تنها امنیت رو افزایش میده، بلکه علاوه بر اون سطح امنیتی جدید، مجموعه ای کاملا جدید از ویژگی ها هم اضافه میکنه. به خاطر اعتماد کامل به DNS، امکان انتشار گواهینامه های SSL در DNS یا کلیدهای PGP برای رمزگذاری کاملاً خودکار ایمیل از طریق پلت فرم SSH هم وجود داره.

بررسی اجمالی EDNS

پاسخ های DNS قدیمی معمولاً اندازه کوچکی دارن (کمتر از 512 بایت) و خیلی خوشگل توو پکت UDP کوچک قرار میگیرن. سازوکار Extension برای DNS (EDNS یا EDNS (0)) مکانیزمیه که امکان برای ارسال داده های DNS در بسته های بزرگتر از طریق UDP رو به ما میده. برای پشتیبانی از EDNS، سرور DNS و شبکه باید آماده بشن تا از اندازه پکت بزرگتر و چندین قطعه پشتیبانی کنن.

این برای DNSSEC مهمه، زیرا بیت +do سیگنال DNSSEC-awareness رو در EDNS حمل میکنه، و پاسخ های DNSSEC بزرگتر از پاسخ های نرمال DNS در حالت معمولیه. اگر سرورهای DNS و محیط شبکه نتونن از بسته های بزرگ UDP پشتیبانی کنن، این امر باعث انتقال مجدد آن از طریق TCP میشه یا پاسخ های بزرگتر UDP کنار گذاشته میشن. کاربران احتمالاً DNS کندی رو تجربه کنن و یا به طور کلی قادر به resolve کردن بعضی نام های خاص نیستن.