سایت بالا نمیآید و مرورگر میگوید DNS_PROBE_FINISHED_NXDOMAIN. یا ایمیلهای تراکنشی به پوشه اسپم میروند و مشتری میگوید «ایمیل تأیید سفارش نیامد». در هر دو حالت، پیش از دستزدن به سرور، باید بفهمید کدام رکورد DNS را اشتباه ثبت کردهاید. این متن نحو دقیق هر رکورد را با مثال واقعی میآورد تا بتوانید همین امروز مشکل را ببندید.
پیش از هر چیز: با چه ابزاری رکورد DNS را ببینید
قبل از تغییر، وضعیت فعلی را ثبت کنید. اگر این کار را نکنید، بعد از تغییر نمیدانید چه چیزی خراب شده بود.
dig +short A example.com
dig +short MX example.com
dig +short TXT example.com @8.8.8.8
dig +trace example.com
دستور dig +trace مسیر کامل از ریشه تا سرور authoritative را نشان میدهد و وقتی گیر میکنید که «رکورد را ثبت کردم ولی اعمال نشده»، تنها ابزار واقعی همین است. اگر dig نصب نیست، از nslookup -type=MX example.com استفاده کنید. برای بررسی سریع از داخل مرورگر هم میتوانید از ابزارهای رایگان بررسی DNS و دامنه سرورنت استفاده کنید.
رکورد A و AAAA: آدرس IPv4 و IPv6
رکورد A یک نام دامنه را به آدرس IPv4 نگاشت میکند. سادهترین رکورد است و بیشترین خطا هم در همین رخ میدهد.
example.com. 3600 IN A 185.10.20.30
www.example.com. 3600 IN A 185.10.20.30
عدد 3600 همان TTL است، بر حسب ثانیه. یعنی رزولورها تا یک ساعت نسخه کششده را نگه میدارند. اگر میخواهید مهاجرت سریع اعمال شود، TTL را ۲۴ ساعت قبل از تغییر به 300 کاهش دهید، بعد تغییر را بزنید، و بعد از پایدارشدن دوباره بالا ببرید. اینجا اشتباه میکنند: TTL را همان لحظهٔ مهاجرت کم میکنند و بعد میبینند تا یک ساعت سایت روی سرور قدیمی میرود. کش قبلی را کسی پاک نمیکند.
رکورد AAAA همان کار را برای IPv6 انجام میدهد. اگر سرورتان IPv6 ندارد، رکورد AAAA را ثبت نکنید. ثبت AAAA به آدرسی که مسیر برگشت ندارد، باعث میشود بخشی از کاربران با تأخیر چند ثانیهای وارد شوند؛ چون کلاینت اول IPv6 را امتحان میکند، شکست میخورد، و بعد سراغ IPv4 میرود.
رکورد CNAME: نام مستعار، با یک محدودیت مهم
CNAME یک نام را به نام دیگر اشاره میدهد، نه به IP. کاربرد اصلیاش زیردامنههایی است که به سرویس بیرونی وصل میشوند.
shop.example.com. 3600 IN CNAME example.myshopify.com.
mail.example.com. 3600 IN CNAME mail.provider.net.
نکتهٔ آخر خط را ببینید: نقطهٔ انتهایی. اگر آن را جا بگذارید، بعضی پنلها نام را نسبی تفسیر میکنند و رکورد به example.myshopify.com.example.com تبدیل میشود. نتیجهاش خطای NXDOMAIN است و شما فکر میکنید سرویس بیرونی خراب است.
محدودیت واقعی CNAME این است: در رکورد apex (یعنی خود example.com بدون زیردامنه) استاندارد اجازه نمیدهد CNAME بگذارید، چون با MX و NS تداخل میکند. بعضی ارائهدهندههای DNS این کار را با ترفند «CNAME flattening» ممکن میکنند، ولی نتیجه دیگر یک CNAME واقعی نیست؛ یک رکورد A است که پشت صحنه ساخته میشود. اگر روی DNS خودتان کنترل کامل دارید و میخواهید دامنهٔ اصلی به یک سرویس ابری وصل شود، این ترفند کار میکند. اگر نه، از رکورد A استفاده کنید.
رکورد MX: چرا ایمیل نمیرسد
رکورد MX میگوید ایمیل دامنه را کدام سرور دریافت کند. عدد جلوی آن اولویت است؛ عدد کمتر یعنی اولویت بالاتر.
example.com. 3600 IN MX 10 mail1.provider.net.
example.com. 3600 IN MX 20 mail2.provider.net.
دو خطای رایج. اول، گذاشتن نقطه در انتهای مقدار MX؛ اگر mail1.provider.net را بدون نقطه بنویسید، بعضی پنلها آن را به دامنهٔ خودتان میچسبانند و ایمیل به سرور اشتباه میرود. دوم، استفاده از CNAME بهجای MX. استاندارد صریح میگوید مقدار MX باید نام میزبان باشد، نه نام مستعار. بعضی سرورهای ایمیل این را تحمل میکنند و بعضی نه؛ و وقتی نه، ایمیل بیصدا گم میشود.
اگر ایمیل میرود ولی در اسپم میافتد، مشکل MX نیست. باید SPF و DKIM را در رکورد TXT بررسی کنید.
رکورد TXT: SPF، DKIM و تأیید مالکیت
TXT متن آزاد نگه میدارد و امروز بیشتر برای احراز هویت ایمیل استفاده میشود.
example.com. 3600 IN TXT "v=spf1 include:_spf.provider.net -all"
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
در SPF فقط یک رکورد مجاز است. اگر دو رکورد v=spf1 داشته باشید، نتیجه permerror میشود و گیرنده پیام را رد میکند. اینجا اشتباه میکنند: هنگام اضافهکردن سرویس ایمیل جدید، یک TXT دوم میسازند بهجای اینکه include را به رکورد موجود اضافه کنند. علائمش این است که ایمیلها بهطور نامنظم به اسپم میروند و لاگ سرور مقصد SPF permerror نشان میدهد.
مقدار DKIM طولانی است و بعضی پنلها آن را در چند رشته میشکنند. اگر رکورد را دستی کپی میکنید، مطمئن شوید کلید کامل و بدون فاصلهٔ اضافه ثبت شده؛ یک کاراکتر کم، امضا را باطل میکند.
رکورد SRV و CAA: کمکاربرد ولی حیاتی
SRV شمارهٔ پورت و میزبان سرویس را کنار هم اعلام میکند. نحو آن چهار عدد و یک نام دارد:
_sip._tcp.example.com. 3600 IN SRV 10 5 5060 sipserver.example.com.
ترتیب اعداد: اولویت، وزن، پورت، مقصد. جابهجا نوشتن وزن و پورت خطای رایجی است که فقط وقتی خودش را نشان میدهد که سرویس VoIP یا XMPP وصل نمیشود و شما دنبال مشکل در فایروال میگردید.
رکورد CAA مشخص میکند کدام مرجع صدور گواهی اجازه دارد برای دامنهٔ شما SSL صادر کند:
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
اگر CAA را سختگیرانه ببندید و بعد بخواهید از مرجع دیگری گواهی بگیرید، صدور شکست میخورد و پیام خطا در لاگ ACME چیزی شبیه CAA record forbids issuance است. این محدودیت امنیتی است، نه باگ. اگر تیم شما گواهی را از چند مرجع میگیرد، یا CAA نگذارید یا هر دو مرجع را مجاز کنید.
کدام رکورد را کجا ثبت کنیم
| رکورد | به چه چیزی اشاره میکند | کاربرد اصلی | خطای رایج |
|---|---|---|---|
| A | آدرس IPv4 | دامنهٔ اصلی و www | IP قدیمی بعد از مهاجرت |
| AAAA | آدرس IPv6 | فقط اگر IPv6 فعال است | ثبت بدون مسیر برگشت |
| CNAME | نام دیگر | زیردامنههای سرویس بیرونی | استفاده در apex |
| MX | سرور ایمیل | دریافت ایمیل دامنه | نقطهٔ انتهایی جاافتاده |
| TXT | متن آزاد | SPF، DKIM، DMARC | دو رکورد SPF |
| SRV | میزبان و پورت | VoIP، XMPP، برخی بازیها | جابهجایی وزن و پورت |
| CAA | مرجع صدور گواهی | محدودکردن صدور SSL | بستن بیدلیل روی یک مرجع |
اگر سایت وردپرسی دارید و بعد از تغییر رکورد A با خطای اتصال دیتابیس روبهرو شدید، مشکل DNS نیست؛ مسیر عیبیابی را در راهنمای خطای اتصال دیتابیس وردپرس دنبال کنید. برای پروژههایی که روی زیرساخت لینوکسی میزبانی میشوند و میخواهید کنترل کامل روی ناحیهٔ DNS داشته باشید، هاست لینوکس گزینهٔ منطقیتری از پنلهای بسته است. اگر هم روی وردپرس کار میکنید و میخواهید بدون بازکردن پنل، رکوردها و کش را از ترمینال بررسی کنید، دستورهای ضروری WP-CLI وقت زیادی از شما میگیرد.
ترتیب کار وقتی چیزی خراب است
- با
dig +shortوضعیت فعلی را ثبت کنید. - مشخص کنید کدام رکورد مسئول آن علامت است: NXDOMAIN یعنی A یا CNAME، ایمیل نرسیدن یعنی MX و TXT، خطای SSL یعنی CAA یا گواهی.
- TTL را قبل از تغییر کم کنید، نه بعدش.
- بعد از تغییر، از دو رزولور مختلف (
@8.8.8.8و@1.1.1.1) بررسی کنید. - اگر بعد از TTL هنوز اعمال نشده، با
dig +traceببینید کدام سرور پاسخ قدیمی میدهد.
یک نکتهٔ آخر که کمتر گفته میشود: تغییر رکورد DNS هرگز فوری نیست و هیچ راهی برای فوریکردنش وجود ندارد. اگر کسی به شما گفت کش را پاک میکند و بلافاصله اعمال میشود، فقط کش خودش را پاک کرده. کش رزولورهای میانی دست شما نیست. پس تغییرهای DNS را در بازهٔ کمترافیک و با حوصله انجام دهید، و همیشه یک نسخه از ناحیهٔ فعلی را قبل از دستزدن ذخیره کنید.
پرسشهای پرتکرار
تفاوت رکورد A و CNAME چیست؟
رکورد A یک نام را مستقیم به آدرس IP وصل میکند، ولی CNAME یک نام را به نام دیگر اشاره میدهد و رزولور باید یک مرحلهٔ دیگر Query بزند. برای دامنهٔ اصلی همیشه A بگذارید؛ CNAME برای زیردامنههایی است که به سرویس بیرونی وصل میشوند.
چرا بعد از تغییر رکورد DNS سایت هنوز بالا نمیآید؟
چون رزولورها نسخهٔ قدیمی را تا پایان TTL کش نگه میدارند. اگر TTL روی ۳۶۰۰ باشد، تا یک ساعت ممکن است سایت قدیمی را ببینید. با dig +trace example.com میتوانید ببینید کدام سرور پاسخ قدیمی میدهد.
آیا میتوانم برای دامنهٔ اصلی CNAME ثبت کنم؟
در استاندارد DNS نه، چون CNAME در apex با رکوردهای MX و NS تداخل میکند. بعضی ارائهدهندهها با CNAME flattening این کار را شبیهسازی میکنند، ولی در واقع یک رکورد A پشت صحنه ساخته میشود.
چند رکورد SPF میتوانم داشته باشم؟
فقط یکی. اگر دو رکورد TXT با v=spf1 ثبت کنید، نتیجه permerror میشود و سرورهای گیرنده ایمیل شما را رد یا اسپم میکنند. سرویس جدید را با include به همان رکورد موجود اضافه کنید.
دیدگاهها ۰
هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!