تفاوت DNS و Nameserver چیست و چرا این دو را با هم اشتباه می‌گیریم؟

سال‌ها پیش در پروژه‌ای که سایت مشتری روی یک هاست ایرانی بود، مدیر فنی سرور با اطمینان گفت مشکل DNS را حل کرده، چون Nameserver را عوض کرده. وقتی لاگ درخواست‌ها را باز کردم، دیدم Nameserver جدید روی سروری تنظیم شده که رکوردهای A آن به IP اشتباه اشاره می‌کرد و سرویس‌دهی همان Nameserver در وضعیت نامطمئن بود. آن روز دوباره یادآوری شد که تفاوت DNS و Nameserver، به‌ظاهر فنی و پیش‌پاافتاده است، اما در عمل، بیشترین سردرگمی‌ها در مدیریت دامنه از همین دو کلمه شروع می‌شود. این مقاله از دید کسی نوشته شده که روی ده‌ها سرور و دامنه کار کرده و یاد گرفته که این دو، دو لایه از یک سیستم هستند، نه دو نام برای یک چیز.

DNS و Nameserver دقیقاً چه هستند؟

پیش از ورود به تفاوت‌ها، تعریف دقیق هر یک ضروری است. سردرگمی رایج، ناشی از یکسان فرض کردن این دو کلمه است، در حالی که هر یک، به لایه متفاوتی از سیستم اشاره دارد.

DNS (Domain Name System) یک سیستم توزیع‌شده است که نام‌های دامنه را به آدرس‌های IP تبدیل می‌کند. DNS یک پروتکل، یک استاندارد و یک مجموعه از سرورهاست که در سراسر اینترنت توزیع شده‌اند. DNS لایه نرم‌افزاری و منطقی است که در قالب مجموعه‌ای از قراردادها، داده‌ها و مکانیزم‌های جستجو تعریف می‌شود.

Nameserver یک سرور مشخص است که در آن، رکوردهای DNS یک دامنه نگهداری می‌شود. Nameserver، پیاده‌سازی فیزیکی یا منطقی DNS برای یک دامنه خاص است. وقتی می‌گوییم Nameserver فلان دامنه، یعنی سروری که پاسخ‌های DNS آن دامنه را ارائه می‌دهد.

پس تفاوت بنیادی: DNS یک سیستم است؛ Nameserver یک سرور در آن سیستم. اگر با مفاهیم پایه آشنا نیستید، مرور کلی در DNS چیست و چگونه کار می‌کند نقطه شروع خوبی است. این مقاله، تفاوت‌ها را در سطح عمیق‌تر و با تمرکز بر مرز دقیق بین این دو مفهوم باز می‌کند.

DNS، زبان اینترنت است. Nameserver، کتابخانه‌ای است که این زبان را برای یک دامنه خاص نگه می‌دارد. بدون زبان، کتابخانه معنا ندارد؛ بدون کتابخانه، زبان کاربردی ندارد.

تشبیه دقیق برای تفکیک دو لایه

تشبیه‌ای که در جلسات مشاوره زیاد استفاده می‌کنم: DNS مانند سیستم پستی بین‌المللی است که قواعد ارسال نامه بین کشورها را تعریف می‌کند. Nameserver مانند اداره پست منطقه‌ای یک شهر خاص است که می‌داند کدام خانه، کدام آدرس را دارد.

در این تشبیه:

• قواعد ارسال نامه بین کشورها (DNS): سیستمی که همه ادارات پست از آن پیروی می‌کنند. یک سیستم واحد با قواعد یکسان.
• اداره پست منطقه‌ای (Nameserver): نهاد محلی که برای یک دامنه خاص، پاسخ‌گوی اصلی است.
• آدرس خانه‌ها (رکوردهای DNS): اطلاعات دقیقی که هر اداره پست نگه می‌دارد؛ مثل این‌که خانه X در فلان کوچه، با کد پستی Y است.
• فرستادن نامه (Query): وقتی شما نامه‌ای می‌فرستید، اداره پست مناطق مختلف را می‌گردد تا آدرس صحیح را پیدا کند.

این تفکیک، در پروژه‌ها کاربردی است. وقتی مشتری می‌گوید DNS سایت مشکل دارد، اولین سؤال من این است: DNS (سیستم) مشکل دارد یا Nameserver (سرور) مشکل دارد؟ این دو، دو مسیر عیب‌یابی متفاوت دارند و گاهی پاسخ‌های متفاوتی می‌دهند.

معماری سه‌لایه DNS

برای درک عمیق تفاوت DNS و Nameserver، باید معماری درونی DNS را در سه لایه باز کرد:

نکته کلیدی: Nameserver شما، در لایه Authoritative قرار می‌گیرد. یعنی، سروری که پاسخ نهایی را برای یک دامنه خاص ارائه می‌دهد. سه لایه دیگر — ریشه، TLD و Resolver — بخشی از سیستم عمومی DNS هستند و توسط شما مدیریت نمی‌شوند.

این تفکیک، در سناریوهای عیب‌یابی حیاتی است. اگر مشکل از لایه ریشه یا TLD باشد، شما کاری نمی‌توانید بکنید جز انتظار یا تماس با ثبت‌کننده. اگر مشکل از Resolver باشد، می‌توانید از Resolver دیگری (مثلاً Google 8.8.8.8 یا Cloudflare 1.1.1.1) استفاده کنید. اگر مشکل از Nameserver خودتان باشد، می‌توانید در آن مداخله کنید.

لایه Resolver: جستجوی بازگشتی

Resolver یا Recursive Resolver، اولین لایه‌ای است که با کاربر تعامل دارد. وقتی کاربری در مرورگر خود آدرس example.com را وارد می‌کند، اولین جستجو به Resolver می‌رود. اگر Resolver پاسخ را در Cache خود داشته باشد، آن را برمی‌گرداند. در غیر این صورت، جستجوی بازگشتی (Recursive Lookup) را آغاز می‌کند.

مراحل جستجوی بازگشتی:

1. پرسش به سرور ریشه: Resolver به یکی از سیزده سرور ریشه می‌پرسد که مسئول دامنه .com کیست.
2. پاسخ از سرور ریشه: سرور ریشه، آدرس سرورهای TLD مربوط به .com را برمی‌گرداند.
3. پرسش به سرور TLD: Resolver به سرور TLD .com می‌پرسد که Nameserver مثال دامنه example.com چیست.
4. پاسخ از سرور TLD: سرور TLD، آدرس Nameserver دامنه را برمی‌گرداند.
5. پرسش به Nameserver: Resolver به Nameserver دامنه می‌پرسد که رکورد A example.com چیست.
6. پاسخ نهایی: Nameserver، آدرس IP را برمی‌گرداند و Resolver آن را به کاربر تحویل می‌دهد.

نکته مهم: Resolver معمولاً در نزدیکی کاربر قرار دارد (از طریق ISP یا سرویس‌های عمومی مثل Google Public DNS، Cloudflare 1.1.1.1 یا Quad9). Nameserver معمولاً نزدیک سرور دامنه قرار دارد. این تفاوت در مسیر، دلیل تفاوت زمان پاسخ در سناریوهای مختلف است. راهنمای بهبود سرعت DNS در چگونه سرعت DNS را بهبود دهیم آمده است.

لایه Authoritative: صاحب حقیقت

لایه Authoritative، جایی است که Nameserver شما نشسته. این لایه، حقیقت نهایی درباره یک دامنه را نگه می‌دارد. اگر بپرسید رکورد A دامنه example.com چیست، پاسخ نهایی از این لایه می‌آید. تفاوت مهم این لایه با Resolver در این است که Resolver پاسخ‌ها را از منابع مختلف جمع می‌کند و Cache می‌کند، اما Authoritative Server پاسخ‌های خودش را از یک منبع مشخص (فایل Zone یا پایگاه داده داخلی) می‌دهد.

در لایه Authoritative، دو مفهوم کلیدی وجود دارد:

• Primary Nameserver (Master): Nameserver اصلی که همه تغییرات در آن اعمال می‌شود. Owner یا ادمین، رکوردها را در این سرور تعریف یا ویرایش می‌کند.
• Secondary Nameserver (Slave): Nameserver ثانویه که از Primary، کپی می‌گیرد. این کار برای تحمل خطا (Redundancy) انجام می‌شود. اگر Primary از دسترس خارج شود، Secondary پاسخ‌دهی را ادامه می‌دهد.

قاعده استاندارد در اینترنت، حداقل دو Nameserver جداگانه است. این دو Nameserver باید روی زیرساخت‌های متفاوت یا حداقل شبکه‌های متفاوت باشند تا از قطعی هم‌زمان جلوگیری شود. در پروژه‌هایی که سایت‌ها روی هاست اشتراکی بودند، بارها دیده‌ام که هر دو Nameserver روی یک سرور قرار داشتند و با قطعی سرور، کل دامنه از دسترس خارج می‌شد. در پیکربندی حرفه‌ای، این کار اشتباه است.

Delegation: چطور کنترل دامنه منتقل می‌شود؟

Delegation یا واگذاری، مکانیزمی است که در آن، مسئولیت پاسخ‌دهی به سؤالات DNS یک دامنه، از یک لایه به لایه دیگر منتقل می‌شود. وقتی شما یک دامنه ثبت می‌کنید، ثبت‌کننده (Registrar) به سرورهای TLD می‌گوید که Nameserver این دامنه فلان آدرس است. از آن لحظه، هر پرسش درباره این دامنه، توسط همان Nameserver پاسخ داده می‌شود.

پس تفاوت بنیادی بین DNS و Nameserver در سطح Delegation روشن می‌شود: DNS، مکانیزم Delegation و Query و Response را تعریف می‌کند؛ Nameserver، نقطه پایانی (Endpoint) در این مکانیزم است که به‌طور مشخص پاسخ‌دهی یک دامنه را بر عهده دارد.

در پروژه‌های مهاجرت، این تفکیک حیاتی است. وقتی می‌خواهید دامنه را از یک هاست به هاست دیگر منتقل کنید، دو گزینه دارید:

• گزینه اول — تغییر Nameserver: آدرس Nameserver دامنه در پنل Registrar را از Nameserver قبلی به Nameserver جدید تغییر می‌دهید. این کار، کل کنترل DNS دامنه را به سرور جدید منتقل می‌کند.
• گزینه دوم — تغییر رکوردها: Nameserver را دست‌نخورده نگه می‌دارید و فقط رکوردهای DNS (مثل A، CNAME، MX) را ویرایش می‌کنید. این کار، کنترل Nameserver را حفظ می‌کند اما مسیر ترافیک را تغییر می‌دهد.

انتخاب بین این دو گزینه، تابع سناریوی مهاجرت است. اگر کل زیرساخت را عوض می‌کنید، گزینه اول مناسب است. اگر فقط می‌خواهید یک سرویس خاص را جابه‌جا کنید، گزینه دوم تمیزتر است. مسیر گام‌به‌گام اتصال دامنه به هاست در چگونه هاست را به دامنه متصل کنیم آمده است، و مسیر مقابل در چگونه دامنه را به هاست متصل کنیم.

رکوردهای کلیدی DNS و نقش هرکدام

برای درک عمیق‌تر، رکوردهای DNS را در سه دسته مرور می‌کنیم. هر کدام، نقش مشخصی در سیستم دارند:

• رکوردهای آدرس‌دهی: A (آدرس IPv4)، AAAA (آدرس IPv6) و CNAME (نام مستعار). این‌ها تعیین می‌کنند که دامنه شما به کدام IP یا دامنه دیگر اشاره کند.
• رکوردهای سرویس: MX (سرور ایمیل)، TXT (متن آزاد برای SPF، DKIM، DMARC، Google Verification) و SRV (سرویس‌های خاص). این‌ها نقش سرویس‌های جانبی را مشخص می‌کنند.
• رکوردهای ساختاری: NS (Nameserver) و SOA (Start of Authority). این‌ها چارچوب ساختاری دامنه را تعریف می‌کنند.

فهرست کامل رکوردها در رکوردهای DNS کدامند آمده است. این‌جا فقط به دو رکورد کلیدی برای موضوع ما می‌پردازیم.

رکوردهای NS و SOA در برابر یکدیگر

رکورد NS و رکورد SOA، دو رکورد ساختاری مهم در DNS هستند که اغلب با هم اشتباه گرفته می‌شوند.

رکورد NS (Name Server): مشخص می‌کند کدام Nameserver مسئول پاسخ‌دهی به سؤالات یک دامنه یا زیردامنه است. این رکورد در سطح Registrar، در سطح دامنه اصلی و در سطح زیردامنه‌ها وجود دارد. مثلاً رکورد NS دامنه example.com به ns1.example.com و ns2.example.com اشاره می‌کند.

رکورد SOA (Start of Authority): اطلاعات ساختاری درباره Zone دامنه را نگه می‌دارد. فیلدهای مهم SOA:

• Primary Nameserver: آدرس Nameserver اصلی.
• Contact Email: ایمیل مدیر فنی دامنه.
• Serial Number: شماره سریال که با هر تغییر افزایش می‌یابد. این شماره، سیگنال اصلی همگام‌سازی بین Nameserverهای Primary و Secondary است.
• Refresh Interval: بازه زمانی که Secondary باید از Primary بخواهد تا تغییرات را دریافت کند.
• Retry Interval: بازه تلاش مجدد در صورت شکست.
• Expire Interval: بازه انقضای اطلاعات در Secondary در صورت عدم پاسخ Primary.
• Minimum TTL: حداقل زمان نگهداری در Cache.

نکته عملی: تنظیم نادرست SOA، می‌تواند به مشکلات همگام‌سازی بین Nameserverها منجر شود. اگر Serial Number در Secondary بزرگ‌تر از Primary باشد یا Refresh Interval بسیار کوتاه تنظیم شود، ممکن است ترافیک اضافی روی سرورها ایجاد شود. بررسی این رکورد در عیب‌یابی DNS، یکی از مراحل مهم است.

Propagation: چرا بعد از تغییر Nameserver صبر می‌کنیم؟

پس از هر تغییر در رکوردهای NS، مدتی زمان لازم است تا تغییرات در سراسر اینترنت منتشر شوند. این انتشار، نتیجه مکانیزم Cache در لایه Resolver است. سه لایه Cache وجود دارد که هرکدام نقش متفاوتی دارند:

1. Cache مرورگر و سیستم‌عامل کاربر: با TTL معمول چند دقیقه تا چند ساعت.
2. Cache Resolver ISP یا سرویس عمومی: با TTL معمول چند ساعت تا چند روز.
3. Cache سایر Resolverها در مسیر: بسته به معماری، می‌تواند چند ساعت طول بکشد.

TTL (Time to Live)، فیلدی است که مشخص می‌کند هر رکورد تا چند ثانیه معتبر است. اگر TTL را در تنظیمات DNS خود پایین تنظیم کنید (مثلاً ۳۰۰ ثانیه)، تغییرات سریع‌تر منتشر می‌شوند. اما TTL پایین، هزینه دارد: تعداد پرسش‌های DNS بیشتر می‌شود. راهنمای تنظیم TTL در چگونه DNS دامنه را تنظیم کنیم آمده است.

زمان کامل انتشار (Propagation Time) پس از تغییر NS، معمولاً بین چند ساعت تا چند روز است. در ادبیات فنی، این زمان انتشار در پروپاگیشن DNS چیست و چقدر طول می‌کشد با جزئیات تحلیل شده است.

سناریوی مهاجرت: کدام را عوض می‌کنیم؟

پرسش رایج در پروژه‌های مهاجرت: باید Nameserver را عوض کنیم یا رکوردها را؟ پاسخ به سناریو بستگی دارد:

نکته مهم در سناریوی اول: وقتی Nameserver را تغییر می‌دهید، همه رکوردهای قبلی در Nameserver قبلی نادیده گرفته می‌شوند و دامنه، رکوردهای موجود در Nameserver جدید را می‌بیند. اگر این رکوردها کامل منتقل نشده باشند، ممکن است برخی سرویس‌ها (مثل ایمیل) از کار بیفتند. راهنمای کامل انتقال دامنه در انتقال دامنه چگونه انجام می‌شود آمده است.

پیکربندی در cPanel و وردپرس

در بستر cPanel، مدیریت DNS از طریق بخش Zone Editor انجام می‌شود. این ابزار، رابط گرافیکی برای ویرایش رکوردهای DNS فراهم می‌کند. پیکربندی در cPanel معمولاً برای کاربران معمولی از طریق همین ابزار انجام می‌شود.

نکته مهم: در cPanel، Nameserver معمولاً توسط هاستینگ تعیین می‌شود و کاربر فقط می‌تواند رکوردهای درون Zone را ویرایش کند. تغییر Nameserver، از طریق پنل Registrar انجام می‌شود، نه cPanel. راهنمای مدیریت DNS در cPanel در مدیریت DNS در cPanel آمده است.

در وردپرس، مدیریت DNS از طریق افزونه‌ها معمولاً محدود است، چون DNS لایه‌ای خارج از وردپرس است. اما برخی افزونه‌ها مثل Cloudflare یا سرویس‌های DNS تخصصی، امکان مدیریت رکوردهای خاص را فراهم می‌کنند. اگر با Cloudflare کار می‌کنید، DNS ابری چیست تصویر روشنی می‌دهد.

عیب‌یابی: کدام لایه مشکل دارد؟

وقتی سایت از دسترس خارج می‌شود، اولین پرسش در عیب‌یابی این است: مشکل از کدام لایه است؟ رویکرد سیستماتیک من، سه مرحله دارد:

1. تست رزولوشن از DNS سرورهای مختلف: با ابزارهایی مثل dig یا nslookup، دامنه را از چند DNS سرور مختلف (Google 8.8.8.8، Cloudflare 1.1.1.1، DNS محلی) کوئری می‌کنم. اگر پاسخ‌ها متفاوت باشند، مشکل احتمالاً در Cache لایه Resolver است. اگر پاسخ‌ها یکسان و اشتباه باشند، مشکل در Nameserver است.
2. تست Authoritative Server: با پرسش مستقیم از Nameserver دامنه، پاسخ نهایی را بررسی می‌کنم. اگر پاسخ از Authoritative Server صحیح است اما Resolver پاسخ اشتباه می‌دهد، مشکل انتشار (Propagation) است. اگر پاسخ از Authoritative Server اشتباه است، مشکل در پیکربندی Zone است.
3. تست در لایه‌های بالاتر: با بررسی رکورد NS در سرور TLD (با ابزار WHOIS یا پرسش مستقیم از سرور TLD)، تأیید می‌کنم که Delegation صحیح تنظیم شده است.

این روش، سیستماتیک و قابل تکرار است. عیب‌یابی معمولاً در کمتر از ده دقیقه به پاسخ می‌رسد. رایج‌ترین اشتباهات پیکربندی DNS را در اشتباهات رایج در تنظیم DNS جمع‌آوری کرده‌ام، اما جزئیات عیب‌یابی در چگونه DNS را عیب‌یابی کنیم آمده است.

در عیب‌یابی DNS، نصف کار این است که بدانید باید به کدام لایه نگاه کنید. هر لایه، ابزار و مسیر عیب‌یابی خودش را دارد.

پرسش‌های پرتکرار درباره تفاوت DNS و Nameserver

پرسش‌هایی که در جلسات مشاوره زیاد می‌شنوم:

آیا DNS و Nameserver یکی هستند؟

نه. DNS یک سیستم توزیع‌شده و مجموعه‌ای از پروتکل‌هاست. Nameserver یک سرور مشخص در این سیستم است که رکوردهای یک دامنه را نگه می‌دارد. DNS لایه منطقی است، Nameserver لایه پیاده‌سازی.

آیا هر دامنه‌ای باید حداقل دو Nameserver داشته باشد؟

بله، طبق استاندارد اینترنت، هر دامنه باید حداقل دو Nameserver داشته باشد تا در صورت قطعی یکی، دیگری پاسخ‌دهی را ادامه دهد. این دو Nameserver باید ترجیحاً روی زیرساخت‌های متفاوت باشند.

آیا می‌توان Nameserver را بدون تغییر رکوردها تغییر داد؟

بله، اما همیشه توصیه نمی‌شود. تغییر Nameserver، در واقع کنترل DNS دامنه را به سرور جدید منتقل می‌کند. اگر رکوردهای Nameserver جدید کامل نباشند، برخی سرویس‌ها (مثل ایمیل) از کار می‌افتند. همیشه پیش از تغییر Nameserver، رکوردها را در سرور جدید آماده کنید.

چطور بفهمم Nameserver دامنه چیست؟

با ابزار WHOIS یا پرسش از سرور TLD مربوط به دامنه. دستور dig NS example.com @8.8.8.8 پاسخ را برمی‌گرداند. این اطلاعات در گزارش‌های DNS گزارش‌گیری نیز نشان داده می‌شود.

تفاوت رکورد NS و SOA چیست؟

رکورد NS مشخص می‌کند کدام Nameserver مسئول پاسخ‌دهی است. رکورد SOA اطلاعات ساختاری Zone (Serial، Refresh، Retry، Expire، Minimum TTL) را نگه می‌دارد. NS برای مسیریابی است، SOA برای همگام‌سازی.

آیا می‌توان DNS را روی یک Nameserver و ایمیل را روی سرور دیگر میزبانی کرد؟

بله، و این سناریوی رایجی است. Nameserver رکوردهای دامنه را نگه می‌دارد. رکورد MX به سرور ایمیل اشاره می‌کند که می‌تواند روی سرور متفاوتی باشد. مثلاً Nameserver روی هاست سایت است، اما رکورد MX به Microsoft 365 یا Google Workspace اشاره می‌کند.

چرا بعضی از سایت‌ها بعد از تغییر Nameserver، فوراً در دسترس نیستند؟

به‌خاطر Propagation یا انتشار. Cache موجود در Resolverها باید منقضی شود تا تغییرات را دریافت کنند. زمان انتشار معمولاً بین چند ساعت تا چند روز است و به TTL رکوردها بستگی دارد.

آیا می‌توان DNS را روی Cloudflare نگه داشت و Nameserver را روی هاست؟

در معماری رایج، Cloudflare خودش به‌عنوان Nameserver عمل می‌کند. یعنی Nameserver دامنه به Cloudflare اشاره می‌کند و رکوردها در پنل Cloudflare مدیریت می‌شوند. این معماری، مزایای سرعت و امنیت را همراه دارد، اما کنترل مستقیم روی Zone File را از شما می‌گیرد و به پنل Cloudflare منتقل می‌کند.

آیا می‌توان برای زیردامنه‌ها Nameserver جداگانه تعریف کرد؟

بله، این کار با مکانیزم Delegation انجام می‌شود. یک زیردامنه مثل sub.example.com می‌تواند به Nameserverهای مستقل خودش واگذار شود. این سناریو در معماری‌های چندلایه و سازمانی رایج است.

برای تغییر رکوردهای DNS، باید به پنل Registrar دسترسی داشته باشم؟

بستگی به معماری دارد. اگر Nameserver شما روی هاست است، رکوردها را از طریق پنل هاست (مثل cPanel) ویرایش می‌کنید. اگر Nameserver روی سرویس DNS اختصاصی است (مثل Cloudflare یا Route 53)، از پنل آن سرویس ویرایش می‌کنید. پنل Registrar فقط برای تغییر آدرس Nameserver استفاده می‌شود.

تصویر نهایی: تفاوت در یک جمله

تفاوت DNS و Nameserver، در یک جمله: DNS سیستم و پروتکل است؛ Nameserver سرور و پیاده‌سازی. اولی زبان اینترنت است، دومی کتابخانه محلی یک دامنه. این تفکیک، در عیب‌یابی، مهاجرت و پیکربندی، کاربردی مستقیم دارد و انتخاب آگاهانه بین تغییر Nameserver و تغییر رکوردها را ممکن می‌کند.

سه اولویت عملی برای مدیران سایت: اول، پیش از هر مهاجرت، تفکیک روشن بین این دو لایه؛ دوم، آماده‌سازی کامل رکوردها در سرور جدید پیش از تغییر Nameserver؛ سوم، آموزش تیم درباره ابزارهای عیب‌یابی (dig، nslookup، whois) برای تشخیص سریع لایه مشکل‌دار.

اگر در پروژه‌ای تجربه‌ای از تفکیک این دو لایه داشته‌اید — به‌خصوص در سناریوهایی که ابتدا مشکل به DNS نسبت داده شد و بعد مشخص شد در لایه Nameserver بوده یا برعکس — برایم جالب است تجربه‌تان را بشنوید. اگر ابزار یا رویکرد عیب‌یابی مؤثری در این زمینه دارید که در این مقاله به آن اشاره نشده، دیدگاه‌ها جای خوبی برای به‌اشتراک گذاشتن آن است. 🌐