جستجو در تالارهای گفتگو

ممکن است شما هم این سوال را داشته باشید که چطور با استفاده از دامنه و آدرس سایتی که در مرورگر مینویسیم، سایت مدنظرمان در اینترنت ظاهر می‌شود؟ در پاسخ باید بدانید که اطلاعات تمامی وبسایت‌ها بر روی کامپیوترهایی قرار دارد که اصطلاحا سرور نامیده می‌شوند. در این پست قصد داریم شما را با نوعی از DNS بنام DNSSEC آشنا خواهیم کرد. به صورت کلی هر سرور دارای یک آدرس منحصر به فرد به اسم آدرس IP در شبکه اینترنت می‌باشد. برای مشاهده یک وبسایت باید آدرس IP آن را به خاطر بسپارید که کار نسبتا دشواری است. ضمن اینکه با این روش امکان نگه‌داری یک سایت بر روی هر سرور می‌باشد و یا باید به ازای هر سایت یک IP هم در نظر گرفت. به همین دلیل استفاده از دامنه‌ها برای آدرس‌دهی وبسایت‌ها استفاده می‌شود. اما پس از ثبت دامنه برای این که یک دامین بداند باید به کدام سرور اشاره کند نیاز به سرویس واسطی می‌باشد که این سرویس که DNS نامیده می‌شود و وظیفه ترجمه نام دامنه به IP را دارد. DNSSEC نوعی خاص از DNS می‌باشد که به منظور افزایش ضریب امنیت استفاده از سرویس DNS ایجاد شده است. قبل از هر چیز باید با یک مفاهیم اولیه اشنا شویم: رمزنگاری (Cryptography): Cryptography روشی برای رمزنگاری داده‌هاست. با استفاده از رمزنگاری می‌توان امنیت و/یا تایید و تصدیق داده‌ها را فراهم کرد. گاهی هدف از رمزنگاری، تنها مخفی کردن محتویات پیام‌ها نیست. برای نمونه در DNSSEC از رمزنگاری در فرآیند احراز هویت رکوردها استفاده می‌شود. روش‌های مختلفی برای رمزنگاری وجود دارند که متداول‌ترین آن‌ها، رمزنگاری کلید عمومی یا Public Key Cryptography است. در این روش از یک جفت کلید، یعنی کلید خصوصی (private key) و کلید عمومی (public key)، استفاده می‌شود. اطلاعاتی که به‌وسیله‌ی یک کلید رمزنگاری می‌شوند، تنها با جفت کلید دیگر رمزگشایی می‌شوند. به بیان بهتر اگر اطلاعاتی به‌وسیله‌ی کلید عمومی رمزنگاری شده باشند، تنها به‌وسیله‌ی کلید خصوصی رمزگشایی می‌شوند. امضای دیجیتال: در امضای دیجیتال، داده‌ها نخست به یک تابع هش داده می‌شوند. خروجی حاصل از این تابع به همراه داده‌ی اصلی به‌وسیله‌ی private key، امضا (sign) و سپس این امضا برای دریافت‌کننده‌ ارسال می‌شود. دریافت‌کننده‌ی امضا اگر public key را در اختیار داشته باشد قادر به رمزگشایی پیام و دست‌یابی به داده‌های اصلی است. حال اگر داده‌های اصلی را به تابع هش بدهد و هش خروجی با هشی که دریافت کرده یک‌سان باشد، به معنای دستکاری نشدن داده‌ها به‌وسیله‌ی یک شخص سوم و احراز هویت موفق است. DNSSEC چیست: اصطلاحات و مفاهیم پایه‌ DNSSEC که کوتاه شده عبارت Domain Name System Security Extensions می‌باشد برای این منظور طراحی شده است که درخواست‌هایی که از طریق کلاینت ارسال می‌شود در صورتی که به مقصد صحیح (سرور اصلی) رسیدند این مقصد را تایید کند و احتمال نفوذهای بین کلاینت و سرور را از بین ببرد. امروزه حملات هک و فیشینگ به عنوان یک خطر همیشگی در شبکه اینترنت وجود دارد و در زمینه سرویس‌های DNS نیز حملات DNS Spoofing انجام می‌شود که درخواست‌های ارسال شده از سمت کلاینت در خصوص یک دامنه را به سروری اشتباه که معمولا سرور هکر می‌باشد هدایت می‌کند و این امر می‌تواند خسارت‌های جبران‌ناپذیری به کاربران وارد کند. 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 ارسال می‌شوند. زمانی‌که 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 به شرح زیر است: ابتدا RRset مربوط به رکورد مورد نظر از name server درخواست می‌شود و name server در پاسخ، رکورد RRSIG مربوط به آن RRset را برای resolver ارسال می‌کند. Resolver با دریافت این امضاها برای تایید اعتبار آن‌ها نیازمند کلیدهای عمومی است. پس از name server رکورد DNSKEY حاوی public ZSK و public KSK را درخواست می‌کند و name server نیز در پاسخ، رکورد RRSIG مربوط به رکوردهای DNSKEY را ارسال می‌کند. در گام بعد resolver با استفاده از public KSK، اعتبار RRSIGهای مربوط به DNSKEY RRset را بررسی می‌کند. اگر 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 باشد. مدیریت DNS با قابلیت فعالسازی DNSSEC سرویسی رایگان از پرشین هویز در پرشین هویز سرویس رایگان مدیریت رکوردهای DNS با خرید دامنه های بین‌المللی قابل ارائه است که توسط آن می‌توانید به صورت رایگان و بدون نیاز به خرید هاست بر روی دامنه‌تان رکوردهای DNS ایجاد نمایید. از قابلیت‌های این سرویس می‌توان به امکان فعالسازی DNSSEC به منظور افزایش ضریب امنیت درخواست‌ها نام برد.