Domain، DNS و Hosting چه تفاوتی دارند؟

وقتی کسی می‌گوید «سایت را بالا آوردیم»، معمولاً سه چیز را در یک جمله قاطی می‌کند: نام دامنه (Domain Name)، سامانهٔ نام دامنه (DNS)، و میزبانی (Hosting). یکی آدرس قابل‌خواندن انسان است، یکی دفترچهٔ تلفن اینترنت است، و یکی جایی است که فایل‌ها و برنامهٔ سایت واقعاً اجرا می‌شوند. اگر این سه لایه را جدا نبینید، خطاهای روزمره — سایت باز نمی‌شود، ایمیل قطع است، گواهی TLS نصب نمی‌شود — را اشتباه تشخیص می‌دهید و پول و زمان را روی لایهٔ غلط خرج می‌کنید.

طبق تعریف ICANN، دامنه یک نام یکتا است که مبنای URLهایی است که مردم برای یافتن منابع اینترنت به‌کار می‌برند؛ مثلاً در https://www.icann.org/public-comments بخش icann.org دامنه است و بقیهٔ مسیر منبع مشخص روی همان دامنه را نشان می‌دهد. DNS طبق MDN و Cloudflare یک سامانهٔ سلسله‌مراتبی و توزیع‌شده است که نام انسان‌پسند را به آدرس IP ماشین‌پسند ترجمه می‌کند. Hosting همان ماشینی (یا سرویس ابری) است که در آن IP محتوا یا اپلیکیشن را نگه می‌دارد و پاسخ HTTP می‌دهد.

این متن برای تصمیم‌گیری نوشته شده: بدانید هر لایه را از چه کسی می‌خرید، کجا تنظیم می‌کنید، و وقتی سایت «نمی‌آید» کدام لایه را اول چک کنید. هدف حفظ جزئیات پروتکل نیست؛ هدف این است که صاحب محصول و توسعه‌دهندهٔ جونیور بتوانند تیکت را درست مسیریابی کنند.

پاسخ کوتاه

Domain نام ثبت‌شدهٔ شماست (مثل example.com). DNS نگاشت آن نام به رکوردهایی مثل A/AAAA (IP)، CNAME، MX و NS است. Hosting جایی است که وب‌سرور، دیتابیس و فایل‌ها اجرا می‌شوند. می‌توانید دامنه را از یک Registrar بخرید، DNS را نزد Cloudflare یا خود Registrar نگه دارید، و Hosting را روی یک VPS یا Cloud جدا بگیرید — این سه قرارداد اغلب جدا هستند و تعویض یکی بدون هم‌تراز کردن بقیه باعث قطعی می‌شود.

قانون تشخیص سریع: اگر نام در مرورگر شناخته نمی‌شود یا به IP اشتباه می‌رود، اول DNS و وضعیت دامنه را ببینید. اگر IP درست است ولی پاسخ ۵xx یا تایم‌اوت می‌گیرید، لایهٔ Hosting را باز کنید. اگر فقط ایمیل خراب است، وب را دست نزنید؛ رکورد MX را بررسی کنید.

دامنه برچسب است؛ DNS نقشه است؛ Hosting ساختمان است. برچسب درست روی ساختمان اشتباه، یا نقشهٔ قدیمی، هر دو شما را به درِ بسته می‌رسانند.

لایهٔ اول: Domain چیست؟

طبق واژه‌نامهٔ ICANN، دامنه نام یکتایی است که مبنای URL قرار می‌گیرد و یک آدرس مشخص روی اینترنت متعلق به یک نهاد (شرکت، سازمان، فرد) را مشخص می‌کند. ساختار دامنه از برچسب‌های متنی جداشده با نقطه تشکیل می‌شود: در icann.org بخش org دامنهٔ سطح بالا (TLD) است و icann دامنهٔ سطح دوم. دامنه می‌تواند زیردامنه‌هایی مثل www یا api هم داشته باشد؛ هر زیردامنه باز هم در فضای همان ثبت والد مدیریت می‌شود مگر اینکه جداگانه واگذار شده باشد.

خرید دامنه یعنی ثبت آن نام نزد یک Registrar برای مدت مشخص (معمولاً سالیانه)، نه خرید «سایت». دامنه خودش صفحهٔ وب نیست؛ فقط حق استفاده از آن برچسب در فضای نام جهانی است. تمدید نکردن دامنه یعنی از دست دادن همان برچسب — حتی اگر فایل‌های سایت روی هاست سالم باشند و تیم توسعه هر روز دیپلوی کند.

Registrar در برابر Registry

Registry پایگاه رسمی یک TLD را نگه می‌دارد. Registrar همان کانالی است که از آن دامنه را می‌خرید و با Registry هماهنگ می‌کند. برای صاحب سایت کافی است بداند: قرارداد تمدید، قفل انتقال، تماس‌های WHOIS یا جایگزین حریم‌خصوصی، و انتقال بین فروشنده‌ها با Registrar است؛ سیاست‌های کلی فضای نام با ICANN و اپراتورهای TLD هم‌راستا می‌شود.

نکتهٔ عملی: دامنه را جایی ثبت کنید که قفل انتقال، احراز هویت دوعاملی حساب، و یادآور تمدید شفاف داشته باشد. دامنهٔ منقضی‌شده گاهی با بازیابی پرهزینه و ریسک از دست رفتن برند برمی‌گردد — این موضوع فنی Hosting نیست؛ موضوع مالکیت نام است. اگر چند نفر به پنل Registrar دسترسی دارند، حداقل یک مالک رسمی و یک روش بازیابی حساب تعریف کنید.

لایهٔ دوم: DNS چیست و چگونه کار می‌کند؟

MDN می‌گوید DNS سامانهٔ نام‌گذاری سلسله‌مراتبی و غیرمتمرکز برای منابع متصل به اینترنت است و فهرست دامنه‌ها را همراه منابعی مثل آدرس IP نگه می‌دارد. برجسته‌ترین نقش آن ترجمهٔ نام انسان‌پسند به IP است (DNS Lookup). Cloudflare همان ایده را با استعارهٔ «دفترچهٔ تلفن اینترنت» توضیح می‌دهد: انسان nytimes.com را تایپ می‌کند؛ مرورگر و ماشین‌ها با IP صحبت می‌کنند.

در مسیر یک Lookup معمولی وقتی کش خالی است، درخواست از Resolver بازگشتی (مثلاً Resolver ارائه‌دهندهٔ اینترنت یا یک DNS عمومی) به Root Nameserver، سپس Nameserver مربوط به TLD، و در نهایت Nameserver معتبر (Authoritative) دامنه می‌رسد. Authoritative همان جایی است که رکوردهای شما — A، AAAA، MX، TXT، CNAME — به‌عنوان منبع حقیقت ذخیره شده‌اند. Recursive Resolver در ابتدای زنجیره است و Authoritative در انتها؛ Cloudflare این تفاوت نقش را صریح جدا می‌کند.

کش DNS در مرورگر، سیستم‌عامل، Resolver و گاهی لایه‌های میانی باعث می‌شود تغییر شما فوری برای همه دیده نشود. TTL هر رکورد می‌گوید پاسخ چقدر می‌تواند کهنه بماند. قبل از مهاجرت بزرگ، TTL را آگاهانه پایین بیاورید؛ بعد از تثبیت دوباره بالا ببرید تا بار Lookup کم شود.

رکوردهایی که صاحب سایت باید بشناسد

• NS: کدام Nameserver برای این دامنه معتبر است — تعویض Provider DNS از اینجا شروع می‌شود.
• A / AAAA: نگاشت نام به IPv4 / IPv6؛ معمولاً به IP سرور Hosting یا لبهٔ CDN.
• CNAME: نام مستعار به نام دیگر (مثلاً www به هدف CDN). روی apex محدودیت‌هایی دارد که باید با ALIAS/ANAME یا راهنمای Provider حل شود.
• MX: مسیر تحویل ایمیل؛ کاملاً جدا از مسیر وب.
• TXT: تأیید مالکیت سرویس‌ها، SPF/DKIM و برخی یکپارچه‌سازی‌های امنیتی.
• CAA (در صورت استفاده): محدود کردن اینکه کدام Certificate Authority اجازهٔ صدور گواهی دارد.

لایهٔ سوم: Hosting چیست؟

Hosting یعنی فراهم‌کردن منابع محاسباتی و ذخیره‌سازی که اپلیکیشن وب روی آن اجرا می‌شود: وب‌سرور، دیتابیس، فایل‌های استاتیک، صف‌ها، و اغلب لاگ و پشتیبان. شکل آن می‌تواند Shared Hosting، VPS، سرور اختصاصی، یا پلتفرم ابری/PaaS باشد. از دید کاربر نهایی، Hosting همان مقصدی است که بعد از Lookup DNS به IP آن وصل می‌شود و پاسخ HTML یا API می‌دهد.

هاست «سایت» نیست؛ اجرای سایت است. می‌توانید بدون تغییر دامنه، هاست را عوض کنید — به شرطی که DNS (معمولاً رکورد A/AAAA یا هدف CDN) را به‌روز کنید. برعکس، می‌توانید هاست را نگه دارید و فقط دامنه را عوض کنید — باز هم DNS و تنظیمات گواهی TLS باید با نام جدید هم‌تراز شوند. انتخاب نوع هاست موضوع ظرفیت، امنیت و هزینه است؛ جزئیات سرور و تفاوت VPS/Cloud را در مقالات مرتبط سری دنبال کنید.

جدول مقایسه: Domain در برابر DNS در برابر Hosting

سناریوهای واقعی که سه لایه قاطی می‌شوند

۱) «دامنه خریدم پس سایت دارم»

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

۲) «هاست عوض کردم؛ هنوز سایت قدیمی است»

IP جدید روی سرور جدید است، اما رکورد A هنوز IP قدیم را نشان می‌دهد، یا TTL قدیمی در Resolverها مانده. مشکل Hosting نیست؛ مشکل پیکربندی DNS یا Propagation است. تست با dig از چند Resolver یا مقایسهٔ IP دیده‌شده با IP پنل هاست معمولاً موضوع را در چند دقیقه روشن می‌کند.

۳) «سایت باز است؛ ایمیل نه»

وب و ایمیل رکوردهای جدا دارند. A درست و MX غلط — یا برعکس — کاملاً ممکن است. وقتی تیکت می‌گوید «اینترنت قطع است»، بپرسید مرورگر است یا ایمیل؛ پاسخ مسیر عیب‌یابی را نصف می‌کند.

۴) «CDN روشن کردم؛ Origin را فراموش کردم»

CDN لایهٔ لبه است و هنوز به Origin (Hosting) نیاز دارد. اگر فقط DNS را به CDN بدهید ولی Origin خاموش، فایروال‌بسته، یا گواهی ناهماهنگ باشد، لبه خطای Upstream می‌دهد. DNS درست به‌معنای اپلیکیشن سالم نیست.

۵) «SSL روی هاست نصب است؛ مرورگر نامعتبر می‌گوید»

گاهی گواهی برای www صادر شده و کاربر به apex آمده، یا برعکس؛ گاهی DNS به سروری می‌رود که گواهی دیگری دارد. اینجا هر سه لایه درگیرند: نام (Domain)، مقصد (DNS)، و محل نصب گواهی (Hosting یا Edge).

چه کسی مسئول کدام تنظیم است؟

در تیم کوچک یک نفر هر سه را می‌بیند؛ در تیم بزرگ‌تر مرزها را بنویسید تا تغییر نیمه‌شب بدون هماهنگی رخ ندهد:

1. مالک دامنه و تمدید: معمولاً عملیات یا مدیر فنی با دسترسی Registrar و بازیابی حساب.
2. تغییر NS و رکوردهای حیاتی: افراد محدود؛ هر تغییر با تیکت یا لاگ کوتاه.
3. سخت‌افزار، کانتینر، دیتابیس Hosting: تیم زیرساخت یا ارائه‌دهنده.
4. گواهی TLS: مشخص کنید منبع حقیقت لبهٔ CDN است یا Origin — دو جا همزمان بدون هماهنگی یعنی قطعی تصادفی.

قبل از مهاجرت چک‌لیست کوتاه: پشتیبان، کاهش TTL از چند روز قبل، رکوردهای موازی در صورت امکان، تست با فایل hosts یا dig، مشاهدهٔ ترافیک روی مقصد جدید، سپس خاموش کردن Origin قدیم. عجله برای «قطع کردن قدیم» قبل از تأیید DNS شایع‌ترین دلیل Downtime خودساخته است.

چک‌لیست تشخیص خرابی در سه لایه

• آیا دامنه منقضی شده، در Registrar قفل است، یا انتقال ناتمام مانده؟ (Domain)
• dig یا NSLOOKUP نام را به چه IPای می‌رساند؟ با IP مورد انتظار یکی است؟ (DNS)
• اگر با IP سرور و هدر Host مناسب درخواست بدهید پاسخ می‌گیرید؟ (Hosting)
• آیا فقط www مشکل دارد یا apex هم؟ (اغلب CNAME/ALIAS ناقص)
• آیا فقط ایمیل یا فقط وب خراب است؟ (رکوردهای جدا)
• آیا از شبکه‌های مختلف یکسان resolve می‌شود یا فقط بعضی Resolverها کهنه مانده‌اند؟ (TTL/Propagation)

جمع‌بندی برای تصمیم

Domain، DNS و Hosting سه قرارداد و سه نقطهٔ شکست جدا هستند. دامنه را برای برند و مالکیت نگه دارید؛ DNS را طوری بچینید که مهاجرت، ایمیل و تأیید مالکیت شفاف باشد؛ Hosting را بر اساس بار، امنیت و بودجه انتخاب کنید — نه فقط بر اساس اینکه «همه‌چیز را یک پکیج ارزان بخرم». پکیج یک‌جا گاهی شروع را ساده می‌کند، اما وقتی مشکل پیش می‌آید باز هم باید بدانید کدام لایه را لمس می‌کنید.

گام بعدی منطقی بعد از فهم این سه لایه، گواهی TLS و HTTPS روی همان نام و همان مسیر است. پیش از آن، نقش سرور و CDN را در مسیر کاربر روشن کنید تا لبه و Origin را با هم قاطی نکنید.

اگر همین هفته یک کار می‌کنید: برای دامنهٔ اصلی‌تان سه خط بنویسید — Registrar کجاست، NSها کجا هستند، رکورد A/AAAA به کدام IP یا CDN می‌رسد. همین سند کوتاه نصف تیکت‌های «سایت بالا نمی‌آید» را درست مسیریابی می‌کند.

منابع و مراجع

• ICANN — Domain Name (Acronyms and Terms) — https://www.icann.org/en/icann-acronyms-and-terms/domain-name-en
• ICANN — The Domain Name System — https://www.icann.org/resources/pages/dns-2022-09-13-en
• MDN Web Docs — DNS (Glossary) — https://developer.mozilla.org/en-US/docs/Glossary/DNS
• Cloudflare Learning — What is DNS? — https://www.cloudflare.com/learning/dns/what-is-dns/

اگر در حال راه‌اندازی یا مهاجرت سایت هستید، این تفکیک سه‌لایه را قبل از خرید پکیج «همه‌چیز با هم» روی کاغذ بیاورید؛ هزینهٔ یک ساعت شفاف‌سازی کمتر از یک روز قطعی ناشی از رکورد اشتباه است.