DNS چیست؟ راهنمای تنظیم دامنه برای سرورهای VPS

DNS چیست و چرا دامنه شما هنوز به VPS متصل نمی‌شود

DNS (سامانه نام دامنه) یک نام مانند example.com را به یک آدرس IP (پروتکل اینترنت) مانند 203.0.113.10 تبدیل می‌کند. مرورگر نمی‌تواند مستقیماً به یک نام متصل شود. مرورگر به یک آدرس نیاز دارد، بنابراین بارگذاری هر صفحه با یک پرسش و پاسخ DNS آغاز می‌شود. اگر به‌تازگی یک دامنه و یک VPS شخصی تهیه کرده‌اید و هیچ‌چیز بارگذاری نمی‌شود، یکی از دو حالت زیر برقرار است: هنوز رکوردی وجود ندارد که نام را به آدرس سرور شما متصل کند، یا رکوردی وجود دارد اما بخشی از مسیر شبکه همچنان پاسخ قدیمی را ارائه می‌دهد.

هر دو وضعیت عادی هستند و هیچ‌کدام به معنای خرابی نیستند. بخش‌های زیر موارد را به ترتیبی که با آن‌ها مواجه می‌شوید بررسی می‌کنند؛ با موردی شروع می‌کنیم که بیشترین زمان را هدر می‌دهد: اینکه کدام پنل مدیریت در واقع رکوردهای شما را نگهداری می‌کند.

تمام بررسی‌های اینجا از dig استفاده می‌کنند که به‌صورت پیش‌فرض روی سیستم‌عامل‌های تازه نصب‌شده Ubuntu یا Debian موجود نیست.

sudo apt update && sudo apt install -y bind9-dnsutils

ثبت‌کننده (Registrar)، سرورهای نام (Nameservers) و میزبان DNS: کدام‌یک را باید ویرایش کنید

این سه نام، وظایف متفاوتی را توصیف می‌کنند. اشتباه گرفتن آن‌ها رایج‌ترین دلیل بی‌اثر بودن تغییرات است.

• ثبت‌کننده (Registrar) شرکتی است که دامنه را از آن خریده‌اید. وظیفه حیاتی آن تفویض اختیار (delegation) است: به رجیستری که TLD (دامنه سطح بالا، بخش .com) شما را مدیریت می‌کند، می‌گوید که کدام سرورهای نام برای دامنه شما معتبر (authoritative) هستند.
• سرورهای نام معتبر (Authoritative nameservers) رکوردهای واقعی مربوط به زون (zone) شما را نگهداری می‌کنند. زون همان دامنه شما و نام‌های زیرمجموعه آن است.
• میزبان DNS (DNS host) هر کسی است که آن سرورهای نام را اداره می‌کند. این میزبان می‌تواند همان ثبت‌کننده، یک ارائه‌دهنده مجزا، یا bind9 باشد که روی سروری متعلق به خودتان اجرا می‌شود.

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

ببینید که جهان از کجا پرس‌وجو می‌کند:

dig example.com NS +short
dig +trace example.com

دستور اول سرورهای نامی را چاپ می‌کند که امروز پاسخگوی دامنه هستند. دستور دوم زنجیره را از سرورهای ریشه (root) دنبال کرده و ارجاعی را که سرورهای TLD ارائه می‌دهند چاپ می‌کند؛ این همان تفویض اختیاری است که ثبت‌کننده شما کنترل می‌کند. اگر آن نام‌ها متعلق به ارائه‌دهنده‌ای هستند که نمی‌شناسید، همان ارائه‌دهنده صاحب پنلی است که به آن نیاز دارید.

نحوه انجام یک جستجوی DNS

چهار طرف در این فرآیند دخیل هستند و هر کدام نسخه‌ای از آنچه می‌آموزند را ذخیره می‌کنند.

1. stub resolver روی دستگاه شما. این بخش جستجویی انجام نمی‌دهد. فقط از یک سرور پیکربندی‌شده می‌پرسد و پاسخ را می‌پذیرد. در Ubuntu، فایل /etc/resolv.conf معمولاً یک symlink به /run/systemd/resolve/stub-resolv.conf است و به 127.0.0.53 اشاره می‌کند که همان systemd-resolved است که به‌صورت محلی با کش اختصاصی خود اجرا می‌شود.
2. recursive resolver. این همان resolver است که توسط ISP (ارائه‌دهنده خدمات اینترنت) شما اجرا می‌شود، یا یک سرویس عمومی مانند 1.1.1.1، یا سرویسی که خودتان راه‌اندازی کرده‌اید. این بخش کار اصلی یافتن پاسخ را انجام می‌دهد.
3. سرورهای root و TLD. recursive resolver از یک سرور root می‌پرسد؛ سرور root آدرس شما را نمی‌داند اما با ارجاع به سرورهای .com پاسخ می‌دهد. آن‌ها نیز با ارجاع به nameserverهای شما پاسخ می‌دهند.
4. authoritative nameserver. این سرور از کسی سوال نمی‌کند. پاسخ را از zone شما استخراج کرده و آن را به عنوان پاسخ معتبر (authoritative) علامت‌گذاری می‌کند.

ابزار dig +trace example.com این فرآیند را به شما نشان می‌دهد، زیرا از ریشه (root) شروع کرده و به جای پرسش از کش، هر ارجاع را چاپ می‌کند. این سریع‌ترین راه برای مشاهده این است که آیا delegation و zone با هم مطابقت دارند یا خیر.

رکوردهای DNS که هنگام اجرای سرور اهمیت دارند

• A: نگاشت یک نام به یک آدرس IPv4. example.com. A 203.0.113.10. این رکوردی است که دامنهٔ شما را به VPS متصل می‌کند.
• AAAA: نگاشت یک نام به یک آدرس IPv6، مانند 2001:db8::10. تنها زمانی آن را منتشر کنید که سرویس شما واقعاً روی آن آدرس گوش می‌دهد. کلاینت‌های موجود در شبکه‌های IPv6 ابتدا پاسخ AAAA را امتحان می‌کنند، بنابراین آدرسی که هیچ پاسخی نمی‌دهد، باعث تأخیر در هر بازدید می‌شود.
• CNAME: یک نام مستعار از یک نام به نام دیگر. www.example.com. CNAME example.com. بازدیدکنندگان www را به هر مقصدی که دامنهٔ اصلی به آن resolve می‌شود، هدایت می‌کند. یک CNAME نمی‌تواند در apex (دامنهٔ بدون زیردامنه، مانند example.com) قرار بگیرد، زیرا apex باید دارای رکوردهای SOA (شروع مرجعیت) و NS اختصاصی خود باشد و CNAME اجازه ندارد با هیچ رکورد دیگری در یک نام مشترک باشد. ارائه‌دهندگان، راهکارهایی را با نام‌هایی مانند ALIAS، ANAME یا CNAME flattening ارائه می‌دهند.
• MX: جایی که ایمیل‌های دامنه تحویل داده می‌شوند. این رکورد شامل یک نام میزبان و یک عدد اولویت است که عدد کمتر، اولویت بالاتری دارد. یک MX باید به نامی اشاره کند که دارای رکورد آدرس باشد. اشاره کردن آن به یک CNAME نامعتبر است و برخی سرورهای فرستنده آن را رد می‌کنند.
• TXT: متن آزاد، که برای اثبات مالکیت و سیاست‌ها استفاده می‌شود. رکوردهای احراز هویت ایمیل (SPF، DKIM، DMARC) در اینجا قرار می‌گیرند، همچنین توکن ACME (محیط مدیریت خودکار گواهی) که برای صدور گواهی wildcard استفاده می‌شود.
• NS: مشخص می‌کند کدام nameserverها zone را سرویس‌دهی می‌کنند. نسخه‌ای که تعیین می‌کند دنیا از کجا پرس‌وجو کند، در zone والد قرار دارد و از delegation ثبت‌کنندهٔ دامنهٔ شما می‌آید، نه از نسخه‌ای که داخل zone خودتان است.

دو جزئیات بیش از خودِ انواع رکوردها باعث سردرگمی می‌شوند. نامی که به نقطه ختم می‌شود مطلق است، بنابراین www.example.com. دقیقاً به همان معناست و نه چیزی بیشتر. اکثر پنل‌ها انتظار یک نام نسبی را دارند و دامنه را برای شما به آن می‌چسبانند، بنابراین وارد کردن www.example.com در کادر نام، به شما www.example.com.example.com می‌دهد که برای هیچ‌کس resolve نمی‌شود. جزئیات دیگر @ است که در تقریباً تمام پنل‌ها به معنای apex است: خودِ دامنه، بدون هیچ زیردامنه‌ای.

اشاره کردن رکورد A به VPS

ابتدا آدرسی را که اینترنت برای سرور شما می‌بیند، به دست آورید:

curl -4 https://ifconfig.me
ip -brief -4 address show

سپس یک رکورد در میزبان DNS خود ایجاد کنید: نوع را A، نام را @، مقدار را همان آدرس و TTL (زمان زنده ماندن) را 300 قرار دهید. یک رکورد دوم برای www اضافه کنید؛ یا یک A دیگر با همان آدرس، یا یک CNAME که به apex اشاره می‌کند.

اکنون صحت resolve شدن آن را بررسی کنید؛ بهتر است این کار را از لپ‌تاپ خود انجام دهید، نه از داخل خود سرور:

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

دستور اول از مسیر معمول دستگاه شما، شامل کش‌ها، استفاده می‌کند. دستور دوم از کش محلی شما صرف‌نظر کرده و از یک recursive resolver عمومی پرس‌وجو می‌کند. دستور سوم مستقیماً از authoritative nameserver شما می‌پرسد، بنابراین پاسخ آن حقیقت فعلی بدون هیچ‌گونه کش در مسیر است. زمانی که دستور سوم آدرس شما را برمی‌گرداند اما دستور اول هنوز این کار را نمی‌کند، یعنی DNS شما به‌درستی پیکربندی شده است و فقط منتظر هستید تا نسخه کش‌شده قدیمی منقضی شود.

عدم بارگذاری به دلیل مشکل در حل نام دامنه

حل نام دامنه (name resolving) تنها ثابت می‌کند که DNS کار می‌کند. این موضوع هیچ چیزی را درباره وب‌سرور شما اثبات نمی‌کند. هنگامی که dig آدرس صحیح را برمی‌گرداند، اتصال را تست کنید:

curl -I http://example.com

curl: (6) Could not resolve host: example.com نشان‌دهنده یک مشکل DNS است. curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused یک مشکل DNS نیست: نام دامنه با موفقیت حل شده و بسته اطلاعاتی به مقصد رسیده است، بنابراین مشکل اینجاست که هیچ سرویسی روی آن پورت در حال گوش دادن (listening) نیست. درخواستی که معلق می‌ماند و سپس با خطای timeout مواجه می‌شود، معمولاً به این معنی است که فایروال بسته را به‌جای رد کردن (refuse)، به‌صورت بی‌صدا حذف (drop) کرده است. در این مرحله، DNS دیگر موضوع بحث نیست و پورت‌ها و سوکت‌های در حال گوش دادن به همراه قوانین فایروال ufw در VPS شما وارد عمل می‌شوند. پس از برقراری اتصال، باقی مراحل بارگذاری صفحه مربوط به عملکرد پروتکل HTTP است.

چرا مرورگر همچنان میزبان قدیمی را نشان می‌دهد

هیچ‌چیز به‌طور خودکار منتشر نمی‌شود. هیچ سروری تغییرات شما را به بیرون مخابره نمی‌کند. سرور نام معتبر (authoritative nameserver) شما در لحظه ذخیره، مقدار جدید را در اختیار دارد، اما هر کپی کش‌شده از پاسخ قبلی تا زمانی که تایمر آن منقضی نشود، معتبر باقی می‌ماند. این تایمر همان TTL است که بر حسب ثانیه محاسبه می‌شود و همراه با رکورد ارائه شده است.

کپی‌ها در مکان‌هایی بیش از آنچه تصور می‌کنید ذخیره می‌شوند: کش داخلی مرورگر، stub resolver روی سیستم، recursive resolver مورد استفاده در شبکه، و هر resolver که توسط VPN روی کلاینت نصب شده باشد. هر کدام کپی خود را تا زمان TTL دریافتی نگه می‌دارند. دو نفر در دو شبکه مختلف ممکن است برای ساعت‌ها دو پاسخ متفاوت ببینند و هر دو سیستم نیز به‌درستی عمل کنند.

شمارش معکوس را در برابر یک caching resolver مشاهده کنید:

dig @1.1.1.1 example.com +noall +answer

آن را دو بار و با فاصله چند ثانیه اجرا کنید. مقدار TTL در پاسخ کاهش می‌یابد. وقتی به صفر برسد، resolver رکورد را دور می‌ریزد و دوباره از nameserver شما پرس‌وجو می‌کند.

یک کش دوم وجود دارد که تقریباً کسی به آن توجه نمی‌کند: پاسخ‌های منفی. وقتی به یک resolver گفته می‌شود که نامی وجود ندارد، آن NXDOMAIN را نیز برای مدتی که در آخرین فیلد رکورد SOA منطقه (zone) شما تنظیم شده، کش می‌کند.

dig example.com SOA +short

عدد نهایی در آن خط، TTL منفی است که اغلب 3600 است. بنابراین جستجوی staging.example.com پیش از ایجاد آن، می‌تواند رکورد را تا یک ساعت پس از ایجاد، از دید شما پنهان نگه دارد. ابتدا رکورد را ایجاد کنید و سپس آن را کوئری بگیرید.

تغییر nameserverها کندتر از تغییر یک رکورد است و دلیل آن مکانیکی است. رکوردهای تفویض (delegation) در منطقه .com با TTL معادل 172800 ثانیه ارائه می‌شوند که برابر با دو روز است؛ بنابراین resolverای که nameserverهای قدیمی شما را کش کرده، می‌تواند تا آن مدت همچنان از آن‌ها پرس‌وجو کند. توصیه به «صبر تا 48 ساعت» از همین‌جا ناشی می‌شود. این موضوع برای تغییرات nameserver صدق می‌کند، نه برای ویرایش‌های عادی رکورد.

مهاجرت را بر اساس TTL برنامه‌ریزی کنید، نه در تقابل با آن:

1. TTL رکورد را به 300 کاهش دهید و ذخیره کنید.
2. بیش از مقدار TTL قدیمی صبر کنید تا تمام کپی‌های کش‌شده با مقدار قدیمی منقضی شوند.
3. آدرس را تغییر دهید.
4. پس از انتقال ترافیک، TTL را دوباره به 3600 یا بالاتر برگردانید، زیرا TTL پایین باعث می‌شود هر resolver بسیار بیشتر از حد معمول از nameserverهای شما پرس‌وجو کند.

برای پاکسازی آنچه سیستم شما در حافظه نگه داشته است:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics یک بخش کش با شمارنده‌های hit و miss چاپ می‌کند، بنابراین بلافاصله پس از flush، جستجوی بعدی به عنوان miss نمایش داده می‌شود. مرورگرها کش جداگانه‌ای دارند، به این معنی که Chrome می‌تواند پس از خالی شدن کش سیستم، همچنان از پاسخ قدیمی استفاده کند. آن را در chrome://net-internals/#dns پاک کنید. /etc/hosts را نیز بررسی کنید، زیرا یک خط باقی‌مانده در آنجا، DNS را روی همان سیستم (و فقط همان سیستم) دور می‌زند. getent hosts example.com پاسخی را نشان می‌دهد که سیستم واقعاً از آن استفاده خواهد کرد، که شامل /etc/hosts نیز می‌شود.

گواهی‌های Wildcard با استفاده از رکورد TXT تأیید می‌شوند

یک CA (مرجع صدور گواهی) پیش از صدور گواهی، کنترل شما بر نام دامنه را بررسی می‌کند. چالش HTTP-01 یک فایل را از طریق پورت 80 روی همان نام میزبان ارائه می‌دهد که برای یک نام واحد به‌خوبی کار می‌کند. یک گواهی wildcard دامنه *.example.com را پوشش می‌دهد؛ مجموعه‌ای نامحدود از نام‌های میزبان که CA نمی‌تواند از آن‌ها فایلی دریافت کند. بنابراین، Let's Encrypt گواهی‌های wildcard را فقط از طریق چالش DNS-01 صادر می‌کند. شما یک رکورد TXT در _acme-challenge.example.com منتشر می‌کنید که حاوی توکنی است که CA به شما داده است؛ کنترل بر zone در اینجا به عنوان مدرک عمل می‌کند.

این موضوع باعث می‌شود میزبان DNS شما بخشی از فرآیند تمدید گواهی باشد. Certbot باید در هر بار تمدید، آن رکورد TXT را بدون دخالت شما ایجاد و حذف کند، بنابراین به یک API و یک پلاگین منطبق با ارائه‌دهنده شما نیاز دارد. هنگامی که اعتبارسنجی با شکست مواجه می‌شود، پیام معمول DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com است که نشان می‌دهد CA پیش از قابل مشاهده شدن رکورد، درخواست را ارسال کرده است: یا رکورد هرگز ذخیره نشده، یا پاسخ منفی همچنان در حافظه کش (cache) باقی مانده است. رویه کامل در راهنمای گواهی‌های wildcard با چالش DNS-01 موجود است.

وقتی یک VPN کنترل resolver شما را در دست می‌گیرد

یک کلاینت VPN (شبکه خصوصی مجازی) معمولاً در زمان اتصال، resolver سیستم را جایگزین می‌کند؛ زیرا ارسال درخواست‌های جستجو به شبکه محلی، نام تمام سایت‌هایی که بازدید می‌کنید را برای آن شبکه فاش می‌کند. این رفتار صحیح است، اما در دو جهت ممکن است با شکست مواجه شود.

اگر تونل برقرار شود و نام‌ها دیگر resolve نشوند، در حالی که آدرس‌ها همچنان کار می‌کنند، به این معناست که resolver نصب‌شده توسط کلاینت از داخل تونل در دسترس نیست. دستور ping 1.1.1.1 با موفقیت اجرا می‌شود و curl https://example.com مقدار curl: (6) Could not resolve host: example.com را برمی‌گرداند. اگر در مقابل، تونل برقرار شود اما جستجوها همچنان به شبکه‌ای که به آن متصل هستید ارسال شوند، ترافیک شما از طریق تونل عبور می‌کند اما resolver محلی همچنان تمام نام‌هایی که درخواست می‌کنید را مشاهده می‌کند.

resolvectl status

این دستور resolver مورد استفاده برای هر لینک را چاپ می‌کند تا بتوانید ببینید تونل کدام یک را نصب کرده است و آیا همان چیزی است که مد نظر شما بوده یا خیر. یک تونل WireGuard این مورد را از طریق خط DNS = در پیکربندی کلاینت تنظیم می‌کند و رفع مشکل DNS هنگام کنترل resolver توسط WireGuard موارد مربوط به systemd-resolved و resolvconf را به‌طور دقیق پوشش می‌دهد.

کدهای پاسخ و معنای هر یک

• NXDOMAIN: یک سرور معتبر (authoritative) اعلام می‌کند که نام مورد نظر وجود ندارد. املای نام را بررسی کنید، وجود پسوند دامنه تکراری را چک کنید و مطمئن شوید که zone مورد نظر را که delegation به آن اشاره دارد، ویرایش کرده‌اید.
• NOERROR همراه با یک ANSWER SECTION خالی: نام وجود دارد، اما هیچ رکوردی از نوع درخواستی شما برای آن ثبت نشده است. درخواست AAAA در حالی که فقط یک A موجود است، دقیقاً منجر به این وضعیت می‌شود.
• SERVFAIL: resolver تلاش کرده اما نتوانسته پاسخی تولید کند. دو دلیل معمول برای این اتفاق وجود دارد: سرورهای معتبری که هرگز پاسخ نمی‌دهند و شکست در اعتبارسنجی DNSSEC (افزونه‌های امنیتی سیستم نام دامنه). با استفاده از dig @1.1.1.1 example.com A +cd که اعتبارسنجی را غیرفعال می‌کند، تست کنید. اگر با این کار پاسخ +cd و SERVFAIL دریافت کردید، مشکل از امضاها است؛ این اتفاق معمولاً پس از انتقال nameserver رخ می‌دهد، جایی که والد (parent) همچنان رکورد قدیمی DS (امضاکننده delegation) را منتشر می‌کند.
• REFUSED: سروری که از آن پرسش کرده‌اید به آن سوال پاسخ نخواهد داد؛ معمولاً به این دلیل که شما dig را به سمت یک سرور معتبر برای دامنه‌ای اشاره داده‌اید که آن سرور مسئولیتش را بر عهده ندارد.
• ;; connection timed out; no servers could be reached: دستور dig هرگز به یک resolver نرسیده است. این یک مشکل شبکه یا resolver در سمت شماست، بنابراین دامنه موضوع اصلی نیست.

ping: example.com: Temporary failure in name resolution همان کلاس از خطا است که توسط glibc گزارش می‌شود، نه توسط dig.

آیا باید nameserverها را روی VPS شخصی خود اجرا کنید؟

شما می‌توانید این کار را انجام دهید. bind9، knot یا nsd می‌توانند zone شما را از روی سرور سرویس‌دهی کنند و این کار بیش از هر پنل مدیریتی، دانش شما را درباره DNS افزایش می‌دهد. ایرادات این کار جنبه عملی دارند. یک دامنه باید حداقل دو nameserver در شبکه‌های مجزا داشته باشد؛ بنابراین یک VPS واحد به نقطه شکست برای تمام سرویس‌های آن دامنه، از جمله ایمیل، تبدیل می‌شود. nameserverهایی که درون دامنه‌ای که سرویس‌دهی می‌کنند نام‌گذاری شده‌اند، به glue record در نزد ثبت‌کننده دامنه نیاز دارند. این در واقع آدرس ns1.example.com است که در zone والد ذخیره می‌شود، زیرا در غیر این صورت، فرآیند lookup راهی برای شروع نخواهد داشت. هنگامی که یک resolver نتواند به nameserver شما دسترسی پیدا کند، به وب‌سایت شما fallback نمی‌کند: کل دامنه برای آن کاربر ناپدید می‌شود. برای اکثر افراد، استفاده از DNS میزبانی‌شده (Hosted DNS) که دارای API است، انتخاب کم‌خطر‌تری محسوب می‌شود. اجرای یک caching resolver روی VPS برای ماشین‌های شخصی خودتان، وظیفه‌ای متفاوت و با تعهد بسیار کمتر است.

FAQ

چرا تغییرات DNS من هنوز اعمال نشده است؟

هیچ چیزی در DNS منتشر نمی‌شود. سرورهای نام معتبر (authoritative nameservers) به محض ذخیره تغییرات، مقدار جدید را در خود نگه می‌دارند و هر resolver که قبلاً پرس‌وجو کرده است، کپی کش‌شده خود را تا زمان انقضای TTL دریافت شده حفظ می‌کند. با استفاده از dig @ns1.your-dns-host.net example.com A +short مستقیماً از سرور معتبر پرس‌وجو کنید. اگر این دستور آدرس جدید را برگرداند، تغییرات اعمال شده است و هر تأخیری که باقی مانده، مربوط به کش است. اگر به‌جای رکوردها، سرورهای نام (nameservers) را تغییر داده‌اید، انتظار زمان بسیار بیشتری داشته باشید، زیرا تفویض‌های TLD معمولاً با TTL دو روزه ارائه می‌شوند.

چگونه بفهمم دامنه‌ام در حال حاضر از چه سرورهای نامی استفاده می‌کند؟

دستور dig example.com NS +short سرورهای نامی که در حال حاضر پاسخگوی دامنه هستند را چاپ می‌کند و dig +trace example.com زنجیره ارجاع از ریشه (root) را نشان می‌دهد که شامل تفویض‌های ارائه‌شده توسط سرورهای TLD است. اگر این نام‌ها متعلق به ارائه‌دهنده‌ای نیستند که پنل آن را ویرایش کرده‌اید، مشکل همین‌جاست. یا رکوردها را در ارائه‌دهنده‌ای که در تفویض ذکر شده ویرایش کنید، یا تفویض را در ثبت‌کننده دامنه (registrar) تغییر دهید تا به مقصد مورد نظر شما اشاره کند.

دامنه من resolve می‌شود اما سایت بارگذاری نمی‌شود. حالا چه کنم؟

به محض اینکه dig example.com A +short آدرس سرور شما را برگرداند، کار DNS تمام شده است. پس از آن، مشکل مربوط به اتصال است. اگر curl -I http://example.com مقدار Connection refused را برگرداند، یعنی هیچ سرویسی روی آن پورت گوش نمی‌دهد. درخواستی که تا زمان timeout معلق می‌ماند، به این معناست که فایروال بسته را مسدود کرده است. بررسی کنید که وب‌سرور شما در حال اجرا باشد و به آدرس عمومی متصل شده باشد، سپس فایروال روی سرور و فایروال شبکه در پنل مدیریت ارائه‌دهنده خود را بررسی کنید.

چرا نمی‌توانم روی دامنه ریشه (root domain) رکورد CNAME قرار دهم؟

رکورد CNAME بیانگر این است که یک نام، مستعار (alias) برای نام دیگری است و نامی که دارای CNAME باشد، اجازه ندارد هیچ رکورد دیگری داشته باشد. دامنه ریشه شما برای اینکه به عنوان یک zone وجود داشته باشد، باید دارای رکوردهای SOA و NS باشد، بنابراین نمی‌تواند همزمان یک CNAME باشد. از یک رکورد A حاوی آدرس در ریشه استفاده کنید، یا از قابلیت ارائه‌دهنده که با نام‌های ALIAS، ANAME یا CNAME flattening فروخته می‌شود استفاده کنید؛ این قابلیت یک نام را ذخیره کرده و به پرس‌وجوها با آدرسی که آن نام در حال حاضر به آن resolve می‌شود، پاسخ می‌دهد.