DNS چیست و چرا باید از آن استفاده کنیم؟

احتمالاً تابه‌حال، بارها در هنگام باز کردن یک سایت در مرورگر خود، با مشکل مواجه شده‌اید و سایت با نمایش خطاهایی مانند خطای ۴۰۳ (403 Error) اجازه‌ی دسترسی شما را به سایت مورد نظر نمی‌دهد. این مشکل، یا به دلیل فیلترشدن این سایت از سوی سرویس ارائه‌دهنده‌ی شما رخ می‌دهد یا سایت مورد نظر، IP منطقه‌ی مکانی شما را تحریم کرده است.

در این حالت، برای دسترسی به سایت یا سرور مورد نظر، استفاده از ابزارهای تغییر IP مانند VPN ساده‌ترین راه‌حل به نظر می‌رسد؛ اما ازآنجاکه ترافیک شما از یک واسطه‌ی ناشناس رد می‌شود، حریم خصوصی و امنیت شما در این روش به خطر می‌افتد. ابزار DNS در این حالت، بهترین و امن‌ترین جایگزین برای دسترسی به سرورها و سایت‌هایی است که به دلایل مختلفی، اجازه‌ی دسترسی IP شما به صفحه‌ی مورد نظر را نمی‌دهند.

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

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

تطبیق آدرس وارد شده از سوی شما با IP ذخیره‌شده در سرور برای آن آدرس، توسط ابزاری به نام DNS انجام می‌شود. اگر برایتان این سؤال پیش آمده است که DNS مخفف چیست و چطور این کار را انجام می‌دهد، باید بگویم که کمی صبور باشید؛ به این سؤالات در بخش‌های مختلف مقاله به‌طور کامل پاسخ خواهیم داد.

در قدم اول، شاید بپرسید که DNS مخفف چیست؟ DNS مخفف عبارت Domain Name System به معنای سامانه نام دامنه است. آدرس تمام سایت‌هایی که می‌شناسید، در فضایی به نام شبکه یا DNS سرور ذخیره می‌شود و هر آدرس، با یک IP خاص ارتباط دارد؛ اما حفظ‌کردن انبوهی از IP-های مختلف برای دسترسی به هر آدرس، نه منطقی است و نه امکان‌پذیر.

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

اگر متوجه روند کلی کارایی DNS نشدید، با یک مثال ساده، این روند را مجدداً توضیح می‌دهیم. تصور کنید که شما می‌خواهید وارد سایت گوگل شوید و آدرس Google.com را در مرورگر خود تایپ می‌کنید. این آدرس، در سرورهای دی‌ان‌اس با IP عددی ۲۱۶.۲۳۹.۳۸.۱۲۰ در DNS ذخیره شده است.

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

گاهی اوقات، برخی کاربران به‌اشتباه تصور می‌کنند که IP و DNS، مشابه یا حتی یکسان هستند؛ درصورتی‌که چنین نیست. IP (مخفف Internet Protocol) یک رشته اعدادی محسوب می‌شود که در قالب چهار عدد با تعداد ارقام متفاوت تعیین می‌شود و برای هر آدرس دامنه یا نام سرور، منحصربه‌فرد است. به‌طور مثال، IP گوگل (۲۱۶.۲۳۹.۳۸.۱۲۰) از چهار عدد ۱۲۰، ۳۸، ۲۳۹ و ۲۱۶ تشکیل می‌شود.

هر چهار عدد IP، می‌توانند یکی از اعداد بازه‌ی ۰ تا ۲۵۵ باشد. به‌عبارت‌دیگر، کمترین IP برابر با ۰.۰.۰.۰ و بیشتری آن برابر با ۲۵۵.۲۵۵.۲۵۵.۲۵۵ است. انتخاب IP به‌صورت تصادفی انجام نمی‌شود و سازمانی به نام IANA (مرجع واگذاری اعداد در اینترنت) این اعداد را به‌صورت اختصاصی برای هر سایت یا سرور خاص تعیین می‌کند.

از آنجا که IP هر سایت یا سرور، به‌صورت منحصربه‌فرد و صرفاً مخصوص به همان سایت یا سرور است، با میلیون‌ها IP مختلف در اینترنت روبه‌رو هستیم که امکان حفظ‌کردن تمام آن‌ها، غیرممکن خواهد بود و به ابزاری نیاز داریم که کار ما را برای دسترسی به سایت دلخواهمان آسان‌تر و البته، سریع‌تر کند؛ اینجا است که تفاوت اصلی میان DNS و IP مشخص می‌شود.

DNS برخلاف IP، یک مشخصه‌ی اختصاصی برای یک سایت نیست. در واقع، این ابزار، صرفاً چند نوع مختلف دارد که بر اساس شرایط درخواست کاربر، وارد عمل می‌شوند تا آدرس واردشده از سمت کاربر را با IP آن آدرس در DNS سرور تطبیق دهند و درصورتی‌که DNS و IP کاربر، از سوی DNS سرور به‌عنوان غیرمجاز شناسایی نشوند، سایتی که مطابق IP ذخیره‌شده برای آدرس آن است، به کاربر نمایش داده شود.

یکی از حیاتی‌ترین کاربردهای DNS در کشورهایی مانند ایران که با تحریم‌های مختلف از سوی شرکت‌های کوچک و بزرگ فناوری درگیر است، دورزدن این تحریم‌ها برای دستیابی به سایت و خدمات این شرکت‌ها محسوب می‌شود.

عبارت‌هایی مانند تغییر DNS برای PS5 یا تغییر DNS برای گوگل پلی، یکی از رایج‌ترین جست‌وجوهای گوگل برای کاربران ایرانی هستند؛ درخواست‌هایی که همگی، کارایی مؤثر و غیرقابل‌ انکار DNS برای دورزدن تحریم‌های شرکت مختلف علیه کاربران ایرانی را نشان می‌دهد، اما DNS چطور این کار را انجام می‌دهد؟

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

برای کشورهای درگیر تحریم مانند ایران، این DNS-ها توسط شرکت‌هایی که از این تحریم‌ها تبعیت می‌کنند، غیرمجاز می‌شود. در این حالت، شما آدرس را در مرورگر وارد می‌کنید یا می‌خواهید به سرور بازی دلخواهتان در کنسول پلی استیشن یا کنسول ایکس باکس متصل شوید، اما ازآنجاکه DNS سرویس‌های ارائه‌دهنده‌ی اینترنت در ایران، از سوی شرکت مورد نظرتان، غیرمجاز شناخته شده است، نمی‌توانید به آن سایت یا بازی دسترسی داشته باشید.

در این حالت، با خطای کلاینت که با نام خطای ۴۰۳ نیز شناخته می‌شود، روبه‌رو خواهید شد و DNS سرور، مانع از اتصال شما به سایت یا بازی دلخواهتان می‌شود و چاره‌ای به جز تغییر DNS در ویندوز، تغییر DNS برای ایکس باکس یا استفاده از یک DNS متفاوت برای هر دستگاهی که از آن استفاده می‌کنید، نخواهید داشت.

حالا که می‌دانیم DNS چیست و تفاوت آن با IP را یاد گرفتیم، زمان آن رسیده است که به سراغ یادگیری نحوه‌ی کار DNS برویم. پیش‌ از این کار، باید با انواع سرورهای DNS نیز، آشنا شویم که در ادامه، به معرفی آن‌ها می‌پردازیم.

Recursive resolver

سرور حل‌کننده‌ی بازگشتی DNS، اولین مقصد پس از ایجاد کوئری DNS است. زمانی که شما آدرس یک سایت را در مرورگر خود تایپ می‌کنید، سرور Recursive resolver درون ISP (مخفف Internet Service Provider) یا همان سرویس ارائه‌دهنده‌ی خدمات اینترنتی شما (مثلاً اینترنت مخابرات) این کوئری یا درخواست شما را با داده‌های کش ذخیره‌شده در خود مقایسه می‌کند.

اگر قبلاً این آدرس را جست‌وجو کرده باشید، IP مرتبط با آن در حافظه کش سرور Recursive resolver ذخیره شده است و سرور با دورزدن مسیر ارتباط با سرور بعدی، در مدت‌زمان سریع‌تری به درخواست شما پاسخ می‌دهد. درصورتی‌که برای اولین‌بار این کوئری DNS به سرور Recursive resolver رسیده باشد یا اینکه سرور نتواند پاسخ مناسبی برای کوئری پیدا کند، درخواستی را برای سرور DNS root name ارسال می‌کند.

DNS root name server

برای هر سرور حل‌کننده‌ی بازگشتی، ۱۳ سرور اصلی DNS root name وجود دارد که در قالب بیش از ۶۰۰ سرور مختلف در سراسر دنیا پخش شده‌اند و توسط سازمانی به نام IANA (مخفف Internet Assigned Numbers Authority) نگهداری می‌شوند. این نوع سرور، درخواست سرور Recursive resolver را که شامل یک نام دامنه است، می‌پذیرد و به تفکیک پسوند دامنه (org. یا com. یا net. و غیره) آن‌ها را به یک سرور TLD name به نام دامنه‌ی سطح بالا هدایت می‌کند.

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

TLD name server

پس از هدایت کوئری کاربر از سمت سرور Recursive resolver به TLD name (مخفف Top Level Domain Name) این سرور باتوجه‌به پسوند دامنه‌ی کوئری به آن پاسخ می‌دهد. هر یک از سرورهای TLD name، انواع خاصی از پسوندهای دامنه را پوشش می‌دهند که به شرح زیر هستند:

• سرورهای TDL عمومی (Generic TLDs یا gTLDs): این سرورها از پسوندهای دامنه‌ی عمومی مانند com. یا net. یا پسوندهای جدید مانند club. یا shop. پشتیبانی می‌کنند.
• سرورهای TDL حمایت‌شده (Sponsored TLD): این سرورها توسط گروه‌هایی نگهداری می‌شوند که شامل جامعه‌ی خاصی از افرادی با قومیت مشترک، موقعیت جغرافیایی مشترک یا شغل مشترک هستند.
• سرورهای TDL بدون حمایت (Non-sponsored TLDs): این سرورها شامل تمام سرورهای TDL عمومی است که از سوی سازمان IANA حمایت نمی‌شوند.
• سرورهای TDL بین‌المللی (Internationalized TLDs): این سرورها برای هر زبان خاص، تفکیک شده‌اند. به‌طور مثال، سرورهای TDL انگلیسی‌زبان یا سرورهای TDL اسپانیایی‌زبان.

نحوه‌ی کارکرد سرورهای TDL name مشابه سرورهای Recursive resolver است و ابتدا هر کوئری را با استناد به اطلاعات ذخیره‌شده در حافظه‌ی کش خود، پاسخ می‌دهند. درصورتی‌که پاسخ مناسبی برای درخواست کوئری ارسال‌شده از Recursive resolver در حافظه‌ی کش نباشد، این درخواست به سرور معتبر یا Authoritative name هدایت می‌شود تا سرور، اطلاعات IP مرتبط با کوئری را پیدا کند.

Authoritative name server

هر شرکت، فرد یا گروهی که حق استفاده از یک دامنه‌ی خاص را برای مدت مشخصی خریداری می‌کند، باید این دامنه را در یک سرور معتبر ثبت کند. این کار، باعث انتشار رسمی نام آن دامنه در فضای شبکه‌ی عمومی (اینترنت) یا شبکه‌ی خصوصی و اختصاص دادن یک IP به این دامنه خواهد شد. این IP در سرورهایی با نام Authoritative name یا سرور نام معتبر ذخیره می‌شود که انتهای زنجیره‌ی پاسخگویی کوئری کاربر هستند.

پس از اینکه سرور Authoritative name، به کوئری ارسال‌شده از سوی سرور Recursive resolver پاسخ داد، اطلاعات این کوئری در حافظه‌ی کش سرور Recursive resolver ذخیره می‌شود تا در دفعات بعدی، درخواست کاربر سریع‌تر پاسخ داده شود.

هر سرور DNS برای اتصال نام دامنه به IP اختصاص‌یافته به آن، از مجموعه‌ای از دستورالعمل‌های مختلف و خاص استفاده می‌کند که با نام رکورد (Records) شناخته می‌شوند. هر رکورد شامل تعدادی فایل متنی به نام Zone files است و در کنار رکوردهای دیگر، در سرور Authoritative name نگهداری می‌شود. این فایل‌ها، علاوه بر کمک به اتصال نام دامنه به IP آن، حاوی اطلاعاتی هستند که تعداد دفعات به‌روزرسانی DNS در سرور (Time-To-Live یا TTL) را تعیین می‌کنند. در ادامه، پنج رکورد DNS اصلی را معرفی می‌کنیم و پس از آن، به سراغ سایر رکوردهای پرکاربرد DNS خواهیم رفت.

رکورد A

این رکورد به‌عنوان مهم‌ترین رکورد DNS شناخته می‌شود و نام آن، از کلمه Adress برگرفته شده است. یک رکورد A، آدرس IP یک دامنه را نشان می‌دهد و صرفاً از آدرس های IPV4 پشتیبانی می‌کند. سرورهای DNS با استفاده از یک رکورد A، آدرس IP وب سایت مورد نظر کاربر را جست‌وجو می‌کنند تا بدون نیاز به دانستن IP، کاربر به وب‌سایت دلخواهش دسترسی داشته باشد. علاوه بر این کاربرد، رکورد A برای مسدودکردن یک سایت صرفاً بر اساس نام دامنه‌ی آن نیز به کار گرفته می‌شود.

رکورد AAAA

عملکرد رکوردهای AAAA مشابه رکورد A است، با این تفاوت که به‌جای آدرس‌های IPV4 به آدرس‌های IPV6 اشاره می‌کند. IPV6، محدودیت ناشی از تمام‌شدن آدرس‌های IP در IPV4 را ندارد؛ ازاین‌رو، رکوردهای AAAA در مقایسه با رکوردهای A، پتانسیل پیشرفت بالاتری دارند.

IPV6 برخلاف آدرس‌های IPV4 که به شکل یک دنباله‌ی چهار عددی (هر عدد بین یک تا سه رقم دارد.) هستند، به‌صورت دنباله‌ای به شکل زیر نمایش داده می‌شود که ترکیبی از هشت زیر مجموعه است و هر زیر مجموعه، از چهار کاراکتر عددی یا حرف تشکیل می‌شود:

3001:0db7:3c5d:0024:0000:0000:1a2f:3c1b

رکورد CNAME

بسیاری از سایت‌ها، ممکن است علاوه بر دامنه‌ی اصلی، شامل تعدادی زیر دامنه باشند. در این حالت، نمی‌توان از زیر دامنه بلافاصله به IP دامنه‌ی اصلی رسید و باید از رکوردهای متفاوتی در این مسیر استفاده کرد. با استفاده از رکورد CNAME، یک نام دامنه‌ی مستعار به یک دامنه‌ی دیگر هدایت می‌شود. به عبارت ساده‌تر، تصور کنید شما می‌خواهید وارد دامنه‌ی ng.example.com شوید.

این دامنه، در واقع یک زیردامنه یا نام مستعار از دامنه‌ی اصلی example.com است. در این حالت، رکورد CNAME، زیردامنه‌ی ng.example.com را به دامنه‌ی اصلی example.com هدایت می‌کند و پس از آن، این دامنه با استفاده از یک رکورد A به آدرس IP مربوط به این سایت ارجاع داده می‌شود.

رکورد Nameserver یا NS

این رکورد، سرور Authoritative name را که باید برای دامنه‌ی شما عمل کند، تعیین می‌کند و به تمام رکوردهای روی دامنه‌ی شما اشاره دارد. ازآنجاکه یک دامنه معمولاً دارای چند نوع سرور Authoritative name مختلف است (به‌طور مثال ns1.examplehostingprovider.com و ns2.examplehostingprovider.com هر دو متعلق به دامنه‌ی .examplehostingprovider.com هستند.) به کمک رکورد NS می‌توان مشخص کرد که دقیقاً کدام‌یک از سرورهای Authoritative name باید پاسخگوی درخواست کاربر باشند. به عبارت ساده‌تر، بدون رکورد NS، کاربران نمی‌توانند به یک وب‌سایت دسترسی داشته باشند.

رکورد Mail exchange یا MX

این رکورد، مقصد دریافت ایمیل‌های یک دامنه را تعیین می‌کند. برای هر نام دامنه، امکان تعیین یک یا چندین رکورد MX مختلف وجود دارد که به کمک آن‌ها می‌توان سرورهای ایمیل پشتیبانی متفاوتی را ایجاد کرد. به طور مثال، رکورد @ MX 10 mx.zoho.com و @ MX 20 mx2.zoho.com از یک دامنه هستند. رکوردی که با MX 10 شروع می‌شود، سرور اصلی خواهد بود و رکورد MX 20، تنها زمانی وارد عمل می‌شود که سرور اصلی در دسترس نباشد یا به هر دلیلی، نتواند ایمیل ارسال/دریافت کند.

علاوه بر پنج رکورد بالا که اصلی‌ترین رکوردهای DNS هستند، رکوردهای دیگری نیز روی سرورهای مختلف DNS به کار می‌روند. این رکوردها عبارت‌اند از:

• رکورد DNAME: عملکرد این رکورد، مشابه رکورد CNAME است و چندین زیر دامنه را به یک دامنه دیگر هدایت می‌کند. به‌طور مثال، اگر یک رکورد DNAME که domain.com را به example.com هدایت کند، امکان هدایت زیر دامنه‌هایی مانند product.domain.com، trial.domain.com و blog.domain.com را نیز به example.com دارد.
• رکورد CAA: رکورد Certification authority authorization یا CAA نوعی رکورد است که به صاحبان دامنه‌ها اجازه می‌دهد تا شخص صادرکننده‌ی گواهی برای دامنه‌ی خود را از میان مقامات سازمان CA تعیین کند. این سازمان، هویت وب‌سایت‌ها را تعیین می‌کند و با صدور گواهی‌های دیجیتالی، وب‌سایت آن‌ها را به کلیدهای رمزنگاری متصل می‌کند.
• رکورد CERT: این نوع رکورد، گواهینامه‌های کلیدهای عمومی را ذخیره می‌کند و برای رمزگذاری اطلاعات و تأیید صلاحیت تمام افراد درگیر با سرور، کاربرد دارد.
• رکورد SOA: رکورد Start of Authority یا به اختصار SOA تمام اطلاعات مدیریت یک دامنه شامل آدرس ایمیل ادمین و همچنین، زمان آخرین به‌روزرسانی دامنه را ذخیره می‌کند.

• رکورد PTR: رکورد Pointer records یا PTR، عملکرد برعکس رکورد A را ارائه می‌کنند. این رکوردها یک آدرس IP را به نام یک دامنه وصل می‌کنند. به‌عبارت‌دیگر، با استفاده از آدرس IP می‌توانند دامنه‌ی آن را پیدا کنند. از این رکورد برای شناسایی هرزنامه‌ها در سرویس‌های مختلف استفاده می‌شود. این رکوردها باید توسط میزبان سرور تنظیم شوند.
• رکورد SPF: رکورد Sender policy framework یا SPF برای شناسایی سرورهای ایمیلی که از دامنه‌ی شما به دیگران ایمیل ارسال می‌کنند، مورد استفاده قرار می‌گیرد. این رکورد از سوءاستفاده از دامنه‌ی شما برای ارسال هرزنامه به دیگران یا رسیدن به اهداف مخرب جلوگیری می‌کنند و به دریافت‌کنندگان ایمیل اطلاع می‌دهد که این ایمیل به‌صورت مجاز از دامنه‌ی شما ارسال شده است یا نه.
• رکورد SRV: رکوردهای Service یا SVR، میزبان و پورت را برای سرویس‌های خاص (ارسال پیام، دامنه و غیره) تعیین می‌کنند.
• رکورد ALIAS: این رکورد، دامنه‌ی شما را به نام میزبان هدایت می‌کند. به‌طور مثال، اگر دامنه‌ی شما example.com است، می‌توانید با استفاده از رکورد ALIAS، این دامنه را به product.differentexample.com هدایت کنید.
• رکورد NSEC: اگر به دنبال رکوردی در سرور DNS می‌گردید و آن رکورد در سرور وجود ندارد، زمان نسبتاً قابل‌ توجهی برای تأیید نبود آن رکورد صرف می‌شود. رکورد NSEC، این روند را کوتاه‌تر می‌کند و باعث صرفه‌جویی در زمان، در هنگام جست‌وجوی رکوردهای خاص می‌شود.
• رکورد URLFWD: با استفاده از رکورد URLFWD (مخفف URL forwarding) می‌توان از طریق چند URL مختلف به یک صفحه‌ی وب رسید. به‌عبارت‌دیگر، با استفاده از این رکورد، امکان تغییر مسیر URL (URL redirecting) از سه روش دائمی، موقت یا پوشاننده (Masking) وجود دارد.
• رکورد TXT: رکورد Text برای تأیید مالکیت دامنه مورد استفاده قرار می‌گیرد و صاحب دامنه با استفاده از آن می‌تواند مقادیر متنی را در DNS ذخیره کند.
• رکورد DCHID: به کمک این رکورد، اطلاعات مربوط به پروتکل پیکربندی میزبان پویا (DHCP) ذخیره می‌شود. این پروتکل، یک پروتکل کلاینت-سرور است و به هر میزبان (Host) در شبکه، آدرس IP و سایر اطلاعات مورد نیاز را اختصاص می‌دهد تا این میزبان بتواند با نقاط پایانی (Endpoints) ارتباط مؤثری داشته باشد.

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

جست‌وجوی DNS در اغلب موارد به صورت محلی و در کامپیوتر یا کنسول کاربر انجام می‌شود؛ اما در مواردی که دامنه‌ی مورد نظر کاربر برای اولین‌بار جست‌وجو شود و هیچ اطلاعاتی از آن دامنه در حافظه کش سرورهای DNS نباشد، DNS به سرورهای سطح بالاتری مراجعه می‌کند. در این حالت، مراحل جست‌وجوی DNS در هشت مرحله و به شرح زیر پیش می‌رود:

• کاربر سایت example.com را در مرورگر خود تایپ می‌کند. با این کار، یک کوئری از سوی کاربر به اینترنت و سرور Recursive resolver ارسال می‌شود.
• کوئری کاربر از سرور Recursive resolver به سمت DNS root nameserver فرستاده می‌شود.
• سرور DNS root nameserver، باتوجه‌به پسوند دامنه‌ی کوئری، به درخواست ارسال‌شده از سرور Recursive resolver پاسخ می‌دهد و آن درخواست را به یک سرور TLD هدایت می‌کند. نوع سرور TDL بر اساس پسوند دامنه‌ی داخل کوئری، متفاوت است. به‌طور مثال، در این دامنه (example.com) به دلیل وجود پسوند com. درخواست به سمت سرور TDL.com فرستاده می‌شود.
• سرور Recursive resolver درخواستی را به سرور TLD ارسال می‌کند.
• سرور TLD با آدرس IP مرتبط با این دامنه را پیدا می‌کند و به آن پاسخ می‌دهد.
• سرور Recursive resolver یک کوئری به سرور نام دامنه (Domain’s nameserver) ارسال می‌کند.
• آدرس IP از سمت سرور Domain’s nameserver به سرور Recursive resolver فرستاده می‌شود.
• سرور Recursive resolver، دامنه‌ی درخواست‌شده از سوی کاربر را به‌همراه IP آن به مرورگر برمی‌گرداند.

پس از این مرحله، مرورگر یک درخواست HTTP برای آدرس IP دریافت‌شده می‌فرستند و سرور نیز، صفحه‌ی وب را برای آن IP اجرا می‌کند.

بخش زیادی از DNS، رمزگذاری نشده است و تمام افرادی که بین دستگاه شما و سرور Recursive Recursive قرار دارند، می‌توانند کوئری‌های DNS شما را به همراه پاسخ آن‌ها از سوی سرورهای DNS ببینند یا حتی آن‌ها را تغییر دهند. این ضعف DNS، حریم خصوصی شما را به خطر می‌اندازد و دامنه و IP سایت‌هایی را که از آن‌ها بازدید می‌کنید، در اختیار افراد دیگر قرار می‌دهد.

برای جبران این ضعف، استفاده از پروتکل‌های رمزگذاری DNS برای پنهان‌کردن کوئری‌های DNS از دید دیگران و جلوگیری از تغییر ماهیت کوئری یا پاسخ دریافتی آن، از حریم خصوصی کاربر محافظت می‌کند و ارتباطی امن و خصوصی را فراهم خواهد کرد.

دو پروتکل DNS over TLS (DoT) و DNS over HTTPS (DoH) برای رمزگذاری DNS مورد استفاده قرار می‌گیرند. این دو پروتکل، جایگزینی برای DNSCrypt هستند که هم امنیت بالاتری دارند و هم از داده‌های کاربر، بهتر محافظت می‌کنند.

DNS over TLS، کوئری ارسال‌شده از کاربر را با استفاده از پروتکل TLS و به‌صورت end-to-end رمزگذاری می‌کند. پروتکل TLS به برنامه‌های کلاینت-سرور اجازه می‌دهد که در یک شبکه که از فاقد امکان شنود و جعل پیام است، با یکدیگر ارتباط برقرار کنند. اگر DNS کاربر با پروتکل DoT رمزگذاری‌شده باشد، کوئری ارسال‌شده از کاربر به‌جای یک سرور Recursive resolver رمزگذاری‌نشده، از طریق پورت TCP 853 به سرور Recursive resolver رمزگذاری‌شده DoT هدایت می‌شود.

در این سرور، حل‌کننده (Resolver) کوئری کاربر را رمزگشایی می‌کند و آن را به سمت سرور Authoritative name ارسال خواهد کرد. پس از پردازش این کوئری و پیداکردن آدرس IP مرتبط با آن، پاسخ کوئری از طریق کانال رمزگذاری‌شده TLS به سمت کلاینت (کاربر) ارسال می‌شود و پس از رمزگشایی این پاسخ توسط پروتکل DoT، کاربر به سمت سایت یا سرویس مورد نظر هدایت می‌شود.

عملکرد پروتکل DoH تا حد زیادی با پروتکل DoT متفاوت است. در این پروتکل، زمانی که کاربر یک کوئری DNS را ارسال می‌کند، این کوئری از طریق HTTPS به سمت سرور Recursive resolver می‌رود و از پورت TCP 403 عبور خواهد کرد. این پورت، به‌دلیل عمومی بودن، کوئری کاربر را در میان تعداد بسیار زیادی کوئری گم خواهد کرد و تمایز آن را از کوئری‌های دیگر، بسیار دشوار می‌کند.

دو تفاوت اساسی میان پروتکل‌های DoT و DoH وجود دارد که در هر حالت، یکی را به دیگری برتری می‌دهد. پروتکل DoT از پورت ۸۵۳ استفاده می‌کند. این پورت، اختصاصی است و همین ویژگی، شناسایی ترافیک کاربر از این پورت و مسدودکردن آن را برای هر کسی که توانایی ردیابی شبکه را داشته باشد، افزایش می‌دهد و حریم خصوصی کاربر را عملاً بی‌معنی می‌کند. از طرفی، مسدود کردن سریع‌تر ترافیک‌های مخرب در این پروتکل، از آسیب رسیدن به سیستم کاربر جلوگیری خواهد کرد.

در مقابل، پروتکل DoH به‌دلیل استفاده از پورت ۴۰۳ که تمام ترافیک‌های HTTPS نیز از آن عبور می‌کند، کوئری کاربر و پاسخ آن را در میان ترافیک HTTPS پنهان می‌کند. این موضوع، اگرچه باعث افزایش حریم خصوصی کاربر می‌شود، از طرفی، شناسایی و مسدودکردن یک ترافیک مخرب را در این‌ بین، سخت‌تر خواهد کرد و تنها در صورتی می‌توان این کار را انجام داد که سایر ترافیک HTTPS نیز مسدود شود.

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

در این حالت، چاره‌ای به جز استفاده از DNS خصوصی برای کاربر باقی نمی‌ماند، اما Private DNS چیست و دقیقاً چطور از کاربر محافظت می‌کند؟ به زبان ساده، DNS خصوصی همان دی‌ان‌اس رمزگذاری‌شده با استفاده از پروتکل‌های DoT و DoH است. اغلب سرویس‌های معتبر ارائه‌دهنده‌ی DNS مانند کلاد فلر و گوگل، DNS-های خود را به‌صورت رمزگذاری‌شده در اختیار کاربر قرار می‌دهند و در طول ارتباط، از داده‌های ردوبدل‌شده میان کاربر و شبکه محافظت می‌کنند.

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

شاید برایتان این سؤال مطرح شود که نشتی DNS چطور رخ می‌دهد؟ به‌طورکلی، موارد زیر می‌توانند باعث نشتی DNS و خروج درخواست‌های کاربر از تونل رمزگذاری‌شده شوند:

• استفاده از یک VPN ناکارآمد و با پیکربندی نادرست: یک VPN که به درستی پیکربندی شده باشد، باید یک سرور DNS را به ISP کاربر اختصاص دهد تا کاربر پیش از ورود به VPN، به ISP خود متصل شود. درصورتی‌که این پیکربندی رعایت نشود، احتمال نشت DNS از طریق این VPN افزایش پیدا می‌کند. علاوه بر این مورد، یک سرویس VPN امن، باید دارای سرورهای DNS اختصاصی باشد تا بتواند محافظت مؤثری در مقابل نشت DNS داشته باشد.
• عدم پشتیبانی VPN از پروتکل IPV6: هنوز بسیاری از آدرس‌های اینترنتی از پروتکل IPv4 استفاده می‌کنند؛ بااین‌وجود، برخی دیگر نیز از ابتدا به سراغ انتخاب پروتکل های IPV6 رفته‌اند. اگر VPN یا سرویس ارائه‌دهنده‌ی DNS شما از پروتکل IPV6 پشتیبانی نکند، احتمال هدایت درخواست DNS کاربر را به خارج از تونل رمزگذاری شده و نشت DNS افزایش می‌یابد.

• استفاده از Transparent DNS proxies: گاهی اوقات، یک ISP کاربران خود را مجبور می‌کند که صرفاً سرورهای DNS این سرویس‌دهنده انتخاب کنند و این کار را با استفاده از Transparent DNS proxies انجام می‌دهد که در نهایت، نشتی DNS را به دنبال دارد.
• ویژگی‌های خاص و هوشمند سیستم‌عامل ویندوز: مایکروسافت در دستگاه‌هایی که از سیستم‌عامل‌های ویندوز ۸ به بعد استفاده می‌کنند، قابلیتی به نام Smart Multi-Homed Name Resolution (SMHNR) را قرار داده است. این قابلیت، کوئری‌های DNS را به سرورهای موجود ارسال می‌کند و هر کدام از سرورهای DNS که درخواست را سریع‌تر پاسخ دهند، به سراغ همان سرور برای دریافت IP می‌رود. این کار باعث نشتی DNS می‌شود و کاربران را در معرض حملات Spoofing attacks قرار می‌دهد.

اگر با استفاده از تست‌های نشت DNS که معمولاً توسط سرویس‌های معتبر ارائه‌دهنده‌ی VPN در اختیار کاربران قرار می‌گیرد، متوجه نشت DNS شدید، جای نگرانی نیست و می‌توانید بلافاصله آن را رفع کنید. برای این منظور، تنها کافی است که به سراغ یک VPN معتبر که دارای پیکربندی مناسب باشد و از سرورهای DNS اختصاصی استفاده کند، بروید.

دی‌ان‌اس از دو پروتکل UDP و TCP برای ارسال بسته‌های داده از طریق اینترنت استفاده می‌کند. این دو پروتکل، بسته‌های داده را به سمت آدرس‌های IP مرتبط با دامنه‌ی جست‌وجوشده از سوی کاربر هدایت می‌کند.

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

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

در حالتی که حجم بسته‌های داده بیشتر از ۶۵٬۶۵۳ بیشتر باشد؛ یک سرور نیاز به جابه‌جایی کامل داشته باشد یا فایروال‌های شبکه، پروتکل UDP را مسدود کرده باشند، از پروتکل TCP استفاده می‌شود. در غیر این صورت، اولویت استفاده از یک پروتکل انتقال بسته‌های داده از سوی DNS، معمولاً با پروتکل UDP خواهد بود.

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

ازآنجاکه DNS نیز، یک ابزار واسطه است و با استفاده از DNS ارائه‌شده از سمت ISP-ها یا تغییر DNS در اندروید، ویندوز یا کنسول‌های بازی، ترافیک کاربر و سایتی که از آن بازدید می‌کند، برای ارائه‌دهندگان DNS مشخص می‌شود، این سؤال برای بسیاری از افراد پیش می‌آید که آیا تغییر DNS خطرناک است یا نه؟

پیش از پاسخ به این سؤال، بهتر است کمی با مفاهیم امنیت DNS آشنا شویم. DNS به پیروی از سیستمی که برای بسیاری از پروتکل‌های اینترنتی طراحی می‌شود، دارای چندین محدودیت مختلف است که سرورهای DNS را در مقابل حملات سایبری آسیب‌پذیر می‌کنند.

از طرفی، DNS به‌عنوان بخش جدایی‌ناپذیر در اغلب درخواست‌های اینترنتی (کوئری‌ها) به شمار می‌آید و هدف بسیار خوب و گرانبهایی برای هکرها خواهد بود. علاوه بر این، حملات DNS معمولاً به‌عنوان بخشی از حملات سایبری بزرگ انجام می‌شوند تا تمرکز تیم‌های امنیتی از هدف واقعی مورد نظر هکرها دور شود. از این رو، به‌جرئت می‌توانیم بگوییم که امنیت DNS، از بسیاری از پروتکل‌های دیگر واسطه بین کلاینت (کاربر) و سرور اهمیت بیشتری دارد.

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

• حملات DNS spoofing/cache poisoning: در این حمله، هکر داده‌های جعلی DNS را وارد حافظه‌ی کش در یک سرور Recursive resolver می‌کند. این کار باعث می‌شود که سرور Recursive resolver یک آدرس IP نادرست را برای یک دامنه بازگرداند. به عبارت ساده‌تر، کاربر آدرس یک سایت را وارد می‌کند، اما به‌جای نمایش سایت صحیح، کاربر به سایتی که هکر می‌خواهد و در واقع، یک نسخه‌ی کپی از سایت اصلی است، هدایت می‌شود. این نوع حمله، کاربرد زیادی در رسیدن به اهداف مخرب مانند آلوده‌کردن یک سیستم به بدافزار، سرقت اطلاعات ورود به یک سایت و همچنین، اجرای فیشینگ دارد.
• حملات DNS tunneling: این نوع حمله از پروتکل‌های خاصی برای تونل زدن از بین کوئری‌ها و پاسخ‌های دریافت‌شده از سرورهای DNS استفاده می‌کند. هدف اصلی این حمله، ارسال بدافزار یا اطلاعات دزدیده شده به کوئری‌های DNS است تا توسط فایرفال شناسایی نشده و از سمت کلاینت و سرورهای DNS به هکر برسد. پروتکل‌های TCP و SSH و HTTP، سه پروتکل پرکاربرد در این نوع حمله هستند.

• حملات DNS hijacking: سازوکار اصلی این نوع حمله، تا حدی به حملات DNS spoofing شباهت دارد، اما در این حمله، هکر به‌جای هدف‌گرفتن حافظهٔ کش سرور Recursive resolver، کوئری‌های DNS را دست‌کاری می‌کند تا کاربران را به وب‌سایت‌های مخرب هدایت کند. این نوع حمله نیز مانند حملات DNS spoofing، اغلب برای فیشینگ مورداستفاده قرار می‌گیرد.
• حملات NXDOMAIN attack: این نوع حمله با ارسال درخواست‌های پی‌درپی به یک سرور DNS، باعث پر شدن حافظه‌ی کش سرور می‌شود و کارایی آن را مختل می‌کند.
• حملات Phantom domain attack: این نوع حمله، عملکردی مشابه حملات NXDOMAIN attack دارد. در این حمله، هکر دسته‌ای از سرورهای دامنه‌ی فانتوم (نوعی دامنه که به وسیله‌ی روترهای FC ایجاد می‌شود.) را راه‌اندازی می‌کند. این سرورها یا به درخواست‌های کاربر پاسخ نمی‌دهند یا روند پاسخگویی بسیار آهسته‌ای دارند و ناگهان سرور Recursive resolver را با انبوهی از درخواست‌ها به این دامنه‌های فانتوم روبرو می‌کند که در نهایت سرعت عملکرد این سرور DNS را تا حد زیادی پایین می‌آورد یا روند کار آن را به طور کامل متوقف می‌کند.
• حملات Random subdomain attack: در این حمله، هکر درخواست‌های DNS را به چند زیر دامنه‌ی تصادفی و ناموجود از یک دامنه اصلی ارسال می‌کند. این کار، وجود سرور Authoritative name را نفی می‌کند تا جستجوی یک وب‌سایت از طریق Name server آن امکان‌پذیر نباشد. اجرای این حمله، علاوه بر تحت‌تأثیر قراردادن وب‌سایت هدف، باعث ورود درخواست‌های بد به حافظه‌ی کش در سرور Recursive resolver در ISP سرویس‌دهنده به هکر نیز می‌شود.
• حملات Domain lock-up attack: این حمله، نوعی از حملات DDoS است که در آن، هکر با تنظیم دامنه‌ها و حل‌کننده‌های (resolvers) ویژه و ارسال درخواست‌هایی از سوی آنها، باعث ایجاد اتصالات TCP شده و سرور DNS را برای دریافت یک پاسخ مناسب که هرگز دریافت نمی‌شود، درگیر نگه می‌دارد.
•  حملات Botnet-based CPE attack: در این حمله، مهاجم از یک دستگاه CPE (روتر، مودم و غیره) به‌عنوان بخشی از یک بات نت استفاده کند تا حملات Random subdomain attack را علیه یک سایت یا دامنه انجام دهد. بات نت‌ها، کامپیوترها یا سیستم‌هایی هستند که به بدافزار (Malware) آلوده شده‌اند.

جلوگیری از بروز حملات DNS، برخلاف آنچه که به نظر می‌رسد، غیرممکن نیست و با استفاده از پروتکل‌های مختلف یا اجرای برخی تمهیدات، می‌توان تا حد زیادی از دسترسی مهاجمان به سرورهای DNS و ورود بدافزار به این سرورها جلوگیری کرد.

پروتکل DNSSEC

یکی از مؤثرترین راه‌های حفاظت از داده‌ها در مقابل حملات DNS، استفاده از پروتکل DNSSEC است. این پروتکل، روی تمام داده‌ها یک امضای دیجیتالی منحصربه‌فرد ایجاد می‌کند و تا امضای آن‌ها را تأیید نکند، اجازه‌ی ورود آن‌ها به حافظه‌ی کش سرورهای DNS را نخواهد داد.

فیلتر DNS

فرایند فیلترکردن DNS به این صورت عمل می‌کند که تمام کوئری‌های DNS یک دامنه که در یک لیست سیاه قرار دارد، به یک سرور Recursive resolver هدایت می‌شود. پیکربندی خاص قرار داده‌شده در این سرور، مانع از پاسخ‌دهی به کوئری‌های دریافتی از آن دامنه می‌شود. در واقع، سرور Recursive resolver به‌عنوان یک فیلتر عمل می‌کند و دسترسی کاربر به آن دامنه را مسدود می‌کند.

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

فایروال DNS

این ابزار، در بین سرورهای Recursive resolver و Authoritative name قرار می‌گیرد و در زمانی که این سرورها بر اثر یک حمله‌ی DNS دچار خرابی می‌شوند و قادر به پاسخگویی به درخواست‌های کاربران نیستند، با ارائه‌ی پاسخ‌هایی از میان داده‌های ذخیره‌شده در حافظه‌ی پنهان این سرورها، سایت یا سرویس مورد نظر را سرِ پا نگه می‌دارد.

آماده‌سازی زیر ساخت یک شبکه برای ترافیک بیش از حد

اختصاص‌دادن حجم بیشتر به سرورهای DNS، یکی از راه‌حل‌های نسبتاً آسان برای غلبه بر حملات DDoS است. در حالتی که سرورهای DNS یک سرویس یا وب‌سایت، ظرفیت پذیرش بسیار بالاتری نسبت به ترافیک مورد انتظار داشته باشد، با دریافت درخواست‌های متعدد دچار افت سرعت عملکرد یا حتی توقف عملکرد نمی‌شود.

حال که با انواع حملات DNS و راهکارهای دفاعی آن‌ها آشنا شدید، نوبت به پاسخ‌دادن به سؤال مربوط به خطرناک بودن یا نبودن DNS می‌رسد. سرورهای DNS مانند اغلب پروتکل‌های امنیتی پرکاربرد در فضای اینترنت، هم امن هستند و هم ناامن.

به‌عبارت‌دیگر، استفاده از یک DNS مجزا (به‌ غیر از چیزی که ISP شما از آن استفاده می‌کند) تنها در حالتی امن است که به اعتبار سازوکار سازمان یا شخص ارائه‌دهنده‌ی این DNS اطمینان داشته باشید. بسیاری از ارائه‌دهندگان معتبر DNS-ها مانند گوگل و کلاد فلر، به امنیت کاربرانی که از DNS آن‌ها استفاده می‌کنند، اهمیت زیادی می‌دهند و امکان نشت DNS و به‌خطرافتادن اطلاعات کاربران را نمی‌دهند.

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