DNS چگونه کار میکند
سامانه نام دامنه (DNS) نامی مانند www.example.com را به آدرس IP تبدیل میکند که کامپیوترها برای اتصال به کار میبرند. یک ریزالور بازگشتی (recursive resolver) این کار را برای شما انجام میدهد: از سرورهای ریشه میپرسد، سپس از سرورهای دامنه سطح بالا و بعد از سرورهای معتبر (authoritative) دامنه، و پاسخ را برای استفاده بعدی ذخیره میکند. این کار معمولاً چند میلیثانیه طول میکشد.
مسیر ریزالو
وقتی www.example.com را باز میکنید و چیزی در کش نیست، این مراحل رخ میدهد:
- Stub resolver. سیستمعامل شما یک کلاینت کوچک داخلی دارد. کش خودش و فایل hosts را بررسی میکند و سپس پرسش را به ریزالور بازگشتی تنظیمشده میفرستد (معمولاً از طرف مسیریاب یا ارائهدهنده اینترنت، یا یک ریزالور عمومی).
- ریزالور بازگشتی. کش خود را بررسی میکند. اگر پاسخی نداشت، از بالا شروع میکند و تا رسیدن به پاسخ نهایی پرسش میکند.
- سرورهای ریشه. ریزالور از یک سرور ریشه درباره
www.example.comمیپرسد. ریشه آدرس را نمیداند، اما سرورهای مسئول.comرا معرفی میکند. - سرورهای TLD. سرورهای
.comهم آدرس را نمیدانند، اما نیمسرورهایexample.com(رکوردهای NS) را برمیگردانند. - سرورهای معتبر (authoritative). نیمسرور دامنه رکوردهای واقعی را دارد و رکورد A یا AAAA مربوط به
www.example.comرا برمیگرداند. - ریزالور پاسخ را به stub resolver برمیگرداند، آن را در کش ذخیره میکند و مرورگر متصل میشود.
این زنجیره را برای هر دامنهای با ابزار بررسی DNS ما میتوانید دنبال کنید.
کش و TTL
هر رکورد DNS یک TTL (time to live) دارد؛ عددی بر حسب ثانیه که به ریزالورها میگوید تا چه مدت میتوانند پاسخ را نگه دارند. TTL برابر 3600 یعنی یک ساعت. کش کردن DNS را سریع میکند و بار روی سرورهای معتبر را کم میکند، اما باعث میشود تغییر در همه جا همزمان دیده نشود. کش در چند جا وجود دارد: مرورگر، سیستمعامل، مسیریاب و ریزالور بازگشتی.
ریزالورها پاسخهای منفی را هم کش میکنند، مثلاً «این نام وجود ندارد» (NXDOMAIN)، به مدتی که در رکورد SOA تعیین شده است.
انواع رکوردهای رایج
| نوع | کاربرد | مقدار نمونه |
|---|---|---|
| A | یک نام را به آدرس IPv4 نگاشت میکند | 192.0.2.10 |
| AAAA | یک نام را به آدرس IPv6 نگاشت میکند | 2001:db8::10 |
| CNAME | نام مستعار از یک نام به نام دیگر. در رأس zone نمیتواند در کنار رکوردهای دیگر وجود داشته باشد. | www.example.com → example.com |
| MX | سرورهای ایمیل دامنه همراه با اولویت (عدد کمتر ابتدا امتحان میشود) | 10 mail.example.com |
| NS | نیمسرورهای معتبر zone | ns1.example.com |
| TXT | متن آزاد؛ برای SPF، DKIM، DMARC و تأیید مالکیت دامنه استفاده میشود | "v=spf1 mx -all" |
| SOA | شروع اختیار (Start of authority): سرور اصلی، تماس مدیر، شماره سریال و تایمرها | ns1.example.com hostmaster.example.com 2026110401 ... |
| CAA | مشخص میکند کدام مراجع صدور گواهی مجاز به صدور گواهی برای دامنه هستند | 0 issue "ca.example.net" |
| SRV | میزبان و پورت یک سرویس مشخص | 10 5 5060 sip.example.com |
| PTR | جستوجوی معکوس: آدرس IP را به یک نام برمیگرداند | 10.2.0.192.in-addr.arpa → host.example.com |
رکوردهای MX، SPF و DKIM درست برای تحویل ایمیل مهم هستند. برای بررسی یک سرور ایمیل و اینکه آدرس IP آن در فهرستهای سیاه اسپم قرار دارد یا نه، از ابزار ایمیل و بلکلیست ما استفاده کنید.
انتشار DNS (propagation) واقعاً چیست
«انتشار DNS» نام رایج مدت زمانی است که طول میکشد تا همه کشهای جهان پاسخ قدیمی را کنار بگذارند و پاسخ جدید را دریافت کنند. چیزی در اینترنت «پخش» نمیشود. سرور معتبر داده جدید را بلافاصله دارد؛ ریزالورها صرفاً داده قدیمی را تا پایان TTL نگه میدارند. بنابراین بیشینه تأخیر برای یک رکورد تغییرکرده تقریباً برابر TTL قدیمی است و نه TTL جدید.
تغییر نیمسرورها در ثبتکننده (registrar) کندتر است، چون رکوردهای NS در zone مربوط به TLD معمولاً TTL یک تا دو روز دارند. در این مدت بعضی کاربران به سرورهای قدیمی و بعضی به سرورهای جدید میرسند. تفویض (delegation) دامنه را با جستوجوی WHOIS و خود رکوردها را با ابزار بررسی DNS میتوانید ببینید.
چگونه تغییر را سریع منتشر کنیم
- دستکم یک دوره TTL قدیمی پیش از تغییر (مثلاً 24 ساعت اگر TTL برابر 86400 است)، TTL رکورد را به مقدار کوچکی مانند 300 ثانیه کاهش دهید.
- صبر کنید تا TTL قدیمی بگذرد، تا همه کشها نسخه کوتاهمدت را داشته باشند.
- تغییر را اعمال کنید. ریزالورها اکنون ظرف حدود 5 دقیقه دوباره میپرسند.
- نتیجه را از چند موقعیت با یک ابزار بررسی DNS کنترل کنید.
- پس از اطمینان از درستی کار، برای کاهش بار پرسوجو، TTL را دوباره افزایش دهید.
سریال SOA و سرورهای ثانویه
بیشتر دامنهها دستکم دو سرور معتبر دارند. یکی اصلی (primary) است و بقیه ثانویه (secondary) هستند که zone را با انتقال zone (AXFR یا IXFR) از آن کپی میکنند. رکورد SOA این فرایند را کنترل میکند:
- Serial: شماره نسخه. وقتی سریال در سرور اصلی از سریال خودش بیشتر باشد، سرور ثانویه zone را منتقل میکند. قالب رایج تاریخ بهعلاوه شمارنده است، مانند
2026110401. اگر zone را ویرایش کنید و سریال را افزایش ندهید، سرورهای ثانویه داده قدیمی را ارائه میدهند. - Refresh: هر چند وقت یک بار سرور ثانویه سریال را بررسی میکند.
- Retry: پس از یک بررسی ناموفق، سرور ثانویه تا چه مدت صبر میکند و دوباره تلاش میکند.
- Expire: پس از این مدت بدون تماس، سرور ثانویه از پاسخ دادن باز میایستد.
- Minimum (TTL منفی): مدتی که ریزالورها پاسخهای «وجود ندارد» را کش میکنند.
اگر یک دامنه از نیمسرورهای مختلف پاسخهای متفاوت برمیگرداند، یک سرور ثانویه قدیمیشده علت محتمل است. شمارههای سریال همه سرورهای NS را با هم مقایسه کنید.
ریزالورهای Anycast
ریزالورهای عمومی، مانند ریزالورهایی که ارائهدهندگان بزرگ اداره میکنند، از anycast استفاده میکنند: یک آدرس IP یکسان از مراکز داده بسیاری اعلام میشود و شبکه هر پرسوجو را به نزدیکترین آنها هدایت میکند. این کار تأخیر کم و تابآوری را به همراه دارد. هر موقعیت کش مخصوص خود را دارد، به همین دلیل دو نفری که از یک آدرس ریزالور استفاده میکنند ممکن است پس از یک تغییر برای مدت کوتاهی پاسخهای متفاوتی ببینند. سرورهای ریشه و بسیاری از سرویسهای DNS معتبر هم از همین روش استفاده میکنند.
برای مبانی مرتبط، آدرس IP چیست و مدل OSI را بخوانید که DNS در آن در لایه کاربرد قرار دارد.