فرایند کامل تفکیک نام DNS — از مرورگر تا سرور ریشه چند گام طی می‌شود؟

1. روند کامل 8 مرحله‌ای

┌─────────────────────────────────────────────────────────────┐
│  مرورگر (Chrome / Firefox) — تایپ google.com                │
└────────────────┬────────────────────────────────────────────┘
                 │ ① کش DNS مرورگر (Chrome حدود 60s)
                 ↓ یافت نشد
┌─────────────────────────────────────────────────────────────┐
│  ریزالور stub سیستم‌عامل + کش DNS سیستم                      │
└────────────────┬────────────────────────────────────────────┘
                 │ ② در کش سیستم نیست ← ارسال استعلام UDP به روتر
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ارسال DNS روتر خانگی + کش روتر                             │
└────────────────┬────────────────────────────────────────────┘
                 │ ③ در کش روتر نیست ← ارسال به ریزالور بازگشتی ارائه‌دهنده اینترنت
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ریزالور بازگشتی ارائه‌دهنده اینترنت / عمومی (1.1.1.1 / 8.8.8.8 / 223.5.5.5) │
│  یافتن در کش: پاسخ مستقیم، کل فرایند 1-5ms                   │
│  نبود در کش: ورود به روند «استعلام کامل» در ادامه             │
└────────────────┬────────────────────────────────────────────┘
                 │ ④ از NS ریشه می‌پرسد «google.com کجاست؟»
                 ↓
        13 خوشه سرور نام ریشه (a~m.root-servers.net)
                 │ ⑤ پاسخ: «نمی‌دانم، از NS دامنه .com بپرس: a.gtld-servers.net»
                 ↓
        سرورهای معتبر TLD دامنه .com (Verisign)
                 │ ⑥ پاسخ: «من هم همه را ندارم، از NS دامنه google.com بپرس: ns1.google.com»
                 ↓
        سرورهای معتبر google.com (با مدیریت خود Google)
                 │ ⑦ پاسخ: «رکورد A دامنه google.com = 142.250.x.x»
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ⑧ ریزالور بازگشتی پاسخ را (طبق TTL) در کش ذخیره و          │
│     به کلاینت برمی‌گرداند — هر لایه در مسیر نیز               │
│     نسخه‌ای از آن را در کش نگه می‌دارد                        │
└─────────────────────────────────────────────────────────────┘

نکته کلیدی: در شرایط واقعی، روند کامل 8 مرحله‌ای تقریباً هرگز رخ نمی‌دهد. آدرس IP سایت‌های بزرگ تقریباً همیشه در کش ریزالور بازگشتی موجود است، بنابراین کاربران عادی فقط تا مرحله ④ پیش می‌روند و پاسخ می‌گیرند. فقط دامنه‌های کم‌شناخته، سایت‌هایی که مدت‌ها بازدید نشده‌اند، TTLهای منقضی‌شده یا دامنه‌های تازه ثبت‌شده روند کامل را فعال می‌کنند.

2. توضیح 5 لایه کش DNS

DNS از زمان طراحی در سال 1983 یک واقعیت را در نظر گرفته بود: تعداد استعلام‌ها 100,000 برابر تعداد تغییرات است. به همین دلیل کش همه‌جا وجود دارد و هر لایه داده را برای مدت TTL (Time To Live) نگه می‌دارد.

3. استعلام بازگشتی در برابر تکراری — مفاهیم کلیدی

3.1 بازگشتی (Recursive)

کلاینت (مرورگر / stub سیستم‌عامل) به ریزالور بازگشتی ارائه‌دهنده اینترنت می‌گوید: «IP دامنه google.com را برایم پیدا کن — برایم مهم نیست چطور.» ریزالور بازگشتی باید کل استعلام را کامل کند و نتیجه نهایی را برگرداند.

3.2 تکراری (Iterative)

وقتی ریزالور بازگشتی با سرورهای ریشه، TLD و معتبر صحبت می‌کند، این تبادل تکراری است — از ریشه می‌پرسد، ریشه می‌گوید «از .com بپرس»، سراغ .com می‌رود، .com می‌گوید «از google بپرس»، سراغ google می‌رود. هر مرحله فقط یک گام را طی می‌کند — این‌طور نیست که «من از ریشه بپرسم و ریشه همه‌چیز را برایم انجام دهد».

4. خودتان آزمایش کنید — dig +trace

dig +trace یک استعلام تکراری کامل را اجباری می‌کند و همه مراحل را نشان می‌دهد:

$ dig +trace cleanip.io

; <<>> DiG 9.10.6 <<>> +trace cleanip.io
;; global options: +cmd

؛ ① گام 1 — استعلام از ریشه (.)
.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
... (13 رکورد NS ریشه)
;; Received 525 bytes from 127.0.0.53#53 in 5 ms

؛ ② گام 2 — استعلام از TLD دامنه .io
io.                     172800  IN      NS      a0.nic.io.
io.                     172800  IN      NS      b0.nic.io.
... (4 NS دامنه .io)
;; Received 822 bytes from 198.41.0.4#53(a.root-servers.net) in 121 ms

؛ ③ گام 3 — استعلام از سرورهای معتبر cleanip.io
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 109 bytes from 156.154.150.6#53(a0.nic.io) in 53 ms

؛ ④ در نهایت پاسخ دریافت می‌شود
cleanip.io.             300     IN      A       104.21.x.x
cleanip.io.             300     IN      A       172.67.x.x
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 154 bytes from 173.245.59.108#53(nolan.ns.cloudflare.com) in 12 ms

تحلیل:

• کل فرایند 5 + 121 + 53 + 12 = 191 ms طول کشید — نخستین استعلام سرد واقعاً کند است
• اما استعلام همان دامنه یک ثانیه بعد فقط 1-2 ms طول می‌کشد، چون کش بازگشتی ارائه‌دهنده اینترنت آن را از قبل دارد (TTL برابر 300 ثانیه)
• 104.21.x.x / 172.67.x.x آدرس‌های CDN شرکت Cloudflare هستند — IP واقعی سرور مبدأ سایت ما پشت CDN پنهان است

5. توضیح TTL — کش واقعاً چه مدت باقی می‌ماند

TTL (Time To Live) فیلدی است که در آن سرور معتبر به همه ریزالورهای بازگشتی می‌گوید «حداکثر این مدت می‌توانید این را کش کنید»؛ واحد آن ثانیه است.

توجه: TTL «حداکثر زمان کش» است — هر ریزالور می‌تواند کش خود را زودتر پاک کند، اما هرگز نمی‌تواند آن را تمدید کند. بنابراین حتی اگر TTL سرور معتبر 1 ساعت باشد، برخی ریزالورها ممکن است فقط پس از 10 دقیقه دوباره استعلام کنند.

دام رایج: پیش از تغییر IP، ابتدا TTL را کوتاه کنید (1 تا 5 دقیقه) و صبر کنید تا TTL قبلی کاملاً منقضی شود، سپس جابه‌جا کنید — در غیر این صورت برخی کاربران تا بیش از یک ساعت همچنان به IP قدیمی می‌رسند.

6. راهنمای سریع انواع رکورد DNS

7. بهینه‌سازی DNS — چگونه تفکیک نام را سریع‌تر کنیم

7.1 یک ریزالور بازگشتی نزدیک انتخاب کنید

سرزمین اصلی چین: 223.5.5.5 (Alibaba) / 119.29.29.29 (DNSPod) سایت‌های داخلی را سریع‌تر از همه تفکیک می‌کنند. سایر نقاط: 1.1.1.1 (Cloudflare، با گسترده‌ترین پوشش Anycast) / 8.8.8.8 (Google). برای جزئیات بنگرید بهفهرست ریزالورهای DNS عمومی.

7.2 DoH (DNS-over-HTTPS) را فعال کنید

رمزگذاری استعلام‌های DNS از طریق HTTPS مانع می‌شود که ارائه‌دهنده اینترنت آن‌ها را ببیند یا دستکاری کند (و جلوی ربایش NXDOMAIN را می‌گیرد). Chrome، Firefox و Edge همگی از آن پشتیبانی می‌کنند — کافی است در تنظیمات فعالش کنید.

7.3 گرم‌کردن از پیش (DNS Prefetch)

<link rel="dns-prefetch" href="//api.example.com"> را به <head> سایت خود اضافه کنید تا مرورگر در زمان بیکاری آن را تفکیک کند — وقتی درخواست واقعی ارسال شود، پاسخ از کش می‌آید.

7.4 از CDN + NS با Anycast استفاده کنید

NS معتبر خود را روی Anycast (Cloudflare / Route 53) قرار دهید تا کاربران سراسر جهان به نزدیک‌ترین نمونه برسند — این کار تأخیر مرحله ③ را از 100ms به 10ms کاهش می‌دهد.

7.5 TTL را معقول تنظیم کنید

برای رکوردهایی که به‌ندرت تغییر می‌کنند (NS / MX)، TTL طولانی (1 تا 7 روز) تنظیم کنید؛ برای رکوردهای A که ممکن است جابه‌جا شوند، TTL کوتاه (5 تا 60 دقیقه) تنظیم کنید.

8. پرسش‌های متداول

8.1 DNS را تغییر دادم اما اتفاقی نیفتاد — چرا؟

ابتدا به TTL فعلی فکر کنید. پس از تغییر DNS، همه ریزالورهای بازگشتی تا منقضی شدن TTL قبلی همچنان IP قدیمی را برمی‌گردانند. «انتشار جهانی» معمولاً حدود 2 برابر TTL زمان می‌برد (به دلیل ناهمگام بودن ریزالورها با یکدیگر).

• کلاینت: ipconfig /flushdns (Windows) / sudo killall -HUP mDNSResponder (macOS)
• منتظر ماندن تا کش ریزالور بازگشتی عمومی منقضی شود: 1.1.1.1 / 8.8.8.8 هر کدام ابزار «purge» خود را برای پاک‌سازی دستی آن ارائه می‌دهند

8.2 برخی کاربران می‌توانند دسترسی داشته باشند و برخی نه — آلودگی DNS

هنگام دسترسی به سایت‌های خارجی از چین اصلی رایج است — GFW پاسخ‌های جعلی DNS تزریق می‌کند / ارائه‌دهندگان اینترنت (ISP) استعلام‌ها را ربایش می‌کنند. استفاده از DoH (DNS رمزگذاری‌شده مرورگر) می‌تواند بیشتر آلودگی‌های DNS را دور بزند.

8.3 چه مدت پس از ثبت دامنه می‌توانم از آن استفاده کنم؟

پس از ثبت، مرجع ثبت TLD رکوردهای NS شما را به سرورهای معتبر سطح بالای .com / .net و غیره ارسال می‌کند — معمولاً 15 دقیقه تا 24 ساعت. دامنه‌های .cn / .com.cn ممکن است پیش از تفکیک نام در چین اصلی به ثبت ICP نیاز داشته باشند.