در مقاله ی قبل در رابطه با عملکرد DNS، تهدیدات و مشکلاتی که بر سر راه آن وجود داشت، به طور مفصل بحث گردید. در انتها آن چه راه نجات DNS برای در امان ماندن از تهدیدات امنیتی معرفی شد، پروتکلی با نام DNSSEC بود.
قبل از پرداختن به مفاهیم و اصطلاحات DNSSEC، شاید بد نباشد که ابتدا مروری بر مفاهیم Cryptography (رمزنگاری) داشته باشیم.
رمزنگاری (Cryptography):
Cryptography روشی برای رمزگذاری یا تولید hash برای محتویات است. با استفاده از رمزنگاری می توان امنیت و/یا قابل تایید و تصدیق بودن را برای اطلاعاتی که میخواهیم، فراهم آوریم. گاهی اوقات هدف از رمزنگاری تنها مخفی کردن محتویات پیام ها نیست. به عنوان مثال در DNSSEC هدف از رمزنگاری، تایید و تصدیق اطلاعات می باشد.
روش های مختلفی برای رمزنگاری وجود دارد که متداولترین این روش ها، رمزنگاری کلید عمومی یا Public Key Cryptography می باشد. با استفاده از این روش هم امنیت و هم تصدیق اعتبار را می توان از طریق encryption، signature و یا هردو، فراهم آورد.
برای encryption معمولا از یک جفت کلید که یکی اصطلاحا private و دیگری public خطاب می شود، استفاده می گردد. اطلاعاتی که توسط یک کلید encrypt شوند، تنها توسط جفت کلید دیگر قابل decrypt شدن هستند. به عبارت بهتر اگر اطلاعاتی توسط private key رمزگذاری شده باشند، تنها توسط public key قابل دست یابی خواهند بود و بالعکس.
منظور از signature تولید یک امضای دیجیتال با استفاده از مقدار hash به دست آمده از تابع hash ای است که اطلاعات به آن داده شده، به علاوه ی Private key (یا public key) می باشد. نحوه ی اعتبارسنجی یک امضای دیجیتال به این طریق است که: بعد از دریافت یک پیام (یا هرنوع داده ای) به همراه امضای دیجیتال، ابتدا امضا decrypt می گردد (از طریق public key). پس از decrypt امضا، آنچه به دست می آید یک مقدار hash است. گیرنده، پیام دریافت کرده را به یک تابع hash میدهد تا یک مقدار hash به دست آید. اگر مقدار hash به دست آمده توسط تابع hash در سمت گیرنده با مقدار hash دریافت شده (مقدار hash ای که پس از decrypt امضا به دست آمده)، یکسان باشد به این معنی است که داده ها درست بوده و تایید اعتبار می شوند.
DNSSEC: اصطلاحات و مفاهیم پایه
DNSSEC با افزودن یک امضای دیجیتال به رکوردهای DNS موجود، یک دامنه ی نام امن ایجاد می کند. این امضاهای دیجیتال یا اصطلاحا digital signature ها همانند سایر رکورد type های رایج چون: A یا AAAA یا CNAME، در سرورهای DNS ذخیره می شوند. با بررسی امضای اختصاص یافته به یک رکورد می توان مطمئن شد که رکورد DNS دریافت شده، از جانب یک DNS سرور مجاز است و یا رکوردی جعلی است که از طریق حمله ی man-in-the-middle تزریق شده است.
DNSSEC برای انجام عملکرد خود، RR های جدیدی را تعریف می کند. این رکوردها توسط ابزارهای signing تولید می شوند و مقادیر آن ها مستقیما قابل تغییر و ویرایش نمی باشند. اما درک ارتباط و کاری که هر کدام از این رکوردهای جدید انجام می دهند، در هنگام رخ دادن مشکل می توانند، کمک کننده باشند. این رکوردها عبارتند از:
1- RRset (Resource Record Set):
مجموعه ای از رکوردهایی با type، name و class یکسان. به عنوان مثال تمام رکوردهای NS برای یک نام.
2- RRSIG (Resource Record Signature):
امضای دیجیتال یک RRSet که name/class/type آن RRSet را به اشتراک می گذارد.
3- DNSKEY:
یک اصطلاح کلی که حاوی یک Public Key بوده و در دو role دسته بندی می شود: KSK و ZSK.
4- KSK (Key Signing Key):
وظیفه ی آن sign کردن مجموعه ای از رکوردهای DNKKEY داخل یک zone می باشد.
5- ZSK (Zone Signing Key):
وظیفه ی آن sign کردن سایر رکوردهای غیر از DNSKEY record ها در یک zone می باشد.
6- DS:
دربردارنده ی hash یک رکورد DNSKEY است. در واقع DS record ها، اشاره گرها یا اصطلاحا pointer هایی برای ایجاد زنجیره ای از اعتبارسنجی محسوب می شوند (این امر در ادامه شرح داده خواهد شد).
7- NSEC & NSEC3:
به منظور بررسی رکوردهایی که در DNS سرور وجود ندارند، از این رکوردها استفاده می شود. به عنوان مثال اگر در مرورگر خود آدرس www.example.com را وارد نماییم و مرورگر درخواستی مبنی بر دسترسی به این سایت را برای recursive resolver ارسال کند و در جواب، recursive resolver پیغامی مبنی بر عدم وجود این سایت برای مرورگر ارسال نماید، مرورگر ازکجا تشخیص دهد که این پاسخ از جانب یک مهاجم نیست؟ یا از کجا تشخیص دهد که برای www.example.com واقعا هیچ A رکورد یا AAAA رکوردی وجود ندارد؟ برای پاسخ به این مشکلات از NSEC و NSEC3 استفاده می شود.
8- CDNSKEY:
از این رکورد به منظور درخواست آپدیت برای DS رکورد(ها) توسط یک child zone از parent zone استفاده می شود.
DNSSEC: عملکرد
اولین گام در امن سازی یک zone، قرار دادن record هایی با type یکسان داخل یک RRset می باشد. به عنوان مثال اگر داخل یک zone چهار NS record وجود داشته باشد، همه ی آن ها داخل یک RRset قرار می گیرند.
به جای آن که DNS record ها به صورت جداگانه sign شوند، RRset ای که به آن تعلق دارند، sign می شود. به این ترتیب، زمان درخواست اعتبار یک رکورد، در واقع کل رکوردهای مشابه آن رکورد که داخل RRset قرار دارند نیز باید تایید اعتبار شوند (به جای تایید اعتبار یک رکورد، RRset ای که رکورد به آن تعلق دارد تایید اعتبار می شود).
Zone signing Key (ZSK):
در DNSSEC به ازای هر zone یک جفت کلید وجود دارد:
بخش private کلید، برای امضای RRset های داخل zone استفاده می شود و بخش public آن به منظور تایید این امضاها مورد استفاده قرار می گیرد.
هنگام فعال سازی DNSSEC، اپراتور به ازای هر RRset ای داخل یک zone، با استفاده از private ZSK، یک امضای دیجیتال ایجاد کرده و آن ها را به عنوان RRSIG record ها در name server خود ذخیره می کند.
این رکوردهای RRSIGN تا زمانی که DNS سرور راهی برای تایید آن ها نداشته باشد، غیر قابل استفاده هستند. پس اپراتور باید public ZSK مربوط به آن ها را نیز در اختیار داشته باشد. بنابراین این public ZSK ها را داخل DNSKEY record ها در DNS سرور ذخیره می کند.
زمانی که resolver درخواست یک record type خاص را می دهد، name server برای آن، RRSIG مربوط به آن رکورد را ارسال می کند. سپس برای به دست آوردن public ZSK، از name server درخواست DNSKEY record را می نماید. نهایتا مجموع RRset، RRSIG و DNSKEY record ها با هم یک پاسخ معتبر را تشکیل می دهند.
اگر public ZSK موجود در یک DNSKEY record تایید شود، تمام رکوردهای داخل آن zone تایید می شوند. بنابراین نیاز به راهی برای تایید اعتبار public ZSK خواهیم داشت.
Key Signing Key (KSK):
وظیفه ی KSK، امن کردن DNSKEY record هاست و این عمل را دقیقا همانند روشی که ZSK برای امن کردن سایر رکوردهای یک zone به کار می برد، انجام می دهد. به بیان بهتر KSK، وظیفه ی sign کردن public ZSK هایی که در DNSKEY record ها ذخیره می شوند و ایجاد RRSIG record برای آن ها را دارد.
مشابه ZSK در KSK نیز دو جفت کلید خواهیم داشت: private KSK و public KSK. باز هم مشابه آن چه برای ZSK شرح داده شد، public KSK ها نیز درون DNSKEY رکوردها ذخیره می شوند.
همانند سایر رکورد type ها، DNSKEY record ها نیز در یک RRset قرار می گیرند. این DNSKEY رکوردها، هم شامل public ZSK ها می شوند و هم public KSK ها. حال RRset مربوط به DNSKEY record ها توسط private KSK امضا یا sign شده و درون یک RRSIG record ذخیره می شود. Resolver از public KSK به منظور تایید اعتبار public ZSK استفاده می کند.
پس به صورت خلاصه مراحل تایید اعتبار یک رکورد برای یک resolver به این شرح است که:
1- ابتدا RRset مربوط به رکورد مورد نظر از name server درخواست می شود و name server در پاسخ، RRSIG record مربوط به آن RRset را برای resolver ارسال می کند.
2- در گام بعد resolver درخواست DNSKEY record ها که حاوی public ZSK و public KSK هستند، برای name server ارسال می کند و name server نیز در پاسخ، RRSIG record مربوط به DNSKEY record ها را برای resolver ارسال می نماید.
3- در گام بعد resolver با استفاده از public KSK، اعتبار RRSIG های مربوط به DNSKEY RRset را بررسی می کند.
4- در صورت معتبر بودن DNSKEY RRset، در واقع اعتبار Public ZSK تایید می شود و به این ترتیب resolver با استفاده از public ZSK، اعتبار RRSIG مربوط به RRset درخواست شده را بررسی می کند.
اما چگونه resolver قادر خواهد بود که RRSIG record (یا در واقع امضای دیجیتال) مربوط به DNSKEY record ها را تایید اعتبار کند؟ به عبارت بهتر، resolver چگونه قادر خواهد بود تا اعتبار public KSK را تصدیق نماید؟
در واقع آن چه تا به اینجا بررسی گردید، نحوه ی ایجاد trust در یک zone بود اما DNS دارای ساختاری سلسله مراتبی است و اغلب به ندرت پیش می آید که یک zone به طور مستقل عمل کند.
راهکار DNSSEC برای ایجاد trust بین Child zone ها و parent zone های مربوط به آن ها، استفاده از DS record می باشد. در واقع DNS با استفاده از DS record ها، Public KSK ها را تایید اعتبار می کند. بدون وجود DS record ها، DNS resolver ها باید میلیون ها Public Key را ذخیره کنند!
Delegation Signer Records:
هر زمان که resolver قصد ارجاع به یک child zone را داشته باشد، از جانب parent zone مربوط به آن child zone، یک DS record دریافت خواهد کرد. این DS record برای resolver مشخص کننده ی آن است که برای child zone مورد درخواست، DNSSEC فعال شده است.
resolver برای آن که بتواند اعتبار Public KSK های مربوط به child zone را مورد بررسی قرار دهد، DNSKEY record دریافت کرده از جانب child zone که حاوی Public KSK هاست را hash کرده و هش به دست آمده را با DS record ای که از parent zone دریافت کرده، مقایسه می کند (همانطور که در بالا نیز شرح داده شد، DS record حاوی hash مربوط به public KSK هاست). اگر این دو مقدار با هم یکسان باشند، به این معنی است که Public KSK ها معتبر هستند و تمام رکوردهای child-zone تایید اعتبار می شوند. به این ترتیب DNSSEC زنجیره ای از اعتماد را در دامنه ی DNS فراهم می آورد.
از آن جایی که KSK و DS record کاملا به هم وابسته می باشند، هر تغییری در KSK نیازمند تغییر در DS رکورد parent zone می باشد. تغییر DS record در parent zone یک فرآیند چند مرحله ای است که اگر ناقص یا به درستی انجام نشود، ممکن است سبب تفکیک یک zone گردد. به همین سبب تغییر ZSK بسیار آسان تر از KSK است.
تا به اینجا نحوه ی برقراری ارتباط و حصول اطمینان از معتبر بودن رکوردها در یک zone و مابین یک child zone و parent zone را مورد بررسی قرار دادیم. اما چطور می توان اطمینان حاصل کرد که DS record ارسالی از جانب parent zone معتبر می باشد؟
DS record نیز همانند سایر RRset ها sign شده و دارای RRSIG record می باشد. تمامی مراحل اعتبارسنجی تا زمانی که Public KSK از parent دریافت شود، تکرار خواهد شد. پس به بیان بهتر برای اعتبارسنجی یک رکورد، یک زنجیره از ارتباطات با سطوح بالاتر برقرار می شود. نهایتا آخرین سطح اعتبارسنجی در این زنجیره، بررسی DS record مربوط به root DNS server می باشد. اما مشکلی که دراینجا وجود دارد آن است که هیچ parent DS record ای برای root DNS server به منظور انجام این اعتبارسنجی وجود ندارد، چراکه root DNS server ها هیچ parent یا سطح بالاتری ندارند.
برای حل این مشکل، نشستی تحت عنوان Root Signing (یا Root Signing Ceremony) به منظور sign کردن DNSKEY RRset مربوط به root DNS Server ها، توسط ICANN برگزار می شود. در طی این مراسم RRSIG record ای تولید می شود که با استفاده از آن public KSK و ZSK مربوط به root name server را می توان اعتبارسنجی نمود.
نکته ی حائز اهمیت آن است که در هر مرحله ای در طی این اعتبارسنجی زنجیره وار، اعتبار کلیدی تایید نشود، این زنجیره شکسته و کل عمل اعتبارسنجی با شکست مواجه خواهد شد و به این ترتیب از بروز حملات man-in-the-middle جلوگیری می شود.
آنچه در این مقاله شرح داده شد توضیح ساده و مختصری از عملکرد DNSSEC بود. برای آشنایی بیشتر با جزییات این پروتکل، مطالعه ی RFC 4033 پیشنهاد می گردد.
