ترمینال را باز کرده‌اید، dig زده‌اید و به‌جای رکورد A، یک کد سه‌حرفی برگشته. همان لحظه دو سؤال ذهن‌تان را پر می‌کند: این کد دقیقاً یعنی چه، و مشکل از سرور من است یا از جای دیگری؟ کد خطای DNS در واقع پاسخ رسمی رزولور است، نه پیام مبهم. اگر بدانید هر کد از کدام لایه می‌آید، در چند ثانیه جهت بررسی را پیدا می‌کنید.
کد خطای DNS از کجا می‌آید
هر پاسخ DNS یک فیلد چهاربیتی به نام RCODE دارد. مقدار صفر یعنی NOERROR و بقیه مقادیر یعنی چیزی در مسیر درست پیش نرفته. این کد را می‌تواند authoritative server تولید کند، می‌تواند رزولور میانی، و در بعضی موارد خود رزولور محلی شما. همین نکته کلید ماجراست: کد خطای DNS همیشه از سروری که دامنه را صاحب است نمی‌آید.
برای دیدن کد خام، از گزینه‌های dig استفاده کنید:
dig +noall +comments example.com A
dig +short example.com A
dig @1.1.1.1 example.com A +norecurseخط status: در بخش comments همان RCODE است. اگر +norecurse بزنید، رزولور پاسخ را از کش خودش نمی‌دهد و رفتار authoritative را نزدیک‌تر می‌بینید. برای بررسی رکوردهای DNS یک دامنه از چند نقطه، ابزار آنلاین بررسی رکوردهای DNS سریع‌تر از بالا و پایین کردن ترمینال است.
NXDOMAIN: نام وجود ندارد
این کد یعنی authoritative server قاطعانه می‌گوید چنین نامی در این zone تعریف نشده. دقت کنید: NXDOMAIN درباره نام است، نه درباره نوع رکورد. اگر mail.example.com وجود داشته باشد ولی رکورد AAAA نداشته باشد، پاسخ NXDOMAIN نیست؛ NOERROR با بخش پاسخ خالی است.
سه علت رایج:
- رکورد را در zone اشتباه ساخته‌اید، مثلاً زیر
www.example.com.example.comبه‌جایwww. - دامنه به nameserver دیگری اشاره می‌کند و شما در پنل اشتباه ویرایش می‌کنید.
- رکورد را حذف کرده‌اید و TTL قدیمی هنوز در کش رزولورها زنده است.
اینجا اشتباه می‌کنند: کاربر NXDOMAIN می‌بیند، فوراً رکورد جدید می‌سازد، و چند ساعت بعد دو رکورد متناقض در zone دارد. نشانه‌اش این است که پاسخها بین دو IP مختلف می‌چرخند و بعضی کاربران سایت را می‌بینند و بعضی نه. قبل از هر تغییری، اول با dig NS example.com مطمئن شوید کدام nameserver مرجع است.
SERVFAIL: رزولور نتوانست جواب را کامل کند
SERVFAIL مبهم‌ترین کد خطای DNS است، چون علت را نمی‌گوید. رزولور تلاش کرده و به نتیجه نرسیده. در عمل چهار علت بیشترین سهم را دارند:
- DNSSEC شکسته است. امضا منقضی شده یا رکورد DS در والد با کلید zone همخوان نیست.
- authoritative server روی پورت 53 از IP شما پاسخ نمی‌دهد یا timeout می‌خورد.
- zone روی دو nameserver با محتوای متفاوت لود شده و رزولور پاسخ متناقض می‌گیرد.
- رزولور میانی به سقف نرخ پاسخ‌دهی خورده است.
برای جدا کردن این حالت‌ها، مستقیم به authoritative بزنید:
dig @ns1.example.com example.com A +dnssec
dig +trace example.comاگر پاسخ مستقیم سالم است ولی از رزولور عمومی SERVFAIL می‌گیرید، مشکل تقریباً قطعاً DNSSEC یا ناهمخوانی nameserverهاست. اگر هر دو SERVFAIL می‌دهند، سراغ دسترس‌پذیری پورت 53 بروید. ترتیب دقیق این بررسی‌ها در راهنمای عملی عیب‌یابی DNS آمده است.
REFUSED و NOTAUTH و بقیه کدها
REFUSED یعنی سرور پاسخ را نمی‌دهد چون اجازه ندارد، نه چون نمی‌داند. رایج‌ترین صحنه: رزولور باز است و ادمین با ACL جلوی کوئری از شبکههای خارجی را گرفته. اگر dig @server روی سرور خودتان REFUSED می‌گیرد ولی از داخل شبکه جواب می‌گیرید، مشکل DNS نیست؛ سیاست دسترسی است.
NOTAUTH یعنی سروری که پرسیدید اصلاً مرجع این zone نیست. این را وقتی می‌بینید که IP یک سرور دیگر را به‌عنوان nameserver وارد کرده‌اید. FORMERR یعنی پیام کوئری از نظر ساختاری خراب است و تقریباً همیشه به باگ نرم‌افزار یا middlebox دستکاری‌کننده برمی‌گردد. NOTIMP هم یعنی سرور آن نوع کوئری را پیاده نکرده؛ روی سرورهای قدیمی با کوئری نوع SVCB یا HTTPS زیاد دیده میشود.
| کد | معنی | مسیر بررسی |
|---|---|---|
| NOERROR | پاسخ سالم، حتی اگر خالی باشد | نوع رکورد را چک کنید |
| NXDOMAIN | نام در zone وجود ندارد | zone و nameserver مرجع |
| SERVFAIL | رزولور به نتیجه نرسید | DNSSEC و پورت 53 |
| REFUSED | سرور اجازه پاسخ ندارد | ACL و allow-query |
| NOTAUTH | سرور مرجع این zone نیست | رکورد NS |
| FORMERR | کوئری ساختار خراب دارد | نسخه نرم‌افزار و middlebox |
کد خطای DNS را با TTL اشتباه نگیرید
بزرگ‌ترین سوءتفاهم این است که کاربر NXDOMAIN را با «هنوز منتشر نشده» قاطی می‌کند. NXDOMAIN یک پاسخ قطعی است، نه تأخیر. اگر رکورد را همین حالا ساخته‌اید و همچنان NXDOMAIN می‌بینید، احتمالاً TTL قبلی در کش مانده. مقدار TTL را ببینید:
dig example.com A +noall +answer
example.com. 3600 IN A 203.0.113.10عدد 3600 یعنی تا یک ساعت رزولورها مجازند پاسخ قدیمی را نگه دارند. برای تغییرات پرریسک، TTL را از قبل به 300 ثانیه کاهش دهید، تغییر را اعمال کنید، و بعد از تثبیت دوباره بالا ببرید. این هزینه‌ای دارد که کمتر گفته میشود: TTL کوتاه بار کوئری روی authoritative server را چند برابر می‌کند و روی دامنه‌های پرترافیک می‌تواند خودش منبع SERVFAIL باشد. جزئیات این چرخه در راهنمای TTL و کش DNS توضیح داده شده.
ترتیب درست بررسی
وقتی کد خطای DNS می‌گیرید، این ترتیب را رعایت کنید و از میان‌بر پرهیز کنید:
- با
dig NSببینید nameserverهای واقعی کدام‌اند. - مستقیم به همان nameserver کوئری بزنید و RCODE را ببینید.
- اگر مستقیم سالم بود، سراغ DNSSEC و کش رزولور بروید.
- اگر مستقیم خطا بود، zone و رکورد را در پنل DNS بررسی کنید.
برای دامنه‌های ir یک لایه اضافه هم وجود دارد: اگر ایرنیک یا nameserverهای داخلی در میان باشند، ممکن است پاسخ از بیرون درست و از داخل نادرست باشد. این حالت را جداگانه بررسی کنید، چون الگوی خطا با حالت عادی فرق دارد.
اگر دامنه را تازه ثبت کرده‌اید و هنوز به هیچ سروری وصل نیست، اول جستجو و ثبت دامنه و تنظیم رکوردها را کامل کنید و بعد سراغ عیب‌یابی بروید. برای پروژه‌هایی که DNS و وب‌سرور روی یک ماشین جمع می‌شوند، یک هاست لینوکس با دسترسی کامل به فایل zone کار را ساده‌تر می‌کند، چون می‌توانید مستقیم با dig @127.0.0.1 رفتار سرور خودتان را ببینید.
پرسش‌های پرتکرار
تفاوت NXDOMAIN و SERVFAIL در چیست؟
NXDOMAIN یک پاسخ قطعی است: نام در zone وجود ندارد. SERVFAIL یعنی رزولور نتوانسته به پاسخ برسد و علت را اعلام نمی‌کند. اگر NXDOMAIN می‌گیرید، رکورد یا zone را بررسی کنید؛ اگر SERVFAIL می‌گیرید، اول DNSSEC و دسترس‌پذیری پورت 53 را چک کنید.
چرا یک رزولور جواب میدهد و رزولور دیگر NXDOMAIN؟
تقریباً همیشه یعنی nameserverهای دامنه با هم همخوان نیستند یا یکی از آنها zone را لود نکرده. با dig @ns1 و dig @ns2 هر دو را جدا تست کنید. اگر پاسخها فرق داشت، مشکل propagation نیست، ناهمخوانی zone است.
کد REFUSED یعنی DNS من هک شده؟
نه. REFUSED معمولاً یعنی سرور بهدرستی جلوی کوئری از شبکههای غیرمجاز را گرفته است. اگر رزولور باز (open resolver) دارید، این کد نشانه تنظیم درست ACL است، نه نفوذ. برعکسش نگرانکننده است: رزولوری که به همه پاسخ میدهد و در حمله بازتابی استفاده میشود.
چقدر طول می‌کشد تا کد خطای DNS بعد از تغییر رکورد برطرف شود؟
به TTL قبلی رکورد بستگی دارد، نه به سرعت پنل. اگر TTL روی 3600 بوده، تا یک ساعت ممکن است بعضی کاربران پاسخ قدیمی ببینند. برای تغییرات حساس، TTL را از قبل کاهش دهید و بعد از تثبیت برگردانید.
یک قاعده را نگه دارید: کد خطای DNS را از منبع اصلی بخوانید، نه از کش. تا وقتی مستقیم به authoritative server کوئری نزده‌اید، هر نتیجه‌ای که می‌بینید می‌تواند مربوط به لایه‌ای باشد که کنترلش دست شما نیست.