DNS چیست؟ DNS سامانه‌ای است که به دستگاه‌ها کمک می‌کند اطلاعات مربوط به یک نام دامنه را پیدا کنند؛ از جمله آدرس IP موردنیاز برای اتصال به وب‌سایت. وقتی نام سایت را در مرورگر وارد می‌کنید، معمولاً پیش از دریافت صفحه، دستگاه این آدرس را از طریق DNS پیدا می‌کند. بااین‌حال، DNS فایل‌های سایت را نگهداری نمی‌کند و پاسخ درست آن به‌تنهایی به معنای آماده بودن وب‌سایت نیست.
برای مدیریت دامنه، باید بدانید چه سرویسی پاسخ DNS آن را می‌دهد، رکوردها کجا تنظیم می‌شوند و تغییر هر تنظیم چه اثری دارد. در ادامه، مسیر پیدا شدن آدرس سرور را مرور می‌کنیم و تفاوت تغییر DNS دستگاه، نیم‌سرور دامنه و رکورد سایت را توضیح می‌دهیم.
DNS چیست و چه اطلاعاتی را نگهداری می‌کند؟
DNS کوتاه‌شدهٔ Domain Name System، به معنای «سامانهٔ نام دامنه» است. این سامانه ساختاری توزیع‌شده دارد؛ یعنی سرورهای مختلف اطلاعات نام‌ها را نگه می‌دارند و یک دفتر مرکزی واحد وجود ندارد. هر بخش از این ساختار می‌تواند مدیریت جداگانه‌ای داشته باشد.
برای وب‌سایت، کاربرد آشنای DNS پیدا کردن آدرس IP متناظر با نامی مانند www.example.com است. اما وظیفهٔ DNS به آدرس سایت محدود نمی‌شود؛ اطلاعات سرور دریافت ایمیل و اطلاعات تأیید مالکیت دامنه هم می‌توانند در رکوردهای آن قرار بگیرند. برای شناخت ساختار رکوردها و نقش سرورها، استاندارد پایهٔ DNS را بخوانید.
نام دامنه، سرویس DNS و محل میزبانی سه جزء متفاوت‌اند. دامنه نامی است که ثبت می‌کنید؛ DNS اطلاعات مربوط به آن نام را در اختیار درخواست‌کننده می‌گذارد؛ هاست یا سرور، برنامه و فایل‌های سایت را اجرا و نگهداری می‌کند. برای آشنایی با بخش میزبانی، مقالهٔ هاست چیست را بخوانید.
از وارد کردن نام سایت تا دریافت صفحه چه اتفاقی می‌افتد؟
فرض کنید می‌خواهید www.example.com را باز کنید و پاسخ موردنیاز در حافظهٔ موقت دستگاه یا مرورگر موجود نیست. دستگاه از یک سرویس حل نام بازگشتی، یا Recursive Resolver، کمک می‌گیرد. این سرویس ممکن است متعلق به ارائه‌دهندهٔ اینترنت، شبکهٔ سازمان یا یک ارائه‌دهندهٔ عمومی DNS باشد.
Resolver به نمایندگی از دستگاه، پاسخ را پیدا می‌کند. اگر پاسخ معتبر در کش آن موجود باشد، همان پاسخ را برمی‌گرداند. در غیر این صورت، بسته به اطلاعاتی که از قبل دارد، از سرورهای دیگر پرس‌وجو می‌کند. در یک مثال ساده که اطلاعات لازم در کش Resolver نیست، مسیر به این شکل پیش می‌رود:
- Resolver از سرور ریشه می‌پرسد برای پسوند .com به کدام سرورها مراجعه کند. سرور ریشه، مسیر ادامهٔ جست‌وجو را معرفی می‌کند.
- سپس از سرور پسوند .com، نیم‌سرورهای مسئول example.com را می‌گیرد. این مرحله، معرفی مرجع دامنه است؛ نه دریافت محتوای سایت.
- Resolver از نیم‌سرور مرجع دامنه، رکورد موردنیاز www.example.com را می‌پرسد. در این مثال، پاسخ رکورد A یک آدرس IPv4 است.
- پاسخ به دستگاه برمی‌گردد. مرورگر با استفاده از آدرس به‌دست‌آمده به مقصد وب متصل می‌شود و دریافت صفحه در ارتباطی جدا از پرس‌وجوی DNS انجام می‌گیرد.
این تفکیک در توضیح AWS دربارهٔ مسیر درخواست وب هم دیده می‌شود: ابتدا آدرس پیدا می‌شود و بعد مرورگر از مقصد، محتوای وب را درخواست می‌کند. اگر معماری سایت شامل CDN یا پراکسی باشد، آدرس پاسخ می‌تواند متعلق به همان واسطه باشد؛ بنابراین IP پاسخ DNS همیشه IP سرور اصلی سایت نیست.
لازم نیست برای هر بار باز کردن یک صفحه، همهٔ این مراحل تکرار شوند. کش دستگاه و Resolver می‌تواند بخشی از جست‌وجو یا تمام آن را حذف کند. همچنین در رکوردهایی مانند CNAME، ممکن است Resolver برای رسیدن به آدرس نهایی، نام دیگری را هم بررسی کند.
سرور DNS بازگشتی با نیم‌سرور مرجع چه تفاوتی دارد؟
«DNS سرور» نام کلی است و ممکن است به نقش‌های متفاوتی اشاره کند. Resolver بازگشتی پاسخ را برای دستگاه کاربر پیدا می‌کند و می‌تواند آن را موقتاً ذخیره کند. نیم‌سرور مرجع، یا Authoritative Nameserver، پاسخ محدودهٔ تحت مسئولیت خود را می‌دهد؛ مدیر دامنه رکوردها را در همین بخش تنظیم می‌کند. مستندات مفاهیم DNS کلودفلر این تفاوت را توضیح می‌دهد.
هنگام تغییر تنظیمات، شناخت این تفاوت اهمیت دارد. اگر DNS لپ‌تاپ را عوض کنید، سرویس حل نام مورد استفادهٔ آن دستگاه تغییر می‌کند. با این کار رکوردهای دامنهٔ کسب‌وکارتان را برای سایر کاربران ویرایش نکرده‌اید. برای تغییر مقصد سایت، باید سراغ DNS مرجع همان دامنه بروید.
سرور ریشه و سرور پسوند نیز مسئول معرفی مرحلهٔ بعد در سلسله‌مراتب‌اند. آن‌ها را نباید بانک آدرس همهٔ وب‌سایت‌ها یا واسطهٔ انتقال فایل‌های سایت دانست.
محصولات ابر آراد را ببینید و مشخصات هر سرویس را مقایسه کنید.
نِیم‌سرور، Zone و رکورد؛ هر تنظیم چه نقشی دارد؟
در تنظیمات دامنه معمولاً با Nameserver یا نیم‌سرور روبه‌رو می‌شوید. تنظیم نیم‌سرور در سامانهٔ ثبت‌کننده، به فرایند واگذاری پاسخ‌گویی دامنه به DNS مرجع مربوط است. پس از آن، مدیر دامنه باید رکوردها را در سرویس مرجع درست تنظیم کند. تغییر رکورد در پنلی که مرجع فعال دامنه نیست، لزوماً اثری بر پاسخ عمومی ندارد.
Zone محدوده‌ای از فضای نام DNS است که رکوردهای آن تحت مدیریت مشخصی قرار دارند. برای شروع، می‌توانید آن را مجموعهٔ اطلاعات تحت مدیریت DNS دامنه در نظر بگیرید؛ با این قید که مدیر دامنه می‌تواند یک زیردامنه را جداگانه واگذار و رکوردهای آن را در Zone دیگری تنظیم کند.
هر رکورد، نوع مشخصی از اطلاعات را نگهداری می‌کند. نمونه‌های متداول را در راهنمای انواع رکوردهای DNS ببینید:
| رکورد | چه چیزی مشخص می‌کند؟ | کاربرد متداول |
|---|---|---|
| A | آدرس IPv4 یک نام | معرفی مقصد وب‌سایت |
| AAAA | آدرس IPv6 یک نام | معرفی مقصد دارای IPv6 |
| CNAME | نام اصلیِ متناظر با یک نام مستعار | ارجاع یک زیردامنه به نامی دیگر |
| MX | نام سرور دریافت ایمیل و اولویت آن | معرفی مقصد ایمیل دامنه |
| TXT | متن وابسته به یک نام | تأیید مالکیت یا سیاست ارسال ایمیل |
| NS | نیم‌سرورهای مرجع یک محدوده | معرفی مرجع پاسخ‌گویی |
رکورد CNAME تغییر مسیر صفحه در مرورگر نیست؛ نام مستعار را در فرایند DNS به نام دیگری مرتبط می‌کند. همچنین رکورد A و AAAA شامل آدرس IP هستند، نه نشانی کامل صفحه یا مسیر فایل. برای نمونه، بخش /products/ در نشانی یک صفحه، موضوع تنظیم رکورد A نیست.
برای تغییر مقصد سایت، کدام بخش باید عوض شود؟
فرض کنید سایت را به سرور جدیدی منتقل کرده‌اید، اما می‌خواهید ثبت‌کننده و سرویس DNS فعلی را نگه دارید. در چنین سناریویی، معمولاً مقصد رکوردهای وب را متناسب با معماری جدید تغییر می‌دهید؛ صرف جابه‌جایی سایت، الزاماً به تغییر نیم‌سرورها نیاز ندارد.
اگر قرار است ارائه‌دهندهٔ DNS را هم عوض کنید، پیش از تغییر نیم‌سرورها باید رکوردهای لازم را در سرویس جدید آماده کنید. فقط رکورد وب را در نظر نگیرید؛ رکوردهای ایمیل، تأیید مالکیت و زیردامنه‌های فعال هم اهمیت دارند. این تغییر، به‌خودی‌خود فایل‌های سایت یا صندوق‌های ایمیل را منتقل نمی‌کند و به معنای انتقال ثبت دامنه نیست.
وقتی سرور مستقیماً میزبان یک سایت ساده است، آدرس DNS، تنظیم نام سایت در وب‌سرور و پیکربندی HTTPS باید با یکدیگر سازگار باشند. حتی اگر نام به IP موردنظر برسد، وب‌سرور باید برای همان نام پاسخ مناسب بدهد و مدیر سرویس باید گواهی معتبر همان نام را در محل پایان ارتباط HTTPS نصب کند.
چرا تغییر DNS برای همه هم‌زمان دیده نمی‌شود؟
دستگاه‌ها و سرورها ممکن است پاسخ DNS را در چند نقطه کش کنند؛ یعنی آن را برای استفادهٔ دوباره، موقتاً نگه دارند. TTL زمان مجاز نگهداری رکورد در کش را مشخص می‌کند. Resolverی که هنوز پاسخ قبلی را با زمان اعتبار باقی‌مانده دارد، ممکن است همان پاسخ را برگرداند؛ درحالی‌که کاربر دیگری پاسخ تازه را بگیرد. مستندات TTL ارتباط زمان کش با دیده شدن تغییرات را شرح می‌دهد.
بنابراین عبارت «انتشار DNS» را نباید به معنای فرستادن رکورد جدید به تک‌تک سرورهای اینترنت دانست. زمان مشاهدهٔ تغییر به نوع تغییر، کش‌های موجود و تنظیمات وابسته است؛ یک عدد ثابت برای تمام تغییرها دقیق نیست. کاهش TTL نیز اعتبار پاسخ‌های قبلیِ موجود در کش با TTL بالاتر را به‌صورت بازگشتی کوتاه نمی‌کند.
حتی پاسخ «این نام وجود ندارد» را هم دستگاه یا Resolver می‌تواند برای مدتی در کش نگه دارد. در نتیجه، پس از ایجاد یک نام تازه نیز ممکن است همهٔ کاربران فوراً نتیجهٔ یکسانی نبینند. این رفتار را استاندارد کش پاسخ‌های منفی DNS توضیح می‌دهد.
پاسخ DNS درست است؛ آیا سایت هم درست کار می‌کند؟
پاسخ DNS فقط یکی از بخش‌های بررسی دسترسی است. اگر نام به آدرس موردنظر می‌رسد اما صفحه باز نمی‌شود، باید اتصال شبکه، سرویس وب، تنظیمات نام سایت و HTTPS را هم بررسی کنید. خطای DNS و خطای برنامه را نباید با یک اقدام مشترک، مانند تغییر بی‌دلیل نیم‌سرورها، دنبال کرد.
برای بررسی اولیه، ابتدا مشخص کنید دربارهٔ کدام نام و کدام نوع رکورد صحبت می‌کنید. example.com و www.example.com دو نام متفاوت‌اند و نتیجهٔ یکی، صحت دیگری را ثابت نمی‌کند. سپس پاسخ مرجع را با پاسخ Resolver مقایسه کنید؛ تفاوت آن‌ها می‌تواند سرنخی از کش یا تنظیمات باشد، اما به‌تنهایی علت قطعی اختلال نیست. برای مشاهدهٔ رکوردها در ویندوز، راهنمای دستور Resolve-DnsName مسیر بررسی فنی را توضیح می‌دهد.
DNS به پیدا کردن مقصد کمک می‌کند، اما جای تنظیم وب‌سرور، راه‌اندازی ایمیل یا رمزگذاری ارتباط را نمی‌گیرد. با شناخت این مرز، هنگام راه‌اندازی یا جابه‌جایی سایت، تغییر را در بخش درست انجام می‌دهید و احتمال قطع سرویس‌های وابسته را کاهش می‌دهید.
اگر می‌خواهید DNS دامنه را برای وب‌سایت، ایمیل یا سرویس‌های پروژه‌تان مدیریت کنید، صفحهٔ DNS ابری ابر آراد را بررسی کنید. پیش از تغییر نیم‌سرورها، فهرست رکوردهای فعال و مقصد هر سرویس را آماده کنید؛ برای بررسی مسیر متناسب با پروژه نیز می‌توانید از مشاورهٔ ابر آراد کمک بگیرید.
از صفحه تماس ابر آراد، مسیر ارتباط با تیم را انتخاب کنید.
دیدگاه‌ها و پرسش‌های شما
تجربه یا پرسش خود را درباره موضوع مقاله با ما در میان بگذارید.
هنوز دیدگاهی ثبت نشده است؛ شما گفت‌وگو را شروع کنید.