DNSSEC چیست؛ نحوه کار آن در ۷ مرحله

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

DNSSEC چیست؟

برای درک برنامه های افزودنی امنیتی سیستم نام دامنه (DNSSEC)، به داشتن درک اولیه از سیستم نام دامنه (DNS) نیاز است. عملکرد صحیح اینترنت به شدت به DNS وابسته است. پس از خرید دامنه، در هر صفحه وب بازدید شده، هر ایمیل ارسال شده، هر تصویر بازیابی شده از یک رسانه اجتماعی همه و همه این تعاملات، از DNS برای ترجمه نام های دامنه انسان پسند (مانند icann.org) به آدرس های IP (مانند 192.0.43.7 و 2001) استفاده می‌کنند. dns مورد نیاز سرورها، روترها و سایر دستگاه های شبکه برای هدایت ترافیک در سراسر اینترنت به مقصد مناسب است.

استفاده از اینترنت در هر دستگاهی با DNS شروع می‌شود. به عنوان مثال، زمانی را در نظر بگیرید که کاربر نام یک وب سایت را در مرورگر گوشی خود وارد می‌کند. مرورگر از سیستم حل کننده نام، که بخشی از سیستم عامل دستگاه است، برای شروع فرآیند ترجمه نام دامنه وب سایت به آدرس پروتکل اینترنت (IP) استفاده می‌کند. حل کننده یک سرویس گیرنده DNS بسیار ساده است که درخواست یک برنامه کاربردی برای داده های DNS را به یک کلاینت DNS پیچیده تر به نام Recursive Relay ارسال می‌کند. بسیاری از اپراتورهای شبکه، حل‌کننده‌های بازگشتی را برای رسیدگی به درخواست‌های DNS، یا پرس‌وجوهایی که توسط دستگاه‌های موجود در شبکه‌شان ارسال می‌شود، اجرا می‌کنند. (اپراتورها و سازمان‌های کوچک‌تر گاهی اوقات از حل‌کننده‌های بازگشتی در شبکه‌های دیگر، از جمله حل‌کننده‌های بازگشتی که به عنوان یک سرویس برای عموم استفاده می‌شوند، مانند Google Public DNS، OpenDNS و Quad9 استفاده می‌کنند.)

DNSSEC دو ویژگی مهم را به پروتکل DNS اضافه می‌کند:

1- احراز هویت مبدا داده

احراز هویت مبدا داده به یک حل‌کننده اجازه می‌دهد تا به صورت رمزنگاری تأیید کند که داده‌های دریافتی واقعاً از منطقه‌ای آمده است که معتقد است داده‌ها از آنجا منشأ گرفته‌اند.

2- حفاظت از یکپارچگی داده

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

هر منطقه کلید عمومی‌خود را منتشر می‌کند، که یک حل کننده بازگشتی آن را برای اعتبارسنجی داده‌ها در منطقه بازیابی می‌کند. اما چگونه یک حل‌کننده می‌تواند از معتبر بودن کلید عمومی‌منطقه اطمینان حاصل کند؟ کلید عمومی‌یک منطقه، درست مانند سایر داده های موجود در منطقه، امضا شده است. با این حال، کلید عمومی‌توسط کلید خصوصی منطقه امضا نمی‌شود، بلکه توسط کلید خصوصی منطقه والد امضا می‌شود. به عنوان مثال، کلید عمومی‌منطقه icann.org توسط منطقه org امضا شده است. همانطور که والد یک منطقه DNS مسئول انتشار لیست سرورهای نام معتبر یک منطقه فرزند است، والد یک منطقه نیز مسئول تضمین صحت کلید عمومی‌منطقه فرزند خود هستند. کلید عمومی‌هر منطقه توسط منطقه والد آن امضا می‌شود، به جز منطقه ریشه که هیچ والدی برای امضای کلید خود ندارد.

DNSSEC چگونه باعث افزایش امنیت می‌شود؟

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

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

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

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

افزونه های امنیتی DNS  (DNSSEC)

مهندسان در گروه ضربت مهندسی اینترنت (IETF)، سازمانی که مسئول استانداردهای پروتکل DNS است، مدت‌ها متوجه شده‌اند که عدم احراز هویت قوی‌تر در DNS یک مشکل است. کار بر روی یک راه حل در دهه 1990 آغاز شد و نتیجه آن DNSSEC Security Extensions (DNSSEC) بود.

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

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

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

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

آشنایی با نحوه کار آن

مرحله 1

اولین قدم در راه اندازی یک سیستم DNSSEC این است که تمام رکوردهای منبع (RR) را در یک مجموعه یا RRset گروه بندی کنید. RRset همه رکوردهای یک نوع و برچسب را در یک بسته واحد جمع می‌کند که بعداً می‌تواند امضا شود. به جای امضای هر رکورد به صورت جداگانه، تمام رکوردهای AAAA را می‌توان با هم و همچنین هر نوع رکورد دیگری که در منطقه DNS استفاده می‌شود امضا کرد. این گروه‌بندی ترافیک مورد نیاز برای تأیید و اعتماد هر رکورد را تا حد زیادی کاهش می‌دهد، زیرا داده‌های رمزنگاری فقط باید یک بار برای همه رکوردهای یکسان کشیده شوند.

مرحله 2

هنگامی‌که مجموعه‌های RR ایجاد شدند، سرورهای DNS معتبر در منطقه، هر مجموعه RR را با یک جفت کلید علامت‌گذاری منطقه (ZSK) امضا می‌کنند. ساختار این کلید به شکلی مشابه ارتباطات SSL نامتقارن است، جایی که یک جفت کلید خصوصی و عمومی‌وجود دارد. در این مورد، مجموعه‌های RR با بخش خصوصی کلید علامت‌گذاری منطقه امضا می‌شوند، در حالی که بخش عمومی‌بعداً برای تأیید امضا استفاده می‌شود. به عنوان بخشی از DNSSEC، هنگامی‌که هر مجموعه RR با کلید عمومی‌امضا می‌شود، امضای حاصل در یک رکورد منبع جداگانه به نام رکورد RRSIG ذخیره می‌شود.

مرحله 3

نقش کلید امضای کلید (KSK) اعتبارسنجی ZSK و ارائه ابزاری برای اطمینان از اعتماد از طریق کل سیستم DNSSEC است. KSK به همان روشی که ZSK مجموعه های RR را تأیید می‌کند، ZSK را تأیید می‌کند. یعنی KSK بخش عمومی‌ZSK را امضا می‌کند (که همانطور که قبلاً گفته شد به عنوان یک رکورد DNSKEY ذخیره می‌شود) و با انجام این کار یک رکورد RRSIG اضافی ایجاد می‌کند که برای تأیید رکورد DNSKEY ZSK استفاده می‌شود.

مرحله 4

بخش عمومی‌کلید امضای کلید خود در یک رکورد DNSKEY دیگر ذخیره می‌شود که همراه با رکورد DNSKEY برای ZSK یک مجموعه RR از رکوردهای DNSKEY را تشکیل می‌دهد. با تکمیل این فرآیند، می‌توانیم مطمئن باشیم که کل منطقه امن است و اعتماد ایجاد شده است. اگر DNS فقط به عنوان یک منطقه وجود داشته باشد، خوب است، اما البته اینطور نیست. DNS سلسله مراتبی است و اعتماد به یک منطقه این است که چیزی در مورد مناطق فرزند یا والدین آن نگوییم. علاوه بر این، اگرچه ما توانسته ایم اعتماد را در داخل منطقه ایجاد کنیم، اما اعتمادی به منطقه ایجاد نکرده ایم. می‌توانید به این فکر کنید که انگار در حال تلاش برای خواندن کتابی در مورد فیل هستید. تا کنون تأیید کرده‌ایم که همه چیزهایی که در کتاب نوشته شده درست و واقعی است، اما هنوز مشخص نکرده‌ایم که آیا خود کتاب درباره فیل‌ها یا کرگدن‌ها یا فیزیک ذرات است.

مرحله 5

اکنون که مطمئن شدیم رکوردهای بازگردانده شده توسط یک منطقه معتبر هستند، به روشی برای اعتبارسنجی خود منطقه نیاز داریم. برای انجام این کار DNSSEC به سادگی زنجیره ساختار سلسله مراتبی DNS را ایجاد می‌کند و اعتماد را از طریق والدین منتقل می‌کند. به عبارت دیگر، اگر می‌توانید به منطقه والد اعتماد کنید، می‌توانید به مناطق فرزند نیز اعتماد کنید. برای انجام این کار، هر زمان که یک منطقه فرزند تنظیم شود، یک نسخه هش شده از کلید امضای کلید عمومی‌منطقه (KSK) به منطقه والد داده می‌شود تا به عنوان یک نوع رکورد جدید به نام رکورد Delegation Signer (DS) منتشر شود. نحوه کار به این صورت است که هر بار که به یک حل کننده گفته می‌شود با یک منطقه فرزند تماس بگیرد، منطقه والد یک رکورد DS را به حل کننده ارائه می‌دهد. این کار نه تنها به حل کننده می‌گوید که منطقه فرزند از DNSSEC پشتیبانی می‌کند (DNSSEC به دور از همه جا حاضر است)، بلکه راهی برای اعتبارسنجی و اعتماد به منطقه فرزند نیز ارائه می‌دهد. تنها کاری که DNS Resolver باید انجام دهد این است که KSK عمومی‌منطقه فرزند را هش کرده و آن را با رکورد DS ارائه شده توسط والدین مقایسه کند. اگر سوابق با هم مطابقت داشته باشند، می‌توان به حل‌کننده اطمینان داد که با سرور DNS مجاز منطقه فرزند صحبت می‌کند. همچنین به حل‌کننده می‌گوید که KSK فرزند دستکاری نشده است و می‌توان به تمام رکوردهای منطقه فرزند اعتماد کرد.

مرحله 6

سوال بعدی این است، بنابراین اکنون می‌توانیم به منطقه فرزند اعتماد کنیم، اما چگونه می‌توانیم اعتماد منطقه والد و رکورد DS آن را ایجاد کنیم. اینجا جایی است که زنجیره Trust و Private root-signing key وارد عمل می‌شوند. مانند هر رکورد دیگری در سیستم DNSSEC، رکورد DS بخشی از یک مجموعه RR است که یک RRSIG امضا شده در والد دارد. کل فرآیند اعتبار سنجی RRset مانند قبل تکرار می‌شود تا زمانی که به KSK عمومی‌والد برسیم. برای تأیید آن، باید به رکورد DS والد (پدربزرگ و مادربزرگ؟) نگاه کنیم، و تأیید کنیم که ما به سادگی به دنبال یافتن زنجیره و اعتبارسنجی والد والد والد هستیم تا زمانی که به منطقه DNS ریشه در آنجا برسیم. دیگر پدر و مادری نیستند که سابقه DS را برای تأیید ارائه کنند. (منطقه DNS ریشه یک خوشه مدیریت شده از سرورها است که توسط 13 مقام نامگذاری شده توسط IANA اداره می‌شود). اگرچه این ممکن است بسیار رسمی‌به نظر برسد، اما برخی ممکن است نیاز به تأیید اعتماد با روت را بدون ابزار صحیح تأیید کنند، هیچ راهی برای اطمینان از اینکه DNS حل شده در واقع با سرورهای منطقه DNS ریشه صحبت می‌کند وجود ندارد. بنابراین از آنجایی که هیچ منطقه دیگری برای تأیید ریشه وجود ندارد، وظیفه اعتماد از ماشین به انسان منتقل می‌شود.

مرحله 7

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

نتیجه گیری

مشابه HTTPS، DNSSEC با فعال کردن پاسخ‌های احراز هویت شده در بالای یک پروتکل ناامن، یک لایه امنیتی اضافه می‌کند. در حالی که HTTPS ترافیک را رمزگذاری می‌کند تا هیچ کس در شبکه نتواند فعالیت های اینترنتی شما را زیر و رو کند، DNSSEC صرفاً پاسخ‌ها را امضا می‌کند تا جعلیات قابل تشخیص باشد. DNSSEC راه حلی برای یک مشکل واقعی بدون نیاز به رمزگذاری ارائه می‌دهد. در صورت نیاز به اطلاعات بیشتر با کارشناسان مجرب وب‌رمز تماس حاصل نمایید.