WIUNIX ACADEMY
عیب‌یابی DNSSEC و خطای SERVFAIL
صفحهٔ 2 از 3؛ مراحل قبلی و پیش‌نیازها را پیش از ادامه مرور کن.
آموزش متناسب با محیط تو
کجا اجرا می‌کنی؟
سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.
آموزش متناسب با مقادیر تو
تنظیمات این آموزش
مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.
آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.
تنظیم مقادیر برای محیط من5 مقدار قابل‌تغییر
قدم بعدی
DS فرزند را از والد بپرسید
با recursion غیرفعال از سرور اصلی زون والد پرس‌وجو کنید. DS باید در والد باشد؛ قرار دادن نمونهٔ آن در فرزند، ثبت درست آن در والد را جبران نمی‌کند. key tag، الگوریتم، نوع digest، مقدار digest و TTL را ثبت کنید.
نبود DS همیشه خرابی نیست؛ ممکن است delegation عمداً بدون زنجیرهٔ امن باشد. ابتدا سیاست مورد انتظار زون را روشن کنید.
ترمینال همان میزبان معرفی‌شده در توضیح گام
dig @203.0.113.54 'example.com' DS +dnssec +norecurse +time=3 +tries=1پاسخ authoritative والد و مجموعهٔ واقعی DS یا نبود آن ثبت شده؛ هیچ دادهٔ ثبت‌کننده تغییر نکرده است.
قدم بعدی
کلید و امضای فعلی زون را مقایسه کنید
از سرور اصلی خود زون DNSKEY و SOA همراه امضا بگیرید و بیت AA را بررسی کنید. اگر نودها اختلاف دارند، هر سرور اصلی فعلی زون باید جدا بررسی شود.
یکسان‌بودن key tag فقط برای پیدا کردن کلید کمک می‌کند؛ اثبات رمزنگاری نیست. digest موجود در DS و زنجیرهٔ امضا باید واقعاً اعتبارسنجی شوند. از روی فایل کلید نامعلوم یا tag مشابه، DS تازه منتشر نکنید.
ترمینال همان میزبان معرفی‌شده در توضیح گام
dig @203.0.113.53 'example.com' DNSKEY +dnssec +norecurse +time=3 +tries=1
dig @203.0.113.53 'example.com' SOA +dnssec +norecurse +time=3 +tries=1
dig @203.0.113.53 'www.example.com' A +dnssec +norecurse +time=3 +tries=1کلیدها، زمان امضا و هماهنگی authoritative را می‌توان با DS والد و trace اعتبارسنجی مقایسه کرد.
قدم بعدی
پاسخ بزرگ را روی TCP هم بررسی کنید
اگر UDP جواب نمی‌دهد یا پاسخ truncate می‌شود، همان DNSKEY را از همان سرور اصلی زون روی TCP بخواهید. پاسخ‌های DNSSEC می‌توانند بزرگ‌تر باشند؛ مشکل TCP53، MTU یا fragmentation ممکن است شبیه شکست اعتبارسنجی دیده شود.
موفقیت TCP صحت امضا را ثابت نمی‌کند. از طرف دیگر، خطای مشخص رمزنگاری با زیادکردن کورکورانهٔ buffer UDP حل نمی‌شود. برای ابزار کلاینت، لازم نیست سرویس DNS عمومی روی میزبان باز کنید.
ترمینال همان میزبان معرفی‌شده در توضیح گام
dig @203.0.113.53 'example.com' DNSKEY +dnssec +norecurse +tcp +time=3 +tries=1رفتار UDP و TCP از نتیجهٔ اعتبارسنجی جدا و به مسئول درست شبکه یا DNS ارجاع شده است.
اولین حلقهٔ خراب را به مسئولش وصل کنید
DS قدیمی پس از rollover به هماهنگی والد و ثبت‌کننده نیاز دارد. RRSIG منقضی یا زودهنگام به signer و ساعت مربوط است. نبود DNSKEY یا اختلاف نودها به انتشار سرور اصلی زون برمی‌گردد.
اگر زون‌های نامرتبط فقط روی یک resolver مشکل دارند، ساعت و trust anchor همان resolver را بررسی کنید. خاموش‌کردن عمومی validation یا حذف عجولانهٔ DS، راه‌حل این آموزش نیست.
تغییر کلید را با زمان انتشار و cache هماهنگ کنید
پیش از تغییر، DS، DNSKEY، RRSIG و TTLهای فعلی را ثبت کنید و روند پشتیبانی‌شدهٔ signer و ارائه‌دهنده را دنبال کنید. دادهٔ لازم باید پیش از وابسته‌شدن والد منتشر شود و هم‌پوشانی کلید و امضای معتبر به مدت لازم حفظ شود.
بازگشت امن یعنی بازسازی یک زنجیرهٔ هنوز معتبر؛ برگرداندن فقط یک طرف ممکن است خرابی را ادامه دهد. یک زمان انتظار ثابت جای TTL و سیاست واقعی signer را نمی‌گیرد.
قدم بعدی
اصلاح زنجیره را از cache باقی‌مانده جدا کنید
پس از رفع مشکل والد و سرور اصلی زون، درخواست عادی را از همان resolver و یک resolver معتبر دیگر که اجازهٔ استفاده از آن را دارید مقایسه کنید. TTL و cache شکست می‌توانند همگرایی را عقب بیندازند.
اگر resolver BIND زیر اختیار شماست، هر عملیات محدود cache باید از runbook خودش بیاید. این آموزش cache مشترک را flush یا resolver را restart نمی‌کند؛ چنین کاری دادهٔ خراب سرور اصلی زون را اصلاح نمی‌کند و به‌تنهایی تأیید اعتبار هم نیست.
ترمینال همان میزبان معرفی‌شده در توضیح گام
dig @127.0.0.1 'www.example.com' A +dnssec +time=3 +tries=1
delv @127.0.0.1 'www.example.com' A +vtraceحل عادی نام و اعتبارسنجی مستقل، بدون تکیه بر CD موفق شده‌اند؛ cache شکست باقی‌مانده در گزارش ثبت می‌شود.