WIUNIX ACADEMY
عیب‌یابی DNSSEC و خطای SERVFAIL
بدون خاموش‌کردن اعتبارسنجی، مشخص کنید خرابی از DS والد، DNSKEY، امضا، resolver یا انتقال پاسخ DNS است.
محیطت را انتخاب کنآموزش متناسب با محیط تو
کجا اجرا می‌کنی؟
سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.
آموزش متناسب با مقادیر تو
تنظیمات این آموزش
مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.
آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.
تنظیم مقادیر برای محیط من5 مقدار قابل‌تغییر
از اینجا شروع کن
در پایان چه چیزی خواهی داشت؟
اولین حلقهٔ خراب اعتماد یا انتقال را پیدا کنید و بعد از اصلاح، پاسخ عادی و معتبر بگیرید؛ پاسخ بدون اعتبارسنجی را بازیابی محسوب نکنید.
سیستم‌عامل‌ها و نسخه‌های پوشش‌داده‌شده
مسیرهای این آموزش با مستندات رسمی ابزار و توزیع انتخابی بررسی شده‌اند. فرمان‌های آموزشی روی سرویس شما اجرا نشده‌اند؛ نتیجهٔ محیط خودتان را در هر گام بررسی کنید.
قبل از شروع
- ابزارهای dig و delv روی کلاینت لینوکس موجودند و مجاز به بررسی زون و resolver انتخابی هستید.
- نام مشکل‌دار، زون شامل آن و authoritative واقعی زون و والدش مشخص‌اند؛ IPهای نمونه باید جایگزین شوند.
- برای تغییر کلید یا DS، روند بومی signer و ثبت‌کننده و زمان‌های TTL لازم است؛ این آموزش آن داده‌ها را تغییر نمی‌دهد.
هر SERVFAIL از DNSSEC نیست
سرور پاسخ‌گوی اصلی زون (authoritative) رکوردهای همان زون را از دادهٔ تحت اختیارش پاسخ می‌دهد. نرسیدن به سرور اصلی زون، delegation خراب، مشکل انتقال و شکست اعتبارسنجی همگی می‌توانند SERVFAIL بدهند. بیت AD فقط وقتی معنا دارد که resolver و مسیر دریافت پاسخ قابل اعتماد باشند. درخواست رکوردهای DNSSEC با DO هم خودش اعتبارسنجی انجام نمی‌دهد.
این راهنما یک زون امضاشدهٔ موجود را بررسی می‌کند. DS ثبت‌کننده تغییر نمی‌کند و validator مشترک خاموش نمی‌شود. هدف این است که لایهٔ خراب را بشناسید، نه اینکه خطا را پنهان کنید.
قدم بعدی
پیش از شروع، ابزار و تفاوت‌های توزیع را بررسی کنید
این گام روی همان میزبان آزمایش یا عیب‌یابی اجرا می‌شود. نام و نسخهٔ سیستم‌عامل و بسته‌های فهرست‌شده را با محیط انتخابی تطبیق دهید. اگر ابزاری نصب نیست، ابتدا از مخزن رسمی فعال و روند مجاز مدیریت بستهٔ خود آن را نصب کنید؛ این آموزش سرور موجود را دوباره نصب یا مخزنش را عوض نمی‌کند.
در Debian 13 و 12 نام بسته‌ها در پنل آمده است. Debian 12 در دورهٔ LTS قرار دارد و پوشش پشتیبانی به معماری و بسته بستگی دارد؛ صرف نصب‌بودن یک بسته تضمین پشتیبانی آن نیست.
این میزبان فقط ابزار کلاینت لازم دارد؛ bind9-dnsutils در Debian/Ubuntu و bind-utils در RPM باید dig و delv را فراهم کنند. وجود هر دو را از پنل تأیید کنید. سرویس named یا bind9 راه‌اندازی نمی‌شود و نیازی به بازکردن ورودی پورت 53 در firewalld یا UFW نیست. شبکه باید درخواست و پاسخ خروجی DNS را روی UDP و TCP مجاز کند؛ اگر مسیر خروجی محدود است، با مسئول شبکه هماهنگ کنید.
ترمینال میزبان مجاز معرفی‌شده در همین بخش
cat /etc/os-release
dpkg-query -W bind9-dnsutils
command -v dig delvبسته و ابزار لازم شناسایی شده است؛ خطا یا نبود ابزار را پیش از ادامه رفع کنید.
قدم بعدی
resolver و پرس‌وجوی مشخص را ثبت کنید
از یک کلاینت مجاز، مستقیماً 127.0.0.1 را دربارهٔ www.example.com بپرسید. برنامهٔ دیگری ممکن است resolver متفاوتی استفاده کند؛ نتیجه‌ها را بدون تطبیق مقصد مقایسه نکنید. زمان UTC هم برای اعتبار امضا و cache خطا مهم است.
نسخهٔ dig و delv، status، flagها و متن احتمالی Extended DNS Error را نگه دارید. IPهای سرورهای اصلی زون این آموزش نمونه‌اند؛ آن‌ها را با سرور واقعی زون و والد عوض کنید.
ترمینال همان میزبان معرفی‌شده در توضیح گام
date -u +'%Y-%m-%dT%H:%M:%SZ'
dig -v
delv -v
dig @127.0.0.1 'www.example.com' A +dnssec +time=3 +tries=1مقصد، نام پرس‌وجو، نسخهٔ ابزار، زمان و پاسخ کامل همین درخواست معلوم‌اند.
قدم بعدی
همان درخواست را فقط برای تشخیص با CD مقایسه کنید
اگر درخواست عادی SERVFAIL است ولی همان درخواست با CD داده می‌دهد، بررسی اعتبارسنجی اولویت پیدا می‌کند. CD عمداً اجازهٔ دریافت دادهٔ تأییدنشده را می‌خواهد؛ این پاسخ اصالت داده را ثابت نمی‌کند.
از CD به‌عنوان تنظیم همیشگی اپلیکیشن استفاده نکنید. اگر هر دو درخواست شکست می‌خورند، مشکل انتقال یا delegation هم می‌تواند در کار باشد و باید جدا بررسی شود.
ترمینال همان میزبان معرفی‌شده در توضیح گام
dig @127.0.0.1 'www.example.com' A +dnssec +cdflag +time=3 +tries=1تفاوت درخواست عادی و CD روشن شده؛ هیچ سیاست دائمی resolver یا اپلیکیشن تغییر نکرده است.
قدم بعدی
با delv زنجیره را مستقل بررسی کنید
delv فقط به AD پاسخ upstream اعتماد نمی‌کند و از trust anchor محلی برای اعتبارسنجی استفاده می‌کند. در این بررسی، CD اجازه می‌دهد داده‌ای را که resolver رد می‌کند دریافت کنید، اما اعتبارسنجی داخلی delv همچنان انجام می‌شود.
trace را محلی نگه دارید و اولین حلقهٔ خراب را پیدا کنید. آخرین عبارت SERVFAIL علت نیست. ساعت یا trust anchor قدیمی همین کلاینت هم می‌تواند مقایسه را خراب کند.
ترمینال همان میزبان معرفی‌شده در توضیح گام
delv @127.0.0.1 'www.example.com' A +cdflag +vtracetrace یا اعتبار زنجیره را تأیید می‌کند یا مشکل مشخص کلید، امضا یا anchor را نشان می‌دهد.
قدم بعدی
ببینید مسئول پاسخ در هر مرحله کیست
مسیر delegation را بخوانید و سرور اصلی زون زون example.com را از سرور اصلی زون والد آن جدا کنید. trace ابزار کشف مسیر است و به‌تنهایی حکم اعتبار رمزنگاری نمی‌دهد.
اگر پاسخ از CNAME به زون دیگری می‌رود، خرابی ممکن است آنجا باشد. آدرس‌های واردشده در تنظیمات را با همین شواهد تطبیق دهید و همهٔ خطا را به زون شروع نسبت ندهید.
ترمینال همان میزبان معرفی‌شده در توضیح گام
dig 'www.example.com' A +trace +dnssecمسیر واگذاری و مقصد زنجیرهٔ CNAME معلوم‌اند و سرورهای اصلی زون و والد به‌درستی انتخاب شده‌اند.