خطای SERVFAIL یعنی سرور DNS نتوانسته برای پرس‌وجوی شما پاسخ قابل‌استفاده بسازد؛ این پیام به‌تنهایی علت را مشخص نمی‌کند. برای پیدا کردن مسیر رفع مشکل، ابتدا نام و نوع رکورد را ثابت نگه دارید، نتیجهٔ دو DNS را مقایسه کنید و سپس توضیح خطا یا EDE را بخوانید. ناهماهنگی DNSSEC، مشکل نیم‌سرورهای مرجع و اختلال مسیر شبکه از علت‌های قابل بررسی‌اند؛ SERVFAIL الزاماً به معنی حذف‌شدن دامنه نیست.
این آموزش برای مالک سایت و کسی است که می‌خواهد قبل از تغییر تنظیمات، محل مشکل را پیدا کند. همهٔ فرمان‌های این صفحه فقط پرس‌وجو می‌کنند؛ رکورد، نیم‌سرور و تنظیم DNS دستگاه را تغییر نمی‌دهند. اگر تفاوت DNS عمومی و نیم‌سرور دامنه روشن نیست، ابتدا راهنمای DNS به زبان ساده را ببینید.
۱. مطمئن شوید خطا واقعاً SERVFAIL است
پیام کلی «سایت باز نمی‌شود» برای تشخیص کافی نیست. نتیجهٔ ابزار DNS را بخوانید. کدهای زیر در دفتر رسمی کدهای پاسخ DNS در IANA تعریف شده‌اند:
| نتیجه | برداشت درست |
|---|---|
| SERVFAIL / 2 | پاسخ‌دهنده در پردازش سؤال شکست خورده؛ باید علت را پیدا کنیم. |
| NXDOMAIN / 3 | نام پرسیده‌شده ناموجود گزارش شده؛ برای مسیر متفاوت عیب‌یابی، آموزش رفع NXDOMAIN را ببینید. |
| NOERROR / 0 | کد خطایی گزارش نشده؛ وجود پاسخِ نوع رکورد موردنیاز را هم کنترل کنید. |
| timeout | در مهلت تعیین‌شده پاسخ نگرفته‌اید؛ این یک پاسخ SERVFAIL نیست. |
در JSON گوگل، مقدار Status: 2 همان SERVFAIL است. HTTP200 فقط یعنی درخواست وبِ ابزار پاسخ گرفته؛ سلامت DNS دامنه را ثابت نمی‌کند. معنی فیلدها در مستند رسمی API گوگل آمده است.
۲. نمونهٔ واقعی را بدون تغییر تنظیمات ببینید
- ابزار رسمی Google Public DNS را باز کنید.
- برای دیدن نمونهٔ آموزشی، نام
dnssec-failed.orgرا وارد و روی Resolve کلیک کنید. - نوع رکورد را A نگه دارید. گزینهٔ Disable DNSSEC validation باید خاموش باشد تا اعتبارسنجی فعال بماند.
- مقدار Status و متن Comment یا extended_dns_errors را بخوانید؛ صرف نبودن Answer تشخیص کافی نیست.
چرا این نام؟ این دامنه در پرسش‌های متداول رسمی گوگل به‌عنوان نمونهٔ زنجیرهٔ اعتماد معیوب معرفی شده است؛ خرابی سایت یک مشتری را برای آزمایش ایجاد نکرده‌ایم. در همان پاسخ واقعیِ ثبت‌شده، EDE با مقدار 9 و متن No DNSKEY matches DS RRs دیده شد: کلیدِ سازگار با DS پیدا نشده است.
حد این نمونه: این نتیجه فقط یک علت واقعیِ SERVFAIL را نشان می‌دهد. از روی آن نمی‌توان گفت همهٔ SERVFAILها مربوط به DNSSEC هستند یا دامنهٔ شما هم همین مشکل را دارد. برای نام عمومی خودتان، همان مراحل را جدا انجام دهید؛ نام داخلی سازمان و اطلاعات خصوصی را به ابزار عمومی نفرستید.
۳. یک سؤال ثابت را از دو DNS بپرسید
در ویندوز، PowerShell یا Command Prompt را باز کنید. برای تمرین همان نام آزمایشی را بپرسید:
nslookup -type=A dnssec-failed.org 8.8.8.8در اجرای واقعی این فرمان برای این آموزش، ابزار عبارت Server failed برگرداند. ممکن است متن پیام در نسخه یا زبان سیستم متفاوت باشد. برای بررسی دامنهٔ خودتان، فقط نام عمومی را جایگزین کنید و سؤال را از DNS دوم هم بپرسید:
nslookup -type=A example.com 8.8.8.8
nslookup -type=A example.com 1.1.1.1نام example.com نمونه است؛ این دو فرمان قرار نیست خرابی دامنهٔ شما را خودکار تشخیص دهند. طبق مستند nslookup مایکروسافت، آرگومان دوم سرورِ مورد پرس‌وجو را تعیین می‌کند. اگر در خواندن بخش Server و پاسخ رکورد تردید دارید، آموزش nslookup در ویندوز را بخوانید.
- هر دو SERVFAIL دارند: مشکل مشترک دامنه یا مرجع آن محتمل است؛ جزئیات خطا و نیم‌سرورها بررسی شوند.
- یکی پاسخ دارد: نتیجه را همراه زمان ثبت کنید؛ اختلاف کش، مسیر و رفتار resolverها باید بررسی شود. یک پاسخ موفق به معنی سلامت کامل نیست.
- یکی timeout دارد: ابتدا دسترسی همان شبکه به DNS انتخابی را بررسی کنید؛ timeout را به خطای DNSSEC تبدیل نکنید.
مقایسه زمانی معنی دارد که نام دقیق، نوع رکورد و زمان آزمایش نزدیک باشند. دامنهٔ اصلی را با www یا رکورد A را با AAAA مقایسه نکنید و از دو آزمایش، وضعیت همهٔ کاربران را نتیجه نگیرید.
۴. از جزئیات خطا به علت نزدیک شوید
افزونهٔ EDE یا Extended DNS Error توضیحی دقیق‌تر از کد کلی ارائه می‌کند، ولی وجودش در همهٔ پاسخ‌ها الزامی نیست. RFC8914 مشخص می‌کند EDE جای کد اصلی پاسخ را نمی‌گیرد. نبود آن، سالم‌بودن DNSSEC را هم ثابت نمی‌کند.
| نشانهٔ کمکی | بررسی بعدی |
|---|---|
| DNSSEC Bogus — 6 | اعتبارسنجی زنجیره، کلید و امضاها؛ از روی این کد به‌تنهایی DS را حذف نکنید. |
| DNSKEY Missing — 9 | دریافت کلیدهای ناحیه و سازگاری آن‌ها با DS؛ به‌ویژه پس از جابه‌جایی DNS. |
| No Reachable Authority — 22 | دسترسی resolver به نیم‌سرورهای مرجع و اینکه برای ناحیه پاسخ معتبر می‌دهند. |
| Network Error — 23 | جزئیات متن را بخوانید؛ خطای ارتباط یا پاسخ بالادستی نیاز به بررسی دارد. |
متن اضافی EDE و دامنه‌ای که در آن نام برده شده را کنار شماره نگه دارید. این جدول با راهنمای EDE کلادفلر تطبیق داده شده؛ متن و جزئیات تشخیصی resolverها ممکن است یکسان نباشد.
اگر dig دارید
در لینوکس یا مک، در صورت نصب بودن ابزار dig، می‌توانید پاسخ کامل را ببینید:
dig @8.8.8.8 example.com A +dnssec
dig @1.1.1.1 example.com A +dnssecخط status و در صورت وجود، EDE در OPT PSEUDOSECTION را بخوانید. گزینهٔ +dnssec درخواست داده‌های DNSSEC است؛ خودِ dig با این گزینه به یک اعتبارسنج مستقل تبدیل نمی‌شود. سالم‌بودن خروجی +trace نیز به‌تنهایی سلامت اعتبارسنجی را ثابت نمی‌کند. معنای گزینه‌ها در راهنمای رسمی dig در BIND آمده است.
فرمان‌های dig این بخش با مستندات تطبیق داده شده‌اند و در محیط تهیهٔ این مقاله اجرا نشده‌اند. مثال اجراییِ تأییدشدهٔ این صفحه، پرس‌وجوی وب گوگل و nslookup ویندوز است.
۵. مسیر رفع مشکل را به مسئول درست وصل کنید
خطا بعد از تغییر نیم‌سرور یا سرویس DNS شروع شده
زمان تغییر و نام سرویس قبلی و فعلی را مشخص کنید. سپس از مدیر DNS بخواهید واگذاری دامنه، کلیدهای فعال و DS در ناحیهٔ والد را با هم تطبیق دهد. باقی‌ماندن DS ناسازگار یکی از احتمال‌هاست؛ انتقال دامنه به‌تنهایی دلیل قطعی نیست. برای فهم نقش این اجزا، راهنمای DNSSEC و زنجیرهٔ اعتماد را بخوانید؛ این مقاله دستور حذف DS یا تغییر کلید نمی‌دهد.
نیم‌سرورهای مرجع پاسخ نمی‌دهند یا ناسازگارند
نام نیم‌سرورهای واگذارشده و گزارش خطا را به ارائه‌دهندهٔ DNS بدهید تا وجود Zone، پاسخ‌گویی سرورها، واگذاری و مسیر UDP/TCP53 را بررسی کند. در دامنه‌هایی که نیم‌سرورها زیر همان دامنه‌اند، اطلاعات glue هم ممکن است نیاز به بررسی داشته باشد. راهنمای عیب‌یابی دامنه در گوگل این مسیرها را از مشکل DNSSEC جدا بررسی می‌کند. نتیجهٔ آزمون از یک شبکه را به تمام مسیرها تعمیم ندهید.
نمی‌دانید کدام پنل مسئول است
محل واقعی مدیریت DNS دامنه را مشخص کنید. مدیر DNS مسئول Zone و امضاهاست؛ ثبت‌کنندهٔ دامنه مسیر مدیریت واگذاری و DS را فراهم می‌کند. تغییر تصادفی در سی‌پنلی که مرجع DNS نیست، علت را برطرف نمی‌کند.
مشاهدهٔ بخش DNSSEC در سی‌پنل
اگر DNS معتبر دامنه واقعاً روی همین سرویس سی‌پنل مدیریت می‌شود، برای دیدن بخش مربوط، از Tools ← Domains ← Zone Editor وارد فهرست دامنه‌ها شوید. کنار دامنهٔ خود، دکمهٔ DNSSEC را پیدا کنید؛ دکمهٔ Manage برای مشاهده و مدیریت رکوردهای Zone است. عکس زیر از محیط واقعیِ هاستِ مجاز تهیه شده است؛ نام دامنه برای حفظ حریم خصوصی بلور شده است.
با بازکردن DNSSEC، جدول کلیدهای همین محیط را می‌بینید. در اجرای مشاهده‌ای ما، پیام No keys found نمایش داده شد. برای تهیهٔ این تصویر، کلیدی ساخته یا وارد نشده است.
این پیام را درست تفسیر کنید: خالی‌بودن جدول محلی ثابت نمی‌کند DS در ناحیهٔ والد وجود ندارد یا DNSSEC دامنه خراب است؛ ممکن است DNS فعال در سرویس دیگری مدیریت شود. بدون شناخت مرجع فعال و وضعیت DS، روی Create Key یا Import Key کلیک نکنید. این گام فقط مشاهده است. جای این کنترل‌ها و وابستگی دسترسی به تنظیمات ارائه‌دهنده در مستند رسمی Zone Editor سی‌پنل توضیح داده شده است.
قبل از اصلاح حساس: تغییر DS، کلید، نیم‌سرور یا فایروال می‌تواند سایت و ایمیل را قطع کند. مسئول فنی باید وضعیت فعلی، نسخهٔ پشتیبان تنظیمات، وابستگی‌ها، ترتیب تغییر، شرط توقف و مسیر بازیابی را مشخص کند. خاموش‌کردن اعتبارسنجی DNSSEC یا عوض‌کردن تصادفی resolver، اصلاح ریشهٔ خرابی نیست. در این آموزش هیچ‌یک از این تغییرها انجام نشده است.
۶. نتیجه را دوباره بررسی و مستند کنید
بعد از اصلاحِ مشخص توسط مسئول مربوط، همان نام و همان نوع رکورد را از DNSهای قبلی دوباره بپرسید و زمان را ثبت کنید. هدف، دریافت پاسخ مورد انتظار بدون SERVFAIL است؛ NOERROR بدون رکورد لازم هنوز پاسخ کاربردی شما نیست. سپس بازشدن سایت و سرویس ایمیل را جدا بررسی کنید؛ پاسخ صحیح DNS سلامت همهٔ سرویس‌ها را تضمین نمی‌کند.
برای پیگیری، این الگو را با اطلاعات عمومی پُر کنید:
- نام دقیق عمومی و نوع رکورد؛ مثلاً A برای دامنهٔ اصلی.
- زمان و منطقهٔ زمانی، DNS پاسخ‌دهنده و متن کامل خطا.
- Comment یا EDE در صورت وجود، همراه نتیجهٔ resolver دوم.
- آخرین تغییر DNS یا ثبت‌کننده و زمان آن؛ بدون رمز، توکن یا تصویر حساب خصوصی.
- نتیجهٔ آزمون پس از اصلاح؛ چه چیزی عوض شد و چه خطایی هنوز باقی است؟
اگر مسئله فقط SERVFAIL نیست و دامنهٔ تازه‌ثبت‌شده اصلاً باز نمی‌شود، مسیر کلی بررسی دامنهٔ ثبت‌شده و سایت بازنشدنی کمک می‌کند DNS را از هاست و گواهی جدا کنید.
۷. پرسش‌های رایج
با دیدن SERVFAIL باید ۲۴ ساعت صبر کنم؟
زمان ثابت، راه‌حل عمومی نیست. ابتدا علت را مشخص کنید؛ کلید یا واگذاری ناسازگار صرفاً با صبر اصلاح نمی‌شود. پس از اصلاح هم نتیجه را با توجه به کش و زمان تغییر دوباره بسنجید.
پاک‌کردن کش ویندوز این خطا را رفع می‌کند؟
کش محلی، امضای خراب یا نیم‌سرور از دسترس خارج‌شده را تعمیر نمی‌کند. وقتی ابزار عمومی هم برای همان نام SERVFAIL دارد، ابتدا مسیر مرجع و جزئیات خطا را بررسی کنید.
آیا AD=false یعنی DNSSEC خراب است؟
خیر. این فیلد به‌تنهایی حکم خرابی نیست؛ نام بدون امضای معتبرِ قابل اعتبارسنجی هم ممکن است پاسخ معمولی با AD=false داشته باشد. status، نوع پاسخ و جزئیات تشخیصی را کنار هم بخوانید؛ تعریف فیلدها در مستند JSON گوگل آمده است.
