سایت بالا نمی‌آید، مرورگر ERR_NAME_NOT_RESOLVED میدهد، ولی سرور با SSH جواب میدهد و curl -I http://127.0.0.1 هم 200 برمی‌گرداند. یعنی مشکل وب‌سرور نیست؛ جایی بین دامنه و سرور گم شده‌اید. این تقریباً همیشه یعنی یک رکورد در پنل DNS اشتباه است، یا درست است ولی هنوز منتشر نشده. تفاوت این دو حالت را در پنج دقیقه میشود تشخیص داد، به شرطی که بدانید کجا را نگاه کنید.
قبل از هر تغییری، وضعیت فعلی را از بیرون ببینید، نه از پنل. پنل چیزی را نشان میدهد که شما ذخیره کردهاید؛ رزولورها چیزی را نشان می‌دهند که واقعاً در اینترنت پخش شده. این دو تا وقتی TTL بالا باشد، ساعت‌ها با هم فرق دارند.
dig +short A example.com @1.1.1.1
dig +short A example.com @8.8.8.8
dig +trace example.comاگر جواب 1.1.1.1 و 8.8.8.8 یکی نیست، شما در میانه انتشار هستید و هیچ کاری نباید بکنید جز صبر. اگر هر دو یک IP اشتباه می‌دهند، رکورد غلط است. اگر NXDOMAIN می‌گیرید، رکورد اصلاً وجود ندارد یا روی zone اشتباه ثبت شده. برای دیدن زنجیره کامل از ریشه تا authoritative، از بررسی رکوردهای DNS هم می‌توانید استفاده کنید که همان خروجی را خوانا نشان میدهد.
کدام رکورد را باید عوض کنید
بیشتر سردرگمی‌ها از اینجا شروع میشود که چهار نوع رکورد شبیه هم به نظر می‌رسند ولی کارشان کاملاً جداست.
| نوع | کارش | مقدار نمونه |
|---|---|---|
A | نام را به IPv4 وصل میکند | example.com. 3600 IN A 185.10.20.30 |
AAAA | همان کار برای IPv6 | example.com. 3600 IN AAAA 2a01::1 |
CNAME | نام را به نام دیگر می‌چسباند | www 3600 IN CNAME example.com. |
MX | مقصد ایمیل را تعیین میکند | example.com. 3600 IN MX 10 mail.example.com. |
نکته‌ای که خیلی‌ها را زمین می‌زند: CNAME روی ریشه دامنه (@) مجاز نیست. اگر پنل اجازه بدهد، بعضی رزولورها آن را نادیده می‌گیرند و بعضی دیگر کل zone را نامعتبر می‌بینند. برای ریشه همیشه A بگذارید. اگر ارائهدهندهای می‌گوید «CNAME مسطح» یا ALIAS، آن یک رکورد اختصاصی است که در پاسخ نهایی به A تبدیل میشود، نه CNAME واقعی.
برای زیردامنه‌ها برعکس است: CNAME انتخاب بهتری است چون اگر IP سرور مقصد عوض شود، شما دست به پنل نمی‌زنید. فقط یادتان باشد که CNAME و هر رکورد دیگر با همان نام، با هم جمع نمی‌شوند. اگر mail را CNAME کردهاید، نمی‌توانید همزمان MX روی همان نام بگذارید.
TTL را چطور انتخاب کنیم
TTL واحدش ثانیه است و می‌گوید رزولورها چند وقت اجازه دارند جواب را کش کنند. عددی که در پنل می‌بینید معمولاً بین 300 و 86400 است. کوتاه‌ترین گزینه همیشه درست نیست؛ هر کاهش TTL یعنی کوئری بیشتر به نیم‌سرورهای شما و بار بیشتر روی آن‌ها.
- سایت زنده و پایدار: 3600 تا 86400. کمترش هیچ سودی ندارد.
- قبل از مهاجرت برنامه‌ریزی‌شده: 24 تا 48 ساعت قبل به 300 برسانید، بعد از تثبیت برگردانید.
- رکوردهای پویا یا DDNS: 60 تا 300، وگرنه IP عوض میشود و کاربر هنوز آدرس قدیمی را می‌بیند.
- رکوردهای ایمیل مثل SPF و DKIM: دست نزنید. تغییرات ایمیل کندتر از وب جا می‌افتند و گیرنده‌ها کش خودشان را دارند.
یک محدودیت واقعی که کمتر گفته میشود: TTL را شما تعیین می‌کنید، ولی رزولورها موظف نیستند به آن احترام بگذارند. بعضی ISPهای داخلی تا چند برابر TTL اعلام‌شده کش میکنند. اگر TTL را 300 گذاشتید و بعد از نیم ساعت هنوز IP قدیمی را می‌بینید، احتمالاً مشکل شما نیست. جزئیات این رفتار را در انتشار DNS چیست و چرا زمان میبرد با مثال عددی توضیح داده‌ام.
ترتیب امن تغییر رکورد روی سایت زنده
اینجا جایی است که بیشتر خرابی‌ها اتفاق می‌افتد. ترتیب کار مهم‌تر از خود کار است.
- TTL رکورد فعلی را به 300 کاهش دهید و حداقل یک TTL کامل صبر کنید تا کش‌های قدیمی منقضی شوند.
- مقصد جدید را جدا از دامنه تست کنید:
curl -I --resolve example.com:443:185.10.20.40 https://example.com. اگر اینجا SSL خطا داد، هنوز آماده نیستید. - رکورد را ویرایش کنید، نه حذف و ساخت دوباره. حذف و ساخت، پنجره‌ای ایجاد میکند که در آن نام اصلاً resolve نمی‌شود.
- با
dig +short A example.com @1.1.1.1تأیید کنید که IP جدید آمده. - بعد از 24 ساعت پایدار، TTL را به مقدار قبلی برگردانید.
اگر مهاجرت به سرور جدید است و SSL هم درگیر است، ترتیب رکورد و صدور گواهی را در اتصال دامنه به سرور مجازی قدم‌به‌قدم نوشته‌ام؛ اشتباه رایج این است که گواهی را قبل از تغییر رکورد صادر میکنند و بعد از تغییر، دامنه به سروری می‌رسد که آن گواهی را ندارد.
اینجا اشتباه میکنند
رایج‌ترین اشتباهی که در تیکت‌ها می‌بینم این است: کاربر رکورد A را درست تغییر میدهد، ولی رکورد www را که یک CNAME جدا به یک هاست اشتراکی قدیمی است فراموش میکند. سایت با example.com باز میشود، با www.example.com نسخه قدیمی را نشان میدهد. نشانه‌اش این است که کاربر می‌گوید «سایت عوض شده ولی بعضی‌ها هنوز قدیمی می‌بینند» و مشکل اصلاً کش نیست. قبل از هر مهاجرت، لیست کامل رکوردها را بگیرید:
dig +noall +answer example.com ANY
dig +short CNAME www.example.comاشتباه دوم: گذاشتن * به‌عنوان wildcard وقتی فقط یک زیردامنه لازم دارید. نتیجه‌اش این است که هر نام تایپی هم به سایت شما می‌رسد و ربات‌های اسکن، هزاران زیردامنه جعلی روی دامنه شما ثبت میکنند. اگر واقعاً به زیردامنه پویا نیاز دارید، روش درست را در رکورد wildcard و مدیریت زیردامنه‌های پویا توضیح داده‌ام.
رکوردهای ایمیل را جداگانه ببینید
تغییر رکورد A روی ایمیل اثری ندارد، ولی تغییر MX کل مکاتبات را می‌خواباند. قبل از هر تغییری روی MX، خروجی این دستور را ذخیره کنید:
dig +short MX example.com
dig +short TXT example.comرکورد TXT معمولاً شامل SPF است و یک اشتباه رایج در آن، عبور از سقف 255 کاراکتر در یک رشته است. اگر SPF طولانی دارید، باید آن را به چند رشته تقسیم کنید؛ بعضی پنلها این کار را خودکار انجام می‌دهند و بعضی نه، و نتیجه‌اش این است که SPF شما بی‌صدا نامعتبر میشود و ایمیل‌ها به اسپم می‌روند. نشانه‌اش هم واضح نیست: ارسال موفق است، تحویل نه.
اگر دامنه‌تان .ir است، یک لایه اضافه هم دارید: تغییر نیم‌سرورها و بعضی ویرایش‌ها از سمت ایرنیک اعمال میشود، نه فقط پنل. تفاوت این دو مسیر را در راهنمای ثبت و مدیریت دامنه ir جدا کرده‌ام، چون ترتیب کار در این دامنه‌ها فرق میکند و اشتباه در آن چند روز تأخیر می‌سازد.
وقتی هیچ‌کدام جواب نمیدهد
اگر رکورد درست است، TTL گذشته، و هنوز resolve نمی‌شود، مشکل تقریباً همیشه یکی از این سه است: نیم‌سرورهای دامنه در پنل ثبت دامنه به نیم‌سرورهای واقعی zone اشاره نمی‌کنند، zone روی نیمسرور اشتباه ساخته شده، یا دامنه منقضی شده و در حالت clientHold است. حالت سوم را با whois example.com | grep -i status ببینید. اگر clientHold دیدید، هیچ تغییری در DNS نجات نمیدهد؛ باید اول تمدید شود. ترتیب کامل بررسی این حالت‌ها را در راهنمای عملی عیب‌یابی DNS نوشته‌ام و پیشنهاد می‌کنم قبل از باز کردن تیکت، همان ترتیب را یک‌بار اجرا کنید.
یک نکته درباره میزبانی: اگر سایت روی هاست اشتراکی است، معمولاً نیم‌سرورهای ارائه‌دهنده را ست می‌کنید و رکوردها را از پنل خودشان مدیریت می‌کنید؛ در این حالت دست شما برای بعضی رکوردها بسته است. روی هاست لینوکس این رکوردها از همان پنل قابل ویرایش‌اند و برای اکثر سایت‌ها کافی است. اگر به رکوردهای غیرمعمول مثل SRV یا کنترل کامل zone نیاز دارید، سرور مجازی با نیمسرور اختصاصی انتخاب درست‌تری است.
قبل از هر تغییری، این یک کار را انجام دهید: خروجی dig +noall +answer example.com ANY را جایی ذخیره کنید. وقتی سایت خوابید، داشتن وضعیت قبلی تفاوت بین پنج دقیقه و پنج ساعت است.
پرسش‌های پرتکرار
چرا بعد از تغییر رکورد A سایت هنوز IP قدیمی را نشان میدهد؟
چون رزولورها جواب قبلی را تا پایان TTL کش کردهاند. اگر TTL را قبل از تغییر کم نکرده باشید، این حالت میتواند تا 24 ساعت طول بکشد. با dig +short A example.com @8.8.8.8 و @1.1.1.1 چک کنید؛ اگر یکی جدید و یکی قدیمی است، فقط باید صبر کنید.
کمترین TTL که میتوانم بگذارم چقدر است؟
اکثر پنلها حداقل 60 ثانیه را قبول میکنند و بعضی تا 300 ثانیه محدود میکنند. کمتر از 60 ثانیه در عمل سودی ندارد چون رزولورها موظف به رعایت آن نیستند و فقط بار کوئری روی نیمسرور شما را بالا میبرد.
آیا میتوانم رکورد CNAME را روی ریشه دامنه بگذارم؟
نه. استاندارد DNS اجازه CNAME روی ریشه را نمیدهد چون با رکوردهای اجباری NS و SOA تضاد پیدا میکند. برای ریشه از A استفاده کنید. اگر ارائهدهندهای گزینهای به نام ALIAS یا CNAME مسطح دارد، آن یک رکورد اختصاصی است که در پاسخ نهایی به A تبدیل میشود.
تغییر رکورد MX چه تأثیری روی ایمیلهای قبلی دارد؟
ایمیلهایی که قبلاً تحویل داده شدهاند دستنخورده میمانند. اما ایمیلهایی که در بازه انتشار در راه هستند ممکن است به سرور قدیمی برسند و در آنجا رد شوند. اگر سرور قدیمی را خاموش کردهاید، برای چند ساعت ایمیل از دست میرود؛ قبل از تغییر MX مطمئن شوید سرور قدیمی هنوز پاسخ میدهد.