DNS

DNS چه مشکلی را حل می‌کند؟

انسان‌ها با نام راحت‌تر کار می‌کنند (example.com)؛ شبکه اما فقط آدرس IP می‌فهمد. DNS همین شکاف را پر می‌کند و نام‌ها را به IP ترجمه می‌کند. نکته‌ی آزاردهنده این است که وقتی DNS خراب می‌شود، هیچ پیغام روشنی نمی‌گیرید — فقط «سایت باز نمی‌شود»، در حالی که سرور خودش کاملاً سالم و سرحال است. به همین دلیل اولین پرسشی که در عیب‌یابی باید بپرسید این است: «این مشکل از DNS است، از شبکه است یا از خود برنامه؟» خوشبختانه با یک ابزار ساده به اسم dig می‌توانید خودتان جواب این پرسش را پیدا کنید، بدون این‌که به کسی زنگ بزنید (!)

رکوردهای پرکاربرد

DNS در واقع یک پایگاه داده‌ی توزیع‌شده‌ی بزرگ است و هر نام می‌تواند چند نوع رکورد داشته باشد، هر کدام با کاربرد خودش:

رکوردنگاشتمثال کاربرد
Aنام → IPv4سایت روی سرور مشخص
AAAAنام → IPv6همان A برای IPv6
CNAMEنام → نام دیگرwww به‌عنوان نام مستعار example.com
MXسرور ایمیل دامنهدریافت ایمیل
TXTمتن دلخواهتأیید مالکیت دامنه، سیاست‌های SPF

در استقرار یک سرویس، یک راه رایج این است که رکورد A یک نام را مستقیماً به IP سرور خودتان اشاره دهید.

نکته

CNAME به یک نام دیگر اشاره می‌کند، نه به IP؛ همین یک لایه‌ی اضافه می‌تواند زنجیره‌ی Resolve را کمی طولانی‌تر کند.

فرایند Resolve و TTL

وقتی شما آدرس example.com را در مرورگر می‌زنید، این اتفاق‌ها پشت پرده رخ می‌دهد:

  1. سیستم شما از یک Resolver (سرور DNS تنظیم‌شده، معمولاً روتر خانه یا یک سرور DNS عمومی) سؤال می‌پرسد.
  2. اگر آن Resolver پاسخ را از قبل در Cache داشته باشد، همان را برمی‌گرداند؛ در غیر این صورت زنجیره‌ای از سرورهای DNS را طی می‌کند تا به سرور Authoritative همان دامنه برسد.
  3. پاسخ نهایی با یک عدد به نام TTL (Time To Live، به ثانیه) همراه می‌شود که می‌گوید این پاسخ چه مدت قابل Cache‌شدن است.

TTL برای کار DevOps اهمیت واقعی دارد: وقتی سرویسی را به IP جدید منتقل می‌کنید و رکورد DNS را عوض می‌کنید، هر کسی که پاسخ قدیمی را Cache کرده، تا پایان همان TTL همچنان به آدرس قبلی می‌رود. TTL کوتاه‌تر یعنی تغییرات سریع‌تر منتشر می‌شوند، اما قیمتش این است که تعداد Queryهای واقعی هم بیشتر می‌شود.

کار با dig و nslookup

ابزار اصلی این درس dig است. nslookup ساده‌تر و قدیمی‌تر است و روی ویندوز هم معمولاً از قبل نصب است؛ خوب است هر دو را بشناسید، اما در Linux عملاً همیشه سراغ dig می‌روید.

1dig example.com +short
2dig example.com A
3dig example.com AAAA
4dig example.com MX
5dig example.com TXT
  • +short فقط پاسخ نهایی را می‌دهد — گزینه‌ی خوب برای اسکریپت‌نویسی.
  • در خروجی کامل، ستونی به نام TTL برحسب ثانیه می‌بینید؛ اگر دستور را دوباره اجرا کنید و پاسخ از Cache بیاید، همین عدد کم‌کم پایین می‌رود.
  • با دستور dig @1.1.1.1 example.com +short می‌توانید مستقیماً از یک Resolver مشخص بپرسید — راه سریعی برای مقایسه‌ی دو Resolver با هم.

همان Queryها این بار با nslookup:

1nslookup example.com
2nslookup -type=MX example.com

تمرین

در VM این‌ها را اجرا کنید و نتیجه‌ها را با هم مقایسه کنید:

1dig github.com +short
2dig @1.1.1.1 github.com +short
3dig google.com TXT +short

بعد یک نام ساختگی را هم Query کنید (dig does-not-exist.example) تا پیام NXDOMAIN را با چشم خودتان ببینید؛ شناختن این پاسخ بعداً در عیب‌یابی خیلی به کارتان می‌آید — تفاوت «این نام واقعاً وجود ندارد» با «DNS جواب نمی‌دهد».

حالا یک سناریوی واقعی را در ذهن مجسم کنید: فرض کنید می‌خواهید یک سرویس را از سرور قدیمی به سرور جدید منتقل کنید و TTL رکورد A آن 3600 (یک ساعت) است. اگر همین الان رکورد را به IP جدید تغییر دهید، چه کسانی هنوز تا یک ساعت به سرور قدیمی می‌روند؟ اگر بخواهید این ریسک را کم کنید، چند ساعت قبل از مهاجرت باید TTL را کوتاه کنید؟ همین سؤال، دلیل واقعی است که چرا تیم‌های DevOps پیش از تغییرات مهم DNS، TTL را از قبل پایین می‌آورند.

منابع یادگیری

مستندات و مقالات

ویدیو