DNS دقیقاً چیست؟
DNS مخفف Domain Name System است؛ یک سیستم نام گذاری توزیع شده که در سطح جهانی روی هزاران سرور مستقل اجرا می شود و کار اصلی آن ترجمه نام دامنه به آدرس IP است. کامپیوترها و روترها برای مسیریابی بسته های داده فقط با عدد IP کار می کنند، در حالی که انسان ها اسم را بهتر از عدد به خاطر می آورند؛ DNS دقیقاً همین شکاف را پر می کند. هر بار که آدرس یک سایت را در مرورگر تایپ می کنید، پیش از این که حتی یک بایت از محتوای سایت بارگذاری شود، یک درخواست DNS در پس زمینه ارسال و پاسخ آن دریافت می شود.
چرا به DNS نیاز داریم؟
فرض کنید DNS وجود نداشت؛ برای باز کردن هر سرویسی باید عدد IP دقیق آن را حفظ می کردید و با هر تغییر سرور (که در دنیای واقعی به دلایل مختلف مثل تعویض هاست یا مهاجرت به دیتاسنتر دیگر رخ می دهد)، تمام کاربران باید عدد جدید را یاد می گرفتند. DNS این مسئله را با یک لایه غیرمستقیم حل می کند: نام دامنه ثابت می ماند حتی اگر IP پشت آن چند بار عوض شود، فقط کافی است رکورد DNS به روزرسانی شود. همین ویژگی امکاناتی مثل توزیع بار بین چند سرور، سوییچ سریع در زمان قطعی، و مهاجرت بدون آسیب به کاربر نهایی را فراهم می کند.
ساختار سلسله مراتبی DNS
DNS یک پایگاه داده متمرکز نیست؛ یک ساختار درختی و توزیع شده است که در چند سطح مدیریت می شود:
- سرورهای ریشه (Root Servers): بالاترین سطح سلسله مراتب؛ ۱۳ مجموعه سرور ریشه در دنیا وجود دارد که آدرس سرورهای مسئول هر پسوند دامنه (TLD) را می شناسند
- سرورهای TLD: مسئول پسوندهایی مثل .com، .ir یا .org؛ می دانند سرور معتبر (Authoritative) هر دامنه زیرمجموعه خودشان کجاست
- سرورهای معتبر (Authoritative Nameserver): سرور نهایی که رکوردهای واقعی یک دامنه مشخص مثل trustit.ir را نگه می دارد و پاسخ قطعی می دهد
- سرور بازگشتی (Recursive Resolver): واسطه ای که از طرف کاربر این زنجیره را طی می کند تا پاسخ نهایی را پیدا کند
انواع رکوردهای DNS
هر دامنه شامل مجموعه ای از رکوردها است که هرکدام نوع مشخصی از اطلاعات را نگه می دارند. شناخت این رکوردها برای هر کسی که سایت، ایمیل یا سرویس آنلاین دارد ضروری است:
| نوع رکورد | کاربرد | مثال |
|---|---|---|
| A | اشاره دامنه به آدرس IPv4 | trustit.ir → 203.0.113.10 |
| AAAA | اشاره دامنه به آدرس IPv6 | trustit.ir → 2001:db8::1 |
| CNAME | اشاره یک نام به نام دیگر (نام مستعار) | www.trustit.ir → trustit.ir |
| MX | مشخص کردن سرور دریافت ایمیل دامنه | mail.trustit.ir با اولویت ۱۰ |
| TXT | ذخیره متن آزاد؛ اغلب برای تأیید مالکیت و امنیت ایمیل (SPF/DKIM) | "v=spf1 include:..." |
| NS | معرفی سرورهای معتبر دامنه | ns1.trustit.ir |
| SOA | اطلاعات مدیریتی زون از جمله سریال و زمان بندی بروزرسانی | شماره سریال، TTL پیش فرض |
| PTR | ترجمه معکوس IP به نام دامنه | 10.113.0.203 → trustit.ir |
رکورد PTR دقیقاً برعکس رکورد A عمل می کند و روی سرور DNS ارائه دهنده IP (نه ارائه دهنده دامنه) تنظیم می شود؛ نبود PTR صحیح یکی از دلایل رایج افتادن ایمیل های سازمانی در پوشه اسپم است.
فرآیند Resolution قدم به قدم
وقتی آدرسی مثل www.trustit.ir را در مرورگر تایپ می کنید، این زنجیره در کسری از ثانیه طی می شود:
- مرورگر ابتدا کش محلی خودش و سیستم عامل را بررسی می کند؛ اگر پاسخ آن جا موجود باشد، فرآیند همین جا تمام می شود
- در غیر این صورت درخواست به سرور بازگشتی (معمولاً سرور DNS تنظیم شده روی روتر یا ISP) ارسال می شود
- سرور بازگشتی، اگر خودش پاسخ را در کش نداشته باشد، از یکی از سرورهای ریشه می پرسد که سرور TLD مربوط به «.ir» کجاست
- سرور ریشه آدرس سرور TLD را برمی گرداند؛ سرور بازگشتی از سرور TLD می پرسد سرور معتبر «trustit.ir» کجاست
- سرور TLD آدرس سرور معتبر (Authoritative) دامنه را برمی گرداند
- سرور بازگشتی مستقیماً از سرور معتبر trustit.ir رکورد A را درخواست می کند و آدرس IP نهایی را دریافت می کند
- سرور بازگشتی پاسخ را هم به مرورگر برمی گرداند و هم برای درخواست های بعدی در کش خودش ذخیره می کند
در عمل این هفت مرحله معمولاً کمتر از چند دهم ثانیه طول می کشد، چون بخش زیادی از پاسخ ها (به خصوص سرورهای ریشه و TLD) از قبل در کش سرورهای بازگشتی موجود هستند و مرحله کامل فقط برای دامنه های تازه یا کم استفاده اجرا می شود.
کش DNS و مفهوم TTL
برای این که هر درخواست مجبور نباشد کل زنجیره بالا را طی کند، هر پاسخ DNS به همراه یک مقدار TTL (Time To Live) برگردانده می شود که مشخص می کند آن پاسخ چند ثانیه معتبر است. تا زمانی که TTL منقضی نشده، سرورهای بازگشتی و حتی مرورگر همان پاسخ کش شده را بدون پرسیدن دوباره استفاده می کنند. TTL کوتاه (مثلاً ۳۰۰ ثانیه) یعنی تغییرات سریع تر در دنیا منتشر می شود اما بار بیشتری روی سرور DNS می گذارد؛ TTL بلند (مثلاً ۲۴ ساعت یا بیشتر) بار کمتری دارد اما تغییر IP کندتر به همه جا می رسد.
پیش از هر تغییر بزرگ (مثل مهاجرت سایت به هاست جدید)، حداقل چند روز زودتر TTL رکورد را کاهش دهید. اگر TTL روی مقدار بالا مانده باشد، بعد از تغییر IP بخشی از کاربران تا ساعت ها همچنان به سرور قدیمی هدایت می شوند.
سرور بازگشتی در مقابل سرور معتبر
یکی از رایج ترین اشتباه های مفهومی، یکسان دانستن این دو نوع سرور است، در حالی که نقش کاملاً متفاوتی دارند:
| ویژگی | سرور بازگشتی (Recursive) | سرور معتبر (Authoritative) |
|---|---|---|
| نقش | واسطه ای که از طرف کاربر جستجو می کند | منبع نهایی و رسمی اطلاعات یک دامنه مشخص |
| نمونه | 1.1.1.1، 8.8.8.8، DNS ارائه شده توسط ISP | ns1.trustit.ir، سرورهای رجیستراری که دامنه در آن مدیریت می شود |
| کش می کند؟ | بله، برای کاهش بار و افزایش سرعت | معمولاً نه؛ همیشه پاسخ به روز و رسمی می دهد |
سرورهای DNS عمومی محبوب
در کنار DNS ارائه شده توسط ISP، سرورهای DNS عمومی و رایگانی هم وجود دارند که معمولاً سرعت و پایداری بالاتری ارائه می دهند؛ رایج ترین آن ها 8.8.8.8 و 8.8.4.4 از گوگل، و 1.1.1.1 و 1.0.0.1 از Cloudflare هستند که علاوه بر سرعت، روی حریم خصوصی و رمزنگاری درخواست هم تمرکز دارند. برای کاربران و کسب و کارهای داخل ایران، توجه به تحریم و فیلترینگ در انتخاب DNS اهمیت دارد؛ به همین دلیل استفاده از DNSهای داخلی معتبر یا سرویس های تخصصی مثل شکن (403.online) هم در کنار گزینه های بین المللی رایج است.
امنیت DNS: DNSSEC، Spoofing و DoH/DoT
پروتکل اصلی DNS از ابتدا برای امنیت طراحی نشده بود و همین موضوع آن را هدف چند نوع حمله رایج کرده است. DNS Spoofing یا Cache Poisoning زمانی رخ می دهد که یک مهاجر پاسخ جعلی را جای پاسخ واقعی در کش سرور بازگشتی جا می زند تا کاربر به جای سایت واقعی به یک سرور مخرب هدایت شود. برای مقابله با این تهدید، DNSSEC با امضای دیجیتال رکوردها، اصالت و صحت پاسخ را تضمین می کند. در لایه دیگر، پروتکل های DNS over HTTPS (DoH) و DNS over TLS (DoT) با رمزنگاری کل ترافیک DNS، از شنود یا دستکاری درخواست ها در مسیر شبکه جلوگیری می کنند.
عیب یابی مشکلات رایج DNS
بخش زیادی از مشکلات «سایت بالا نمی آید» یا «ایمیل نمی رسد» در واقع ریشه در DNS دارند، نه در خود سرویس. ابزارهای خط فرمان nslookup و dig (روی لینوکس/مک) یا Resolve-DnsName (روی ویندوز) امکان بررسی مستقیم رکوردهای یک دامنه را می دهند و اولین قدم عیب یابی محسوب می شوند.
- اگر سایت برای بعضی کاربران بالا می آید و برای بعضی نه، معمولاً مسئله کش DNS محلی یا تفاوت TTL بین سرورهای مختلف است
- اگر ایمیل نمی رسد، ابتدا رکوردهای MX، SPF و DKIM را با ابزار dig بررسی کنید
- خطای NXDOMAIN یعنی دامنه اصلاً در سرور معتبر پیدا نشده؛ اغلب به دلیل تایپ اشتباه یا انقضای دامنه است
- خطای SERVFAIL معمولاً نشان دهنده مشکل در پیکربندی DNSSEC یا از دسترس خارج بودن سرور معتبر است
نقش DNS در زیرساخت شبکه سازمانی
در مقیاس یک سازمان، DNS فقط برای باز کردن سایت به کار نمی رود؛ سرویس هایی مثل Active Directory برای شناسایی دامین کنترلرها، سرورهای ایمیل داخلی، و حتی بسیاری از اپلیکیشن های داخلی به یک DNS داخلی سالم وابسته اند. قطعی یا کندی DNS داخلی می تواند کل شبکه سازمانی را بدون این که خود اینترنت مشکلی داشته باشد، عملاً متوقف کند. به همین دلیل توصیه استاندارد داشتن حداقل دو سرور DNS داخلی افزونه، مانیتورینگ سلامت این سرویس، و پشتیبان گیری منظم از زون های DNS است.
DNS چه ارتباطی با سرعت باز شدن سایت دارد؟
چرا بعد از تغییر IP، سایت من هنوز به سرور قدیمی می رود؟
تفاوت رکورد A و CNAME چیست؟
آیا می شود چند سرور DNS برای یک دامنه تنظیم کرد؟
DNSSEC چه چیزی را تضمین می کند؟
پیشنهاد آیتی مطمئن
تیم آیتی مطمئن پیکربندی، افزونه سازی و مانیتورینگ DNS داخلی و عمومی سازمان شما را به صورت حرفه ای انجام می دهد تا هیچ سرویسی به خاطر یک رکورد اشتباه یا سرور از دسترس خارج شده متوقف نشود.
مشاوره رایگان زیرساخت شبکه
بدون دیدگاه