مبانی DNS

جریان حل DNS (DNS Resolution Flow)

مسیر کامل پرس‌وجوها و پاسخ‌ها که نام دامنه‌ای مانند www.example.com را به آدرسی IP تبدیل می‌کند که کامپیوتر بتواند به آن متصل شود.

1. چرا این موضوع مهم است

درک جریان حل DNS برای عیب‌یابی، بهینه‌سازی کارایی، طراحی معماری و امنیت ضروری است.

عیب‌یابی اتصالطراحی معماری DNSکارایی و کشینگسخت‌سازی امنیت (Security Hardening)

هدف

وقتی شما وارد می‌کنید https://www.example.com، سیستم باید پاسخ بدهد:

"برای www.example.com باید به کدام آدرس IP متصل شوم؟"
پاسخ dns
www.example.com → 93.184.216.34

2. جریان حل — گام‌به‌گام

تمام مراحل از مرورگر تا سرورهای Authoritative، شامل کش‌های محلی.

01
کش مرورگرمحلیCache Hit

مرورگر کش DNS خودش را بررسی می‌کند. اگر ورودی معتبر موجود باشد، همان IP فوراً استفاده می‌شود — هیچ پرس‌وجویی ارسال نمی‌شود.

www.example.com سی ثانیه پیش باز شده است → IP کش‌شده دوباره استفاده می‌شود
02
کش سیستم‌عامل و فایل HostsمحلیCache Hit

سیستم‌عامل ابتدا /etc/hosts را بررسی می‌کند، سپس کش DNS خودش را. اگر پیدا کند، پاسخ را به اپلیکیشن برمی‌گرداند.

203.0.113.10 intranet.example.com (ورودی در فایل hosts)
03
Recursive ResolverشبکهResolver

پرس‌وجو به یک Resolver (مثل DNS ISP یا 8.8.8.8 یا 1.1.1.1) ارسال می‌شود. Resolver ابتدا کش خودش را بررسی می‌کند.

سرور DNS: 8.8.8.8 (گوگل) یا 1.1.1.1 (Cloudflare)
04
سرور RootRecursiveDelegation

Resolver از یک سرور Root می‌پرسد: «چه کسی .com را مدیریت می‌کند؟» Root فهرست سرورهای TLD را برمی‌گرداند.

.com → a.gtld-servers.net, b.gtld-servers.net ...
05
سرور TLD .comRecursiveDelegation

Resolver از سرور TLD می‌پرسد: «سرورهای Authoritative دامنه example.com کدام هستند؟» و رکوردهای NS را دریافت می‌کند.

example.com. IN NS ns1.dnsprovider.com.
06
سرور AuthoritativeRecursiveAnswer

Resolver از ns1.dnsprovider.com رکورد A را می‌پرسد و پاسخ نهایی را دریافت می‌کند.

www.example.com. IN A 93.184.216.34
07
کش و بازگرداندن پاسخبازگشتResponse

Resolver نتیجه را بر اساس TTL کش می‌کند، IP را به سیستم‌عامل برمی‌گرداند. سیستم‌عامل آن را کش کرده و به مرورگر می‌دهد.

www.example.com → 93.184.216.34 (TTL = 3600s)
08
اتصال TCPبازگشتDone

مرورگر یک اتصال TCP به IP به‌دست‌آمده روی پورت 80/443 برقرار می‌کند. صفحه شروع به بارگذاری می‌کند.

TCP → 93.184.216.34:443 → TLS → HTTP/2

3. نگاهی سریع به سلسله‌مراتب DNS

سه لایه واگذاری (Delegation) از ریشه تا رسیدن به پاسخ نهایی.

سرورهای Root

13 خوشه · . (نقطه)

سرورهای TLD .com

a.gtld-servers.net …

Name Serverهای Authoritative

ns1.dnsprovider.com

پاسخ نهایی

93.184.216.34 (TTL 3600)

4. مثال کامل

تمام 10 گام برای حل www.example.com، از لحظه تایپ تا برقراری اتصال TCP.

مثال کامل — www.example.com

1
عمل کاربر—شما در مرورگر www.example.com را تایپ می‌کنید.
2
کش مرورگر—مرورگر کش DNS را بررسی می‌کند — اگر Hit باشد همان استفاده می‌شود؛ اگر نباشد، از سیستم‌عامل می‌پرسد.
3
کش سیستم‌عامل / فایل hosts—ورودی‌ای پیدا نمی‌شود. سیستم‌عامل پرس‌وجو را به Resolver تنظیم‌شده (مثلاً 8.8.8.8) می‌فرستد.
4
کش Resolver—اگر Resolver قبلاً پاسخ را کش کرده باشد، IP را برمی‌گرداند؛ در غیر این صورت، حل Recursive را شروع می‌کند.
5
پرس‌وجو به Root—Resolver → Root: «چه کسی .com را مدیریت می‌کند؟» فهرست سرورهای TLD را دریافت می‌کند.
6
پرس‌وجو به TLD—Resolver → سرور TLD .com: «سرور Authoritative برای example.com کدام است؟» رکوردهای NS را دریافت می‌کند.
7
پرس‌وجو به سرور Authoritative—Resolver → ns1.dnsprovider.com: «رکورد A برای www.example.com؟» پاسخ 93.184.216.34 را می‌گیرد.
8
کش و پاسخ—Resolver نتیجه را کش کرده و 93.184.216.34 را به سیستم‌عامل برمی‌گرداند.
9
کش سیستم‌عامل و اپلیکیشن—سیستم‌عامل IP را کش کرده و آن را به مرورگر می‌دهد.
10
اتصال—مرورگر به 93.184.216.34 متصل شده و وب‌سایت را بارگذاری می‌کند.

5. حل Recursive در برابر Iterative

کلاینت رفتار Recursive دارد؛ Resolver درون خودش پرس‌وجوهای Iterative انجام می‌دهد.

RecursiveRecursive (کلاینت → Resolver)
  • ·کلاینت فقط یک‌بار می‌پرسد و منتظر پاسخ نهایی می‌ماند
  • ·Resolver مسئولیت تمام پرس‌وجوهای بعدی را بر عهده می‌گیرد
  • ·کلاینت یا یک IP حل‌شده دریافت می‌کند یا خطا
recursive query
client → resolver: "What is www.example.com?"
resolver → client: "93.184.216.34"
IterativeIterative (Resolver → سرورهای DNS)
  • ·Resolver هر سرور را در سلسله‌مراتب به‌ترتیب کوئری می‌کند
  • ·هر سرور یا پاسخ می‌دهد یا به سرور بعدی ارجاع می‌کند
  • ·Resolver کل پیمایش را انجام می‌دهد؛ کلاینت درگیر نمی‌شود
iterative query
resolver → root:  "Where is .com?"
resolver → TLD:   "Where is example.com?"
resolver → auth:  "A record for www.example.com?"

6. وقتی چیزی خراب می‌شود چه اتفاقی می‌افتد؟

سه حالت خرابی رایج و نحوه تشخیص آن‌ها.

از کار افتادن سرور Authoritative"Server not found" / DNS timeout

اگر ns1 و ns2 هر دو در دسترس نباشند، هیچ پرس‌وجوی جدیدی برای example.com قابل حل نیست. نتایجی که در کش هستند تا زمان انقضای TTL همچنان کار می‌کنند.

خروجی خطا
ns1.dnsprovider.com — unreachable
ns2.dnsprovider.com — unreachable
→ SERVFAIL
NXDOMAIN — دامنه پیدا نشدخطای NX­DOMAIN

سرور Authoritative تأیید می‌کند که این نام وجود ندارد. Resolver ممکن است این پاسخ منفی را کش کند تا از پرس‌وجوهای تکراری جلوگیری شود.

خروجی خطا
query: doesnotexist.example.com
auth server: NXDOMAIN (negative TTL cached)
پیکربندی نادرست رکوردهاشکست ایمیل / مشکلات متناوب DNS

حلقه‌های CNAME، نبودن رکورد A برای هدف MX، یا رکوردهای NS اشتباه هرکدام بخش متفاوتی از جریان را خراب می‌کنند.

خروجی خطا
a.example.com → CNAME b.example.com
b.example.com → CNAME a.example.com
→ CNAME loop / SERVFAIL

7. اهمیت جریان حل DNS در عمل

چهار حوزه عملی که این دانش به‌طور مستقیم کاربرد دارد.

تنظیم کارایی (Performance)
  • ·استفاده از Resolverهای نزدیک‌تر / سریع‌تر
  • ·TTL کوتاه → به‌روزرسانی سریع
  • ·TTL بلند → بار کمتر روی سرورها
دردسترس‌بودن بالا (High Availability)
  • ·چند رکورد NS برای افزونگی
  • ·چند رکورد A/AAAA برای توزیع بار
عیب‌یابی
  • ·ابزارهایی مثل dig، nslookup و host هر مرحله را نشان می‌دهند
  • ·بررسی اینکه از کدام Name Serverها استفاده می‌شود
  • ·تأیید رفتار کشینگ
امنیت
  • ·پیش‌نیاز پیاده‌سازی DNSSEC
  • ·تشخیص Cache Poisoning
  • ·شناسایی هدایت‌های مخرب (Malicious Redirection)

8. جمع‌بندی

خلاصه‌ای فشرده از فرایند حل DNS از بررسی‌های محلی تا اتصال نهایی.

جمع‌بندی کوتاه

حل DNS مسیری انتها‌به‌انتها از نام دامنه تا آدرس IP آن است. این فرایند شامل موارد زیر است:

1.بررسی‌های محلی — کش مرورگر، فایل hosts، کش سیستم‌عامل
2.Recursive Resolver — DNS شرکت، ISP یا عمومی
3.بررسی کش در سطح Resolver
4.پرس‌وجوها: Root → TLD → سرورهای Authoritative
5.نتیجه بر اساس TTL کش شده و به کلاینت بازگردانده می‌شود

دانشی ضروری برای: مهندسان شبکه · ادمین‌های سیستم · مهندسان امنیت · توسعه‌دهندگان