DNS چیست و چگونه کار می‌کند؟ راهنمای کامل

DNS چیست؟ این پرسش یکی از بنیادی‌ترین سؤال‌هایی است که هر کاربر اینترنت، مدیر شبکه یا توسعه‌دهنده‌ای دیر یا زود با آن روبه‌رو می‌شود. سامانهٔ نام دامنه یا Domain Name System در واقع همان دفترچهٔ تلفن جهانی اینترنت است؛ سیستمی توزیع‌شده و سلسله‌مراتبی که وظیفهٔ آن ترجمهٔ نام‌های خواندنی برای انسان مانند example.com به نشانی‌های عددی قابل‌فهم برای ماشین‌ها مانند 93.184.216.34 است. بدون DNS مجبور بودیم برای باز کردن هر وب‌سایت، به‌جای یک نام ساده، رشته‌ای از اعداد را به خاطر بسپاریم؛ کاری که در عمل غیرممکن است.

در این راهنمای کامل، از صفر تا صد با مفهوم سرور DNS، ساختار سلسله‌مراتبی آن، تفاوت میان ریزالورهای بازگشتی و تکراری، مراحل دقیق یک جست‌وجوی نام، سازوکار کش و TTL، قالب پیام‌های DNS، پروتکل‌های نوین مانند DNS over TLS و DNS over HTTPS، زنجیرهٔ اعتماد DNSSEC و رایج‌ترین خطاها آشنا می‌شوید. همچنین توضیح می‌دهیم که چگونه یک DNS اختصاصی می‌تواند سرعت و پایداری تجربهٔ آنلاین شما را بهبود ببخشد و چرا در کنار یک آی‌پی ثابت بهتر عمل می‌کند.

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

#مسئلهٔ اصلی: چرا به تبدیل نام به نشانی نیاز داریم؟

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

پیش از پیدایش DNS، در روزهای نخست شبکهٔ آرپانت، هر رایانه فهرست کاملی از نام‌ها و نشانی‌ها را در فایلی به نام HOSTS.TXT نگه می‌داشت. این فایل به‌صورت متمرکز مدیریت می‌شد و هر بار که میزبان جدیدی به شبکه اضافه می‌شد، باید نسخهٔ تازه‌ای از آن میان همه توزیع می‌گشت. با رشد انفجاری تعداد میزبان‌ها، این روش دیگر پاسخگو نبود؛ نه از نظر پهنای باند لازم برای توزیع فایل، نه از نظر یکتایی نام‌ها و نه از نظر به‌روزرسانی سریع. راه‌حل، طراحی سیستمی توزیع‌شده بود که در سال ۱۹۸۳ توسط پاول موکاپتریس معرفی شد و پایه‌های آن در دو سند بنیادین یعنی RFC 1034 و RFC 1035 مستند شد.

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

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

#ساختار سلسله‌مراتبی فضای نام دامنه

برای درک عمیق اینکه DNS چیست و چگونه کار می‌کند، ابتدا باید ساختار درختی آن را بشناسید. فضای نام دامنه شبیه یک درخت وارونه است که ریشهٔ آن در بالا قرار دارد و شاخه‌هایش به سمت پایین گسترده می‌شوند. هر گره در این درخت یک برچسب دارد و مسیر کامل از یک گره تا ریشه، همان چیزی است که ما آن را «نام دامنهٔ کامل» یا FQDN می‌نامیم.

#ریشه، دامنهٔ سطح بالا و دامنهٔ مرجع

در بالاترین سطح، ریشه (Root) قرار دارد که با یک نقطهٔ خالی نمایش داده می‌شود. درست زیر ریشه، دامنه‌های سطح بالا یا TLD قرار می‌گیرند؛ مانند .com، .org، .net و دامنه‌های کشوری مثل .ir یا .de. سطح بعدی، دامنه‌های سطح دوم هستند که همان نام‌هایی‌اند که سازمان‌ها و افراد ثبت می‌کنند، مانند بخش example در example.com. در نهایت می‌توان زیردامنه‌هایی مثل www یا mail را نیز به این ساختار افزود.

برای مثال نام www.shop.example.com. را در نظر بگیرید. اگر آن را از راست به چپ بخوانید، ابتدا نقطهٔ ریشه، سپس دامنهٔ سطح بالای com، بعد دامنهٔ ثبت‌شدهٔ example، سپس زیردامنهٔ shop و در انتها میزبان www را می‌بینید. این ترتیب دقیقاً همان مسیری است که یک ریزالور برای یافتن پاسخ طی می‌کند: از ریشه شروع می‌کند و لایه‌به‌لایه به سمت مرجع نهایی پیش می‌رود.

#مفهوم زون و واگذاری مسئولیت

یکی از مفاهیم مهم در DNS، «زون» (Zone) است. یک زون بخشی پیوسته از درخت نام است که مدیریت آن بر عهدهٔ یک مرجع واحد قرار دارد. مرز میان زون‌ها با سازوکاری به نام Delegation یا واگذاری مشخص می‌شود. برای نمونه، سرورهای ریشه مسئولیت پاسخ‌گویی دربارهٔ محتوای دامنهٔ com را به سرورهای TLD واگذار می‌کنند و آن‌ها نیز به‌نوبهٔ خود مسئولیت example.com را به سرورهای مرجع همان دامنه می‌سپارند.

این واگذاری با استفاده از رکوردهای NS انجام می‌شود که نام سرورهای مرجعِ زون فرزند را معرفی می‌کنند. برای آشنایی دقیق‌تر با انواع رکوردها و کارکرد هرکدام، پیشنهاد می‌کنیم مقالهٔ راهنمای کامل رکوردهای DNS را نیز مطالعه کنید. این ساختار واگذاری، ستون فقرات مقیاس‌پذیری DNS است؛ چون هر سازمان تنها مسئول زون خودش است و نیازی نیست هیچ مرجعی از کل درخت خبر داشته باشد.

#سرورهای ریشه؛ نقطهٔ آغاز هر جست‌وجو

در قلب سامانهٔ نام دامنه، سرورهای ریشه قرار دارند که نقطهٔ شروع هر جست‌وجوی کاملاً تازه‌اند. وقتی ریزالوری هیچ اطلاعاتی دربارهٔ یک نام در حافظهٔ خود ندارد، نخستین جایی که سراغ آن می‌رود، همین سرورهای ریشه هستند. این سرورها محتوای واقعی دامنه‌ها را نمی‌دانند، اما می‌دانند که برای هر دامنهٔ سطح بالا باید به کدام سرورهای TLD مراجعه کرد.

#سیزده حرف، اما هزاران دستگاه

شاید شنیده باشید که در جهان تنها سیزده سرور ریشه وجود دارد. این جمله هم درست است و هم گمراه‌کننده. در واقع سیزده نشانی منطقی برای سرورهای ریشه تعریف شده که با حروف A تا M نام‌گذاری می‌شوند؛ یعنی از a.root-servers.net تا m.root-servers.net. علت محدود بودن به سیزده حرف، مربوط به محدودیت اندازهٔ بستهٔ DNS در پروتکل UDP است که در بخش‌های بعدی به آن می‌پردازیم؛ پاسخ کامل فهرست سرورهای ریشه باید در یک بستهٔ استاندارد جا می‌گرفت.

اما پشت هر یک از این سیزده حرف، ده‌ها یا صدها دستگاه فیزیکی در سراسر جهان پنهان شده است. مجموع این دستگاه‌ها امروز به بیش از هزار نمونه در نقاط مختلف کرهٔ زمین می‌رسد. این کار به کمک فناوری‌ای به نام Anycast ممکن شده است. برای مطالعهٔ فهرست رسمی و به‌روز اپراتورهای سرورهای ریشه می‌توانید به صفحهٔ IANA Root Servers مراجعه کنید و برای آشنایی با نهاد هماهنگ‌کنندهٔ این زیرساخت، وب‌سایت ICANN منبع معتبری است.

#Anycast چگونه سرعت و پایداری را تضمین می‌کند؟

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

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

#ریزالور DNS: مغز متفکر فرایند

تا اینجا با ساختار داده‌ها آشنا شدیم، اما چه کسی این درخت را پیمایش می‌کند؟ پاسخ، ریزالور (Resolver) است. ریزالور نرم‌افزاری است که از طرف کاربر مسئولیت پیدا کردن پاسخ یک پرس‌وجو را بر عهده می‌گیرد. درک تفاوت دو نوع رفتار در این بخش، برای فهم کامل DNS ضروری است: پرس‌وجوی بازگشتی و پرس‌وجوی تکراری.

#پرس‌وجوی بازگشتی در برابر پرس‌وجوی تکراری

در پرس‌وجوی بازگشتی (Recursive)، کاربر از ریزالور می‌خواهد که «هر طور شده پاسخ نهایی را برایم پیدا کن». ریزالور مسئولیت کامل را می‌پذیرد و تا زمانی که یا پاسخ قطعی را بیابد یا با خطا مواجه شود، دست از تلاش برنمی‌دارد. رایانهٔ خانگی شما معمولاً چنین درخواستی را به ریزالور بازگشتی سرویس‌دهندهٔ اینترنت یا یک سرور DNS عمومی می‌فرستد.

در مقابل، در پرس‌وجوی تکراری (Iterative)، هر سرور تنها بهترین پاسخی را که می‌داند برمی‌گرداند. اگر پاسخ نهایی را نداند، به‌جای پیگیری، صرفاً می‌گوید «من نمی‌دانم، اما این سرور دیگر احتمالاً می‌داند؛ از او بپرس». این همان گفت‌وگویی است که میان ریزالور بازگشتی و سرورهای ریشه، TLD و مرجع رد و بدل می‌شود. به بیان ساده، کاربر یک درخواست بازگشتی می‌فرستد و ریزالور در پشت صحنه، زنجیره‌ای از درخواست‌های تکراری را انجام می‌دهد.

#انواع ریزالور و نقش هرکدام

در عمل چند لایه ریزالور در مسیر یک درخواست دخالت دارند. نخست Stub Resolver که همان کتابخانهٔ کوچک داخل سیستم‌عامل شماست و کار چندانی جز ارسال درخواست به ریزالور بالادست انجام نمی‌دهد. سپس Recursive Resolver که موتور اصلی است و کل زنجیره را دنبال می‌کند. در نهایت Authoritative Server که پاسخ قطعی و رسمی هر زون را نگه می‌دارد. تمایز میان این سه نقش را در جدول زیر جمع‌بندی کرده‌ایم.

#مسیر کامل یک جست‌وجوی DNS، گام‌به‌گام

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

1. بررسی کش محلی: ابتدا سیستم‌عامل و مرورگر حافظهٔ کوتاه‌مدت خود را بررسی می‌کنند. اگر پاسخ آنجا باشد، کار همین‌جا تمام می‌شود.
2. درخواست به ریزالور بازگشتی: اگر پاسخی در کش نبود، Stub Resolver یک پرس‌وجوی بازگشتی به ریزالور بالادست (مثلاً 8.8.8.8 یا یک DNS اختصاصی) می‌فرستد.
3. پرسش از سرور ریشه: ریزالور اگر چیزی در کش نداشته باشد، از یکی از سرورهای ریشه می‌پرسد. سرور ریشه محتوای example.com را نمی‌داند اما نشانی سرورهای com را برمی‌گرداند.
4. پرسش از سرور TLD: ریزالور از سرور com می‌پرسد. آن هم پاسخ نهایی را نمی‌داند اما رکوردهای NS مربوط به سرورهای مرجع example.com را معرفی می‌کند.
5. پرسش از سرور مرجع: سرانجام ریزالور از سرور مرجع example.com می‌پرسد و این بار پاسخ قطعی، یعنی رکورد A با نشانی عددی مقصد، بازگردانده می‌شود.
6. بازگشت پاسخ و ذخیره در کش: ریزالور پاسخ را به کاربر تحویل می‌دهد و همزمان آن را برای مدت مشخصی در کش ذخیره می‌کند تا دفعهٔ بعد سریع‌تر پاسخ دهد.

ابزار خط فرمان dig به شما اجازه می‌دهد این زنجیره را با چشم خود ببینید. گزینهٔ +trace کل مسیر از ریشه تا مرجع را نمایش می‌دهد. خروجی زیر نمونه‌ای ساده‌شده از این فرایند است:

$ dig +trace www.example.com

.                       518400  IN  NS  a.root-servers.net.
.                       518400  IN  NS  b.root-servers.net.
;; Received 811 bytes from 198.41.0.4#53(a.root-servers.net) in 12 ms

com.                    172800  IN  NS  a.gtld-servers.net.
com.                    172800  IN  NS  b.gtld-servers.net.
;; Received 1174 bytes from 192.5.6.30#53(a.gtld-servers.net) in 28 ms

example.com.            172800  IN  NS  a.iana-servers.net.
example.com.            172800  IN  NS  b.iana-servers.net.
;; Received 576 bytes from 192.12.94.30#53(a.gtld-servers.net) in 30 ms

www.example.com.        3600    IN  A   93.184.216.34
;; Received 60 bytes from 199.43.135.53#53(a.iana-servers.net) in 41 ms

در این خروجی به‌روشنی می‌بینید که پاسخ چگونه لایه‌به‌لایه محدودتر می‌شود: نخست سرورهای ریشه، سپس سرورهای com، بعد سرورهای مرجع example.com و در نهایت رکورد A با نشانی 93.184.216.34. عدد ابتدای هر خط، همان مقدار TTL است که در بخش بعد به‌تفصیل توضیح می‌دهیم.

#کش و TTL؛ راز سرعت DNS

اگر قرار بود هر بار برای هر نام، کل این زنجیره از ابتدا طی شود، اینترنت به‌شدت کند می‌شد. راه‌حل، کش کردن (Caching) است. هر ریزالور پاسخ‌هایی را که دریافت می‌کند، برای مدتی در حافظه نگه می‌دارد تا در درخواست‌های بعدی نیازی به پیمایش دوباره نباشد. اما این پاسخ‌ها تا کی معتبرند؟ اینجاست که TTL یا Time To Live نقش‌آفرینی می‌کند.

#TTL دقیقاً چیست؟

هر رکورد DNS همراه با یک مقدار TTL بازگردانده می‌شود که برحسب ثانیه بیان می‌شود و می‌گوید این پاسخ تا چه مدت قابل‌اعتماد است. برای نمونه اگر رکوردی TTL 3600 داشته باشد، یعنی ریزالورها مجازند آن را تا یک ساعت (سه‌هزار و ششصد ثانیه) در کش نگه دارند. پس از پایان این مدت، رکورد «کهنه» تلقی می‌شود و باید دوباره از مرجع پرسیده شود. انتخاب مقدار مناسب TTL یک تصمیم مهندسی مهم است.

#موازنهٔ میان سرعت و انعطاف

مقدار TTL یک شمشیر دولبه است. مقدار بالا (مثلاً یک روز) یعنی پاسخ‌ها مدت طولانی در کش می‌مانند، بار روی سرورهای مرجع کم می‌شود و سرعت پاسخ‌گویی افزایش می‌یابد؛ اما اگر بخواهید نشانی سرور را تغییر دهید، ممکن است ساعت‌ها طول بکشد تا این تغییر در همهٔ کش‌های جهان اعمال شود. در مقابل، مقدار پایین (مثلاً چند دقیقه) انعطاف بیشتری می‌دهد و تغییرات را سریع منتشر می‌کند، اما بار بیشتری بر سرورها تحمیل می‌کند و تأخیر متوسط را بالا می‌برد.

به همین دلیل، مدیران شبکه معمولاً پیش از یک جابه‌جایی برنامه‌ریزی‌شده، مقدار TTL را موقتاً کاهش می‌دهند تا انتقال روان‌تر انجام شود و سپس دوباره آن را بالا می‌برند. این تکنیک به‌ویژه هنگام مهاجرت سرویس‌ها یا تغییر آی‌پی ثابت به داینامیک اهمیت زیادی دارد. جدول زیر تأثیر انتخاب TTL را خلاصه می‌کند.

#کش منفی؛ به خاطر سپردن پاسخ‌های «وجود ندارد»

نکتهٔ ظریفی که بسیاری از آن غافل‌اند این است که نه‌تنها پاسخ‌های مثبت، بلکه پاسخ‌های منفی نیز کش می‌شوند. وقتی نامی وجود ندارد، سرور مرجع پاسخی به نام NXDOMAIN برمی‌گرداند. اگر این پاسخ منفی کش نمی‌شد، هر بار که کاربری نام اشتباهی را وارد می‌کرد، کل زنجیره دوباره طی می‌شد و بار سنگینی بر سرورها می‌افتاد. سازوکار کش منفی که در RFC 2308 استاندارد شده، دقیقاً برای حل همین مسئله طراحی شده است.

مدت‌زمان نگهداری پاسخ منفی، به‌جای اینکه از یک رکورد معمولی گرفته شود، از فیلد ویژه‌ای در رکورد SOA زون به نام Minimum TTL تعیین می‌شود. به این ترتیب صاحب هر دامنه می‌تواند مشخص کند که پاسخ‌های «این نام وجود ندارد» تا چه مدت معتبر تلقی شوند. کش منفی یکی از عوامل مهم در کاهش بار کلی شبکه است، به‌ویژه در برابر درخواست‌های اشتباه یا مخربی که سراغ نام‌های ناموجود می‌روند.

#ساختار پیام DNS؛ نگاهی به درون بسته‌ها

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

#پنج بخش هر پیام

• سرآیند (Header): همیشه دوازده بایت است و اطلاعات کنترلی مانند شناسهٔ پرس‌وجو، پرچم‌ها و تعداد رکوردهای هر بخش را در خود دارد.
• بخش پرسش (Question): مشخص می‌کند چه نامی، از چه نوعی (مثلاً A یا MX) و در چه کلاسی درخواست شده است.
• بخش پاسخ (Answer): رکوردهای منابعی که مستقیماً به پرسش پاسخ می‌دهند.
• بخش مرجع (Authority): رکوردهای NS که سرورهای مرجع مسئول را معرفی می‌کنند.
• بخش افزوده (Additional): اطلاعات کمکی مانند نشانی عددی سرورهای مرجع، که با ارائهٔ آن‌ها از یک رفت‌وبرگشت اضافی جلوگیری می‌شود؛ به این رکوردها Glue Record گفته می‌شود.

#پرچم‌ها و شناسهٔ پرس‌وجو

سرآیند شامل چند پرچم کلیدی است. پرچم QR مشخص می‌کند که پیام یک پرسش است یا پاسخ. پرچم AA نشان می‌دهد پاسخ از یک سرور مرجع آمده است یا خیر. پرچم RD یعنی «بازگشتی بودن مطلوب است» و پرچم RA اعلام می‌کند که سرور توانایی پاسخ بازگشتی دارد. علاوه بر این، یک شناسهٔ شانزده‌بیتی به نام Transaction ID در هر پرس‌وجو قرار می‌گیرد که پاسخ متناظر باید همان شناسه را داشته باشد. همان‌طور که بعداً خواهیم دید، تصادفی بودن این شناسه در امنیت DNS نقشی حیاتی دارد.

#پروتکل‌های انتقال: UDP، محدودیت ۵۱۲ بایت و TCP

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

#چرا مرز ۵۱۲ بایت اهمیت داشت؟

در استاندارد اصلی DNS، حداکثر اندازهٔ یک پیام UDP به ۵۱۲ بایت محدود شده بود. این عدد از این واقعیت می‌آمد که در آن زمان تضمین می‌شد بسته‌های تا این اندازه بدون تکه‌تکه شدن در مسیر شبکه عبور کنند. همین محدودیت بود که تعداد سرورهای ریشهٔ قابل‌معرفی در یک پاسخ را به سیزده رساند. اما با گذر زمان و پیچیده‌تر شدن پاسخ‌ها، به‌ویژه با ورود امضاهای دیجیتال DNSSEC، این مرز به‌شدت دست‌وپاگیر شد.

#EDNS0 و شکستن مرز قدیمی

راه‌حل، افزونه‌ای به نام EDNS0 بود که در RFC 6891 استاندارد شد. این مکانیزم با افزودن یک رکورد شبه به نام OPT در بخش افزودهٔ پیام، به سرور و ریزالور اجازه می‌دهد اندازهٔ بستهٔ بزرگ‌تری را با هم توافق کنند؛ برای نمونه ۴۰۹۶ بایت. EDNS0 همچنین بستری برای گزینه‌های نوین دیگر فراهم کرد. بدون آن، عملاً استفادهٔ کارآمد از DNSSEC ممکن نبود.

#چه زمانی به TCP سوییچ می‌کنیم؟

اگر پاسخی حتی با EDNS0 هم بزرگ‌تر از حد توافق‌شده باشد، سرور پرچم TC یا Truncated را در پاسخ فعال می‌کند. این پرچم به ریزالور می‌گوید «پاسخ من بریده شده است؛ لطفاً دوباره اما این بار با TCP بپرس». آنگاه ریزالور همان پرس‌وجو را روی درگاه 53 اما با پروتکل TCP تکرار می‌کند که محدودیت اندازه ندارد. علاوه بر پاسخ‌های بزرگ، انتقال کامل یک زون میان سرورها (که Zone Transfer نامیده می‌شود) نیز همیشه با TCP انجام می‌شود. جدول زیر تفاوت این دو پروتکل را در بستر DNS نشان می‌دهد.

#حریم خصوصی و یکپارچگی: DNS over TLS و DNS over HTTPS

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

#DNS over TLS چیست؟

DNS over TLS یا به‌اختصار DoT که در RFC 7858 تعریف شده، پرس‌وجوهای DNS را درون یک نشست رمزنگاری‌شدهٔ TLS قرار می‌دهد. این ارتباط روی درگاه اختصاصی شمارهٔ 853 برقرار می‌شود. مزیت جدا بودن درگاه این است که مدیران شبکه به‌روشنی می‌توانند ترافیک DNS رمزنگاری‌شده را تشخیص دهند و برای آن سیاست‌گذاری کنند. DoT از نظر ساختاری بسیار نزدیک به DNS سنتی است و صرفاً یک پوستهٔ رمزنگاری‌شده به آن افزوده است.

#DNS over HTTPS چگونه متفاوت است؟

DNS over HTTPS یا DoH که در RFC 8484 استاندارد شده، رویکرد دیگری دارد. در این روش، پرس‌وجوهای DNS درون درخواست‌های معمولی HTTPS روی درگاه 443 قرار می‌گیرند؛ همان درگاهی که ترافیک عادی وب از آن عبور می‌کند. نتیجه این است که ترافیک DNS از دید یک ناظر بیرونی، از سایر ترافیک وب قابل‌تمایز نیست. باید تأکید کنیم که در این مقاله DoT و DoH را صرفاً از منظر حفظ حریم خصوصی و تضمین یکپارچگی پاسخ‌ها بررسی می‌کنیم؛ یعنی جلوگیری از شنود و دستکاری، نه هیچ کاربرد دیگری.

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

#DNSSEC؛ زنجیرهٔ اعتماد برای تضمین صحت پاسخ

رمزنگاری کردن مسیر (مانند DoT و DoH) از شنود جلوگیری می‌کند، اما تضمین نمی‌کند که خودِ داده در منبع دستکاری نشده باشد. برای پاسخ به این نیاز، DNSSEC یا DNS Security Extensions طراحی شد. DNSSEC با افزودن امضای دیجیتال به رکوردها، تضمین می‌کند که پاسخ واقعاً از مرجع معتبر آمده و در مسیر تغییر نکرده است. رکوردهای مرتبط با این سازوکار در RFC 4034 تعریف شده‌اند.

#رکوردهای کلیدی DNSSEC

DNSSEC چند نوع رکورد تازه معرفی می‌کند. رکورد RRSIG امضای دیجیتال یک مجموعه رکورد را نگه می‌دارد. رکورد DNSKEY کلید عمومی‌ای است که برای بررسی آن امضا استفاده می‌شود. رکورد DS یا Delegation Signer اثر انگشتی از کلید زون فرزند است که در زون والد قرار می‌گیرد و پل اعتماد میان دو سطح را می‌سازد. رکورد NSEC نیز برای اثبات امن نبودنِ یک نام (یعنی اثبات این‌که نامی واقعاً وجود ندارد) به کار می‌رود.

#زنجیرهٔ اعتماد چگونه ساخته می‌شود؟

ایدهٔ اصلی DNSSEC یک زنجیرهٔ اعتماد است که از ریشه آغاز می‌شود. کلید زون ریشه به‌عنوان «لنگر اعتماد» شناخته می‌شود و همه به آن اعتماد دارند. ریشه با رکورد DS صحت کلید زون com را تأیید می‌کند، زون com صحت کلید example.com را، و همین‌طور تا پایین. اگر هر حلقه از این زنجیره بشکند یا امضایی نامعتبر باشد، ریزالورِ اعتبارسنج پاسخ را رد می‌کند و خطای SERVFAIL برمی‌گرداند. به این ترتیب کاربر از دریافت دادهٔ جعلی محافظت می‌شود.

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

#حالت‌های خطای رایج در DNS

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

#NXDOMAIN، SERVFAIL و REFUSED

NXDOMAIN یعنی نامی که پرسیده‌اید اصلاً وجود ندارد؛ این یک پاسخ قطعی و معتبر است، نه لزوماً یک خرابی. SERVFAIL یعنی سرور در پردازش درخواست با مشکل روبه‌رو شده؛ این خطا اغلب نشانهٔ مشکل در اعتبارسنجی DNSSEC یا در دسترس نبودن سرور مرجع است. REFUSED یعنی سرور از پاسخ‌گویی خودداری کرده، معمولاً به دلیل سیاست‌های دسترسی؛ برای مثال وقتی درخواست بازگشتی به سروری فرستاده می‌شود که تنها به مشتریان خاصی خدمت می‌دهد.

#لِیم دلیگیشن؛ یک تلهٔ پیکربندی رایج

یکی از خطاهای موذی، لِیم دلیگیشن (Lame Delegation) است. این وضعیت زمانی رخ می‌دهد که زون والد، سروری را به‌عنوان مرجع یک زون معرفی می‌کند، اما آن سرور در عمل مسئولیت آن زون را نمی‌شناسد یا به‌درستی برای آن پیکربندی نشده است. نتیجه، تأخیر و خطاهای متناوب است؛ چون ریزالور به سراغ سروری می‌رود که انتظار پاسخ معتبر از آن می‌رود اما پاسخ درستی نمی‌گیرد. جدول زیر رایج‌ترین کدهای پاسخ DNS را جمع‌بندی می‌کند.

#DNS اختصاصی چگونه سرعت و پایداری را بهبود می‌دهد؟

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

#کاهش تأخیر با کش گرم و مسیریابی هوشمند

یک ریزالور اختصاصی که تعداد مشخص و محدودی کاربر دارد، می‌تواند کش خود را متناسب با الگوی استفادهٔ همان کاربران بهینه کند. وقتی رکوردهای پرکاربرد شما همیشه در کش «گرم» باشند، پاسخ‌ها تقریباً بی‌درنگ بازگردانده می‌شوند. افزون بر این، با به‌کارگیری مسیریابی هوشمند و انتخاب نزدیک‌ترین مسیر ممکن به سرورهای مرجع، تعداد پرش‌های شبکه و در نتیجه تأخیر کل کاهش می‌یابد. این همان اصلی است که در معماری Anycast نیز دیدیم.

#پایداری و قابلیت اطمینان بالاتر

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

#DNS و آی‌پی ثابت؛ یک هم‌افزایی طبیعی

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

#چرا آی‌پی ثابت به رکوردهای DNS پایدارتری می‌انجامد؟

وقتی سرویس شما روی یک نشانی عددی ثابت میزبانی می‌شود، رکورد A یا AAAA مربوط به آن نیز ثابت می‌ماند. این یعنی می‌توانید مقدار TTL را بالاتر بگذارید، از مزایای کش طولانی‌مدت بهره ببرید و بار کمتری بر سرورهای مرجع تحمیل کنید. در مقابل، با یک نشانی متغیر، مجبورید TTL را پایین نگه دارید تا تغییرات سریع منتشر شوند، که خود به تأخیر و بار بیشتر می‌انجامد. تفاوت این دو رویکرد را در مقالهٔ تفاوت آی‌پی ثابت و آی‌پی داینامیک به‌تفصیل بررسی کرده‌ایم.

#ترکیب DNS اختصاصی و آی‌پی ثابت

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

#اندازه‌گیری زمان تبدیل نام (Resolution Time)

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

#خواندن خروجی nslookup

ابزار nslookup یک روش ساده برای پرسیدن مستقیم از یک سرور مشخص است. در مثال زیر، نام example.com را از سرور 8.8.8.8 پرسیده‌ایم:

$ nslookup example.com 8.8.8.8

Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:   example.com
Address: 93.184.216.34

عبارت Non-authoritative answer به این معناست که پاسخ از کش ریزالور آمده، نه مستقیماً از سرور مرجع. اگر همان پرسش را مستقیماً از سرور مرجع دامنه بپرسید، این برچسب ظاهر نمی‌شود. این تمایز برای عیب‌یابی اهمیت دارد؛ گاهی پاسخِ کهنه‌ای در کش مانده و شما باید تازه بودن آن را بررسی کنید.

#سنجش دقیق‌تر با dig

ابزار dig جزئیات بیشتری ارائه می‌دهد. در انتهای خروجی آن، خطی به نام Query time وجود دارد که مدت‌زمان پاسخ را برحسب میلی‌ثانیه نشان می‌دهد. اگر همان پرس‌وجو را دو بار پشت‌سرهم اجرا کنید، معمولاً بار دوم بسیار سریع‌تر است؛ چون پاسخ حالا در کش ریزالور نشسته است. این آزمایش سادهٔ دوباره‌پرسیدن، بهترین راه برای دیدن تأثیر واقعی کش در عمل است. مقایسهٔ زمان پاسخ میان چند ریزالور مختلف نیز به شما کمک می‌کند سریع‌ترین گزینه را برای شبکهٔ خود بیابید.

#سمی‌سازی کش و اهمیت تصادفی‌سازی درگاه مبدأ

از آنجا که DNS در طراحی اولیه بر پایهٔ UDP و بدون رمزنگاری بنا شده بود، در برابر نوعی حمله به نام سمی‌سازی کش (Cache Poisoning) آسیب‌پذیر است. در این حمله، مهاجم می‌کوشد پیش از رسیدن پاسخ واقعی، یک پاسخ جعلی به ریزالور تزریق کند تا نامی را به نشانی نادرست هدایت کند. اگر این پاسخ جعلی در کش بنشیند، همهٔ کاربرانِ آن ریزالور به مقصد اشتباه فرستاده می‌شوند.

#چطور یک پاسخ جعلی پذیرفته می‌شود؟

برای اینکه ریزالور یک پاسخ را معتبر بداند، آن پاسخ باید با چند مشخصهٔ پرس‌وجوی اصلی هم‌خوانی داشته باشد؛ از جمله شناسهٔ شانزده‌بیتی پرس‌وجو و درگاه مبدأ. در گذشته، بسیاری از ریزالورها از درگاه مبدأ ثابت یا قابل‌پیش‌بینی استفاده می‌کردند و شناسهٔ پرس‌وجو نیز به‌صورت ترتیبی افزایش می‌یافت. این قابل‌پیش‌بینی بودن، کار مهاجم را برای جعل پاسخ آسان می‌کرد.

#تصادفی‌سازی درگاه مبدأ به‌عنوان سپر دفاعی

راهکار مهمی که فضای حمله را به‌شدت کوچک می‌کند، تصادفی‌سازی درگاه مبدأ (Source Port Randomization) است. وقتی ریزالور برای هر پرس‌وجو یک درگاه مبدأ تصادفی انتخاب می‌کند، مهاجم علاوه بر حدس زدن شناسهٔ شانزده‌بیتی پرس‌وجو، باید درگاه تصادفی را نیز حدس بزند. ترکیب این دو، تعداد حالت‌های ممکن را از ده‌ها هزار به میلیاردها می‌رساند و حمله را عملاً ناممکن می‌کند. به همین دلیل، تصادفی بودن هم شناسهٔ پرس‌وجو و هم درگاه مبدأ، یکی از پایه‌ای‌ترین اصول امنیتی در پیاده‌سازی هر ریزالور مدرن است. البته راهکار قطعی‌تر، استفاده از DNSSEC برای امضای دیجیتال پاسخ‌هاست که پیش‌تر توضیح دادیم.

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

#جمع‌بندی

در این راهنما از پایه‌ای‌ترین پرسش، یعنی «DNS چیست»، تا مفاهیم پیشرفته‌ای مانند زنجیرهٔ اعتماد DNSSEC و تصادفی‌سازی درگاه مبدأ را پیمودیم. دیدیم که سامانهٔ نام دامنه یک پایگاه‌دادهٔ توزیع‌شدهٔ سلسله‌مراتبی است که با همکاری سرورهای ریشه، TLD و مرجع، نام‌های خواندنی را به نشانی‌های عددی ترجمه می‌کند. آموختیم که کش و TTL راز سرعت آن هستند، پروتکل‌های UDP و TCP هرکدام جای خود را دارند، و استانداردهای نوینی مانند DoT و DoH حریم خصوصی و یکپارچگی پرس‌وجوها را تقویت می‌کنند.

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

#پرسش‌های پرتکرار

#DNS دقیقاً چه کاری انجام می‌دهد؟

DNS یا سامانهٔ نام دامنه، وظیفهٔ ترجمهٔ نام‌های خواندنی برای انسان مانند example.com را به نشانی‌های عددی IP مانند 93.184.216.34 بر عهده دارد. این ترجمه به دستگاه‌ها اجازه می‌دهد یکدیگر را در شبکه پیدا کنند، بدون آنکه کاربر مجبور باشد اعداد را به خاطر بسپارد. به بیان ساده، DNS همان دفترچهٔ تلفن جهانی اینترنت است که نام‌ها را به نشانی‌ها پیوند می‌دهد.

#تفاوت ریزالور بازگشتی و سرور مرجع چیست؟

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

#مقدار TTL مناسب چقدر است؟

پاسخ به کاربرد بستگی دارد. برای رکوردهای پایدار مانند MX یا NS، مقدار بلند (۲۴ ساعت یا بیشتر) بار را کم می‌کند و سرعت کش را بالا می‌برد. اما اگر قصد جابه‌جایی سرور را دارید، بهتر است چند روز قبل TTL را به چند دقیقه کاهش دهید تا تغییرات سریع منتشر شوند و پس از تثبیت، دوباره آن را بالا ببرید. برای بیشتر وب‌سایت‌های عادی، بازهٔ یک تا چهار ساعت انتخاب متعادلی است.

#چرا گاهی تغییر DNS من دیر اعمال می‌شود؟

علت اصلی، کش کردن و مقدار TTL است. وقتی رکوردی را تغییر می‌دهید، ریزالورهایی که نسخهٔ قبلی را در کش دارند تا پایان مدت TTL همان نسخهٔ قدیمی را نمایش می‌دهند. به این دورهٔ انتظار، Propagation یا انتشار گفته می‌شود. اگر پیش از تغییر، TTL را پایین آورده باشید، این انتشار بسیار سریع‌تر انجام می‌شود.

#تفاوت DNS over TLS و DNS over HTTPS در چیست؟

هر دو پرس‌وجوهای DNS را رمزنگاری می‌کنند تا از شنود و دستکاری در مسیر جلوگیری شود، اما در نحوهٔ حمل متفاوت‌اند. DoT از یک نشست TLS مستقیم روی درگاه 853 استفاده می‌کند و برای مدیران شبکه به‌سادگی قابل‌تشخیص است. DoH پرس‌وجوها را درون ترافیک عادی HTTPS روی درگاه 443 جای می‌دهد و از سایر ترافیک وب قابل‌تفکیک نیست. انتخاب میان این دو به سیاست‌های شبکهٔ شما بستگی دارد.

#آیا DNSSEC جای رمزنگاری مانند DoH را می‌گیرد؟

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

#NXDOMAIN یعنی چه و آیا یک خطاست؟

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

#چرا یک DNS اختصاصی بهتر از ریزالور پیش‌فرض است؟

یک DNS اختصاصی ظرفیت اختصاص‌یافته، کش بهینه‌شده برای الگوی استفادهٔ شما، پایش پیوسته و کنترل کامل بر تنظیماتی مانند EDNS0 و اعتبارسنجی DNSSEC را فراهم می‌کند. این ویژگی‌ها معمولاً به تأخیر کمتر و پایداری بیشتر نسبت به ریزالورهای عمومی شلوغ می‌انجامند. وقتی این سرویس را در کنار یک آی‌پی ثابت به کار بگیرید، هم فرایند ترجمهٔ نام و هم مقصد نهایی، پایدار و قابل‌اعتماد خواهند بود.

#چطور می‌توانم سرعت پاسخ‌دهی DNS را اندازه بگیرم؟

ساده‌ترین راه، استفاده از ابزارهای dig در سیستم‌های شبه‌یونیکس یا nslookup در ویندوز است. در خروجی dig، خط Query time مدت پاسخ را برحسب میلی‌ثانیه نشان می‌دهد. اگر همان پرس‌وجو را دو بار اجرا کنید، بار دوم به‌لطف کش سریع‌تر خواهد بود. با مقایسهٔ زمان پاسخ چند ریزالور مختلف می‌توانید سریع‌ترین و پایدارترین گزینه را برای شبکهٔ خود انتخاب کنید.