مهاجرت نام‌سرورها ممکن است در همهٔ پنل‌های مدیریتی موفق به نظر برسد، اما وب‌سایت همچنان در دسترس نباشد. دامنه فعال است، نام‌سرورهای مقتدر جدید آدرس مورد انتظار را برمی‌گردانند و وب‌سرور هم تغییری نکرده است. بااین‌حال، حل‌کننده‌های DNS که اعتبارسنجی انجام می‌دهند، خطای SERVFAIL برمی‌گردانند. حلقهٔ گم‌شده اغلب یک تفویض DNSSEC است که هنوز به کلید امضای ارائه‌دهندهٔ قبلی DNS اعتماد می‌کند.
در رخدادی که مبنای این بررسی بود، پرس‌وجوهای معمولی شکست می‌خوردند، اما همان پرس‌وجوها با دور زدن اعتبارسنجی DNSSEC موفق می‌شدند. ناحیهٔ والد هنوز رکورد DS قدیمی را منتشر می‌کرد، درحالی‌که ناحیهٔ مقتدر جدید در ابتدا امضا نشده بود. انتشار کلید منطبق و امضای ناحیهٔ جدید باعث شد حل‌کننده‌های آزمایش‌شده دوباره پاسخ‌های معتبر برگردانند. نکتهٔ اصلی این نیست که باید DNSSEC را خاموش کرد؛ بلکه تغییر نام‌سرورها و انتقال زنجیرهٔ اعتماد DNSSEC دو عملیات جداگانه‌اند.
چرا با وجود درست بودن رکوردهای A باز هم SERVFAIL رخ می‌دهد؟
DNS به دو پرسش متفاوت پاسخ می‌دهد. رکورد A مشخص می‌کند کدام آدرس IPv4 به یک نام تعلق دارد. DNSSEC به حل‌کنندهٔ اعتبارسنج می‌گوید آیا می‌توان به آن پاسخ اعتماد کرد یا نه. درست بودن آدرس به‌خودی‌خود به معنای معتبر بودن زنجیرهٔ اعتماد DNSSEC نیست.
در دامنه‌ای که امضا شده است، زنجیرهٔ اعتماد از ناحیهٔ والدِ مورد اعتماد شروع می‌شود، از رکورد DS (مخفف Delegation Signer) می‌گذرد و به DNSKEY در ناحیهٔ فرزند می‌رسد. ناحیهٔ فرزند امضاهایی از نوع RRSIG را برای داده‌های DNS خود منتشر می‌کند. رکورد DS شامل یک چکیدهٔ رمزنگاری‌شده برای شناسایی DNSKEY مجاز است؛ نه رکورد A است، نه کپی کلید خصوصی و نه تنظیمی در ویرایشگر معمول فایل ناحیه.
پس از تغییر نام‌سرورهای مقتدر، ناحیهٔ والد ممکن است همچنان رکورد DS مربوط به امضاکنندهٔ قبلی را منتشر کند. اگر ناحیهٔ جدید DNSKEY منطبق و امضاهای لازم را نداشته باشد، حل‌کنندهٔ اعتبارسنج نمی‌تواند زنجیرهٔ اعتماد را کامل کند. در این حالت معمولاً پاسخ را از نظر DNSSEC نامعتبر تشخیص می‌دهد و به‌جای ارائهٔ آدرسی که تأیید نشده، SERVFAIL برمی‌گرداند.
این وضعیت با قطعی HTTP متفاوت است؛ ممکن است درخواست اصلاً به وب‌سرور نرسد. همچنین با منقضی شدن گواهی TLS فرق دارد: DNSSEC داده‌های DNS را اعتبارسنجی می‌کند، اما HTTPS از اتصال بعدی میان مرورگر و سرور محافظت می‌کند.
آزمایشی که مشکل DNSSEC را از نبود رکورد جدا می‌کند
روش تشخیصی گویاتر این است که نام یکسانی را دو بار از همان حل‌کننده بپرسید. ابتدا پرس‌وجوی معمولی انجام دهید و علاوه بر پاسخ، وضعیت آن را بررسی کنید:
dig example.com A +noall +comments +answerسپس همان پرس‌وجو را با فعال کردن بیت غیرفعال‌سازی بررسی DNSSEC (CD) تکرار کنید:
dig example.com A +cdflag +noall +comments +answerدر خرابی مشاهده‌شده، پرس‌وجوی معمولی SERVFAIL می‌داد، اما پرس‌وجو با CD رکورد A مورد انتظار را برمی‌گرداند. این تفاوت به‌شدت نشان می‌داد که مشکل به اعتبارسنجی DNSSEC مربوط است، نه نبود رکورد DNS یا پاسخ ندادن برنامه. گزینهٔ +cdflag از حل‌کنندهٔ بازگشتیِ پشتیبان این قابلیت می‌خواهد برای آن درخواست اعتبارسنجی معمول DNSSEC را انجام ندهد. این گزینه ابزاری برای عیب‌یابی است، نه راه‌حلی در مرورگر یا روشی برای غیرفعال کردن DNSSEC برای بازدیدکنندگان.
از خروجی خالی +short بیش‌ازحد نتیجه‌گیری نکنید. هم نبود پاسخ و هم وضعیت SERVFAIL ممکن است در این قالب به شکل خروجی خالی دیده شوند. هنگام عیب‌یابی، +comments را نگه دارید تا status: SERVFAIL و status: NOERROR قابل مشاهده باشند.
مقایسهٔ CD به‌تنهایی مشخص نمی‌کند کدام بخش DNSSEC مشکل دارد؛ فقط جهت بررسی بعدی را نشان می‌دهد. حل‌کننده ممکن است با خطای موقت در بالادست هم روبه‌رو شده باشد. بنابراین در صورت لزوم آزمایش را تکرار کنید و تفویض در ناحیهٔ والد را بررسی کنید.
رکورد DS ناحیهٔ والد را بررسی کنید، نه فقط ویرایشگر DNS را
رکوردهای DS دامنه را جست‌وجو کنید:
dig example.com DS +noall +comments +answerبرای دیدن مسیر تفویض با جزئیات بیشتر، سلسله‌مراتب DNS را مستقیم دنبال کنید:
dig +trace example.com DSنام‌سرور مقتدرِ دقیق ناحیهٔ والد به دامنهٔ سطح‌بالا بستگی دارد. آنچه اهمیت دارد مجموعهٔ رکوردهای DS منتشرشده در ناحیهٔ والد است، نه صرفاً خلاصه‌ای که داشبورد میزبانی DNS نشان می‌دهد. انتقال دامنه به ثبت‌کنندهٔ دیگر ممکن است بدون تغییر نام‌سرورها انجام شود و تغییر نام‌سرورها هم لزوماً به انتقال ثبت‌کننده نیاز ندارد؛ در هر دو حالت، DS ناحیهٔ والد باید با ناحیهٔ مقتدر فعال سازگار بماند.
رکورد DS چهار فیلد مهم دارد: شناسهٔ کلید (key tag)، الگوریتم، نوع چکیده (digest type) و خود چکیده. شناسهٔ کلید برچسبی مناسب برای عیب‌یابی است، اما به‌تنهایی ثابت نمی‌کند که DNSKEY مطابقت دارد. اطلاعات چکیده و الگوریتم نیز باید با کلیدی که واقعاً از ناحیهٔ مقتدر ارائه می‌شود، منطبق باشند.
وضعیت تعیین‌کنندهٔ این رخداد ساده بود: ناحیهٔ والد همچنان اطلاعات اعتماد DNSSEC قبلی را منتشر می‌کرد، اما ناحیهٔ مقتدر جایگزین اعلام می‌کرد که امضای آن غیرفعال است. رکوردهای A وجود داشتند و با دور زدن اعتبارسنجی قابل دریافت بودند. تغییر پیکربندی برنامه یا ویرایش مکرر همان رکورد A نمی‌توانست این ناسازگاری را برطرف کند.
دو راه برای بازیابی تفویض خراب DNSSEC
دو راهکار معتبر برای بازیابی وجود دارد. هر دو ناسازگاری زنجیرهٔ اعتماد را برطرف می‌کنند، اما پیامدهای عملیاتی متفاوتی دارند. آگاهانه یکی را انتخاب کنید و بی‌برنامه بین آن‌ها جابه‌جا نشوید.
راهکار اول: حذف DS قدیمی و اجرای موقت ناحیه بدون امضا
از ثبت‌کنندهٔ فعلی دامنه بخواهید، یا از رابط مدیریت DNSSEC مورد پشتیبانی آن استفاده کنید، تا رکورد DS منسوخ را از ناحیهٔ والد حذف کند. وقتی ناحیهٔ والد دیگر تفویض امنی را اعلام نکند، حل‌کننده‌های اعتبارسنج می‌توانند ناحیهٔ فرزندِ بدون امضا را به‌جای «نامعتبر»، «فاقد حفاظت DNSSEC» در نظر بگیرند. DNS همچنان کار می‌کند، اما احراز اصالت DNSSEC برای آن دامنه موقتاً وجود نخواهد داشت.
این روش اغلب در شرایط اضطراری ساده‌تر است، مشروط بر اینکه راه مطمئنی برای تغییر مجموعهٔ رکوردهای DS ناحیهٔ والد وجود داشته باشد. پیکربندی امضای فعلی را تا زمانی که DS قدیمی از حافظهٔ پنهان حل‌کننده‌های بازگشتی منقضی شود، ثابت نگه دارید. حذف DS از پنل مدیریت به‌تنهایی مدرک کافی نیست؛ رکورد ناحیهٔ والد را از بیرون بررسی کنید و TTL آن را در نظر بگیرید. HTTPS مستقل از تنظیم DNSSEC باقی می‌ماند. این گذار موقت به حالت بدون امضا در RFC 8078 نیز شرح داده شده است.
راهکار دوم: امضای ناحیهٔ جدید و انتشار DS منطبق
راه دیگر این است که DNSSEC را نزد ارائه‌دهندهٔ جدید DNS مقتدر فعال کنید، کلیدهای DNSKEY را بسازید، ناحیه را امضا کنید و رکورد DS متناظر را در ناحیهٔ والد منتشر کنید. سپس حل‌کنندهٔ اعتبارسنج می‌تواند مسیر اعتمادی تا DNSKEY جدید بسازد و رکورد A را اعتبارسنجی کند.
در رخداد مورد بحث، عملاً همین مسیر بازیابی مشاهده شد. رابط مدیریت DNS گزارش داد که کلیدها را ساخته، ناحیه را امضا کرده و DS جدید را منتشر کرده است. پرس‌وجوی بعدی از ناحیهٔ والد نشان داد رکورد DS جدید در کنار رکورد قبلی قرار دارد. پرس‌وجوهای بازگشتیِ دارای اعتبارسنجی، دوباره رکورد A مورد انتظار را برگرداندند؛ آزمایش دیگری نیز بعداً NOERROR را همراه با پرچم ad نشان داد، به این معنی که آن حل‌کننده داده‌ها را احرازشده می‌دانست.
ترتیب انجام کار مهم است: انتشار DS فقط زمانی مفید است که DNSKEY منطبق و امضاهای معتبر از قبل در سرویس DNS مقتدر در دسترس باشند. عبارت «منتشر شد» در پنل مدیریت جای بررسی مستقل را نمی‌گیرد. داده‌های DS، DNSKEY، RRSIG و NS که در حافظهٔ پنهان مانده‌اند، ممکن است باعث شوند حل‌کننده‌های مختلف در زمان‌های متفاوتی به وضعیت عادی برگردند.
چرا وجود دو رکورد DS لزوماً باعث ادامهٔ قطعی نشد؟
یکی از نتایج غافلگیرکننده این بود که ناحیهٔ والد موقتاً هم یک DS منسوخ و هم یک DS جدید و معتبر داشت، اما اعتبارسنجی DNSSEC موفق بود. این موضوع تناقضی ندارد. مجموعهٔ رکوردهای DS می‌تواند چند رکورد داشته باشد؛ چیزی که هنگام تعویض کلیدها هم رایج است. اعتبارسنج لازم نیست تمام رکوردهای DS به کلیدی اشاره کنند که در آن لحظه قابل استفاده است؛ وجود یک مسیر معتبر احراز اصالت از طریق یک DS مناسب به DNSKEY و امضاهای معتبر کافی است. RFC 6840 روشن می‌کند که اعتبارسنج‌ها باید یک مسیر معتبر را بپذیرند.
البته این به معنای مطلوب بودن نگه‌داشتن همیشگی کلیدهای قدیمی نیست. DS منسوخ ابهام عملیاتی را بیشتر می‌کند و پس از تأیید زنجیرهٔ جدید باید در نهایت پاک‌سازی شود. اما حذف آن یک کار نگه‌داری است، نه بهانه‌ای برای بازنشانی پرخطر DNSSEC وقتی پرس‌وجوهای اعتبارسنجی‌شده هم‌اکنون موفق هستند.
اینجا یک دام به‌خصوص خطرناک در پنل‌های مدیریت وجود دارد: گزینه‌ای با عنوان «لغو اضطراری انتشار DS» ممکن است به معنای حذف همهٔ رکوردهای DS، از جمله رکورد جدید و سالم، باشد. به همین ترتیب، غیرفعال کردن امضای ناحیه وقتی DS هنوز منتشر می‌شود می‌تواند بلافاصله قطعی را دوباره ایجاد کند. هیچ‌یک از این اقدامات معادل حذف یک رکورد DS منسوخِ مشخص نیست. اگر رابط امکان حذف انتخابی یک رکورد را نمی‌دهد، به‌جای بازنشانی کلی از تغییر گزینشی مورد پشتیبانی ثبت‌کننده استفاده کنید.
چگونه نام‌سرورهای مقتدر را با اطمینان تغییر دهیم؟
ایمن‌ترین ترتیب به این بستگی دارد که آیا ارائه‌دهندگان قدیم و جدید DNS می‌توانند کلیدها را با هم هماهنگ کنند یا نه. برای مهاجرت معمولی که یک دورهٔ موقت بدون امضا دارد، ترتیب زیر از ناسازگاری مشاهده‌شده در این رخداد جلوگیری می‌کند:
- ابتدا ناحیهٔ مقصد را آماده کنید. رکوردهای لازم A، AAAA، CNAME، MX، TXT و سایر رکوردهای مرتبط را کپی کنید. پیش از تغییر تفویض، نام‌سرورهای مقتدر جدید را مستقیم آزمایش کنید.
- DNSSEC را در ناحیهٔ والد بررسی کنید. ببینید رکورد DS وجود دارد یا نه و مشخص کنید چه کسی می‌تواند آن را به‌روزرسانی کند. حتی اگر هرگز خودتان DNSSEC را فعال نکرده‌اید این کار را انجام دهید؛ بعضی سرویس‌های DNS امضاکردن را خودکار انجام می‌دهند.
- درحالی‌که ناحیهٔ امضاشدهٔ قدیمی هنوز فعال است، DS قدیمی را حذف کنید. تغییر را در ناحیهٔ والدِ مقتدر تأیید کنید و سپس به‌اندازه‌ای صبر کنید که DSهای قبلاً ذخیره‌شده در حافظهٔ پنهان منقضی شوند. این مدت را TTLهای مشاهده‌شده تعیین می‌کنند، نه یک تعداد دقیقهٔ ثابت برای همهٔ شرایط.
- تفویض نام‌سرورها را تغییر دهید. سرویس مقتدر قبلی را تا زمانی که تفویض‌های NS ذخیره‌شده ممکن است به آن اشاره کنند، در دسترس نگه دارید. TTL رکوردهای NS والد را در نظر بگیرید و بررسی کنید حل‌کننده‌های مختلف واقعاً از کدام سرورها استفاده می‌کنند.
- تصمیم بگیرید DNSSEC را دوباره فعال کنید یا نه. اگر سرویس جدید باید بدون امضا بماند، DS منتشر نکنید. اگر قرار است امضا شود، پیش از انتشار DS منطبق مطمئن شوید DNSKEY و امضاهای جدید به‌درستی ارائه می‌شوند. این کار را با در نظر گرفتن کش‌هایی که هنوز نام‌سرورهای قدیمی را دارند هماهنگ کنید تا ناسازگاری تازه‌ای در اعتبارسنجی ایجاد نشود.
- به‌طور مستقل اعتبارسنجی کنید. DS ناحیهٔ والد، DNSKEY سرویس مقتدر، پاسخ پرس‌وجوی بازگشتی معمولی و نتیجهٔ احراز اصالت در حل‌کننده‌های اعتبارسنج را بررسی کنید.
اگر حفظ بی‌وقفهٔ حفاظت DNSSEC ضروری است، تغییر هماهنگ کلیدها یا انتقال با چند امضاکننده، به‌جای دورهٔ بدون امضا، ترجیح دارد. این کار مستلزم آن است که هر دو ارائه‌دهنده از چیدمان لازم برای کلیدها و امضاها پشتیبانی کنند؛ کپی کردن صرفِ چکیدهٔ DS قدیمی در ارائه‌دهندهٔ جدید به‌معنای تغییر کلید نیست.
چک‌لیست کوتاه پس از مهاجرت
پس از هر تغییر مرتبط با DNSSEC، هم رکوردهای DNS و هم شواهد پذیرش آن‌ها توسط حل‌کننده‌ها را بررسی کنید:
dig example.com DS +noall +comments +answer
dig example.com DNSKEY +dnssec +noall +comments +answer
dig example.com A +dnssec +noall +comments +answer
dig example.com A +cdflag +noall +comments +answerبرای بررسی پاسخ احرازشده از یک حل‌کنندهٔ بازگشتیِ اعتبارسنج استفاده کنید. در پاسخ آن، NOERROR به‌همراه رکورد A مورد انتظار یعنی نام با موفقیت حل شده است؛ وجود پرچم ad نیز نشان می‌دهد آن حل‌کننده طبق سیاست DNSSEC خود اصالت پاسخ را تأیید کرده است. نبود پرچم ad به‌تنهایی ثابت نمی‌کند مشکلی وجود دارد، چون قابلیت‌ها، سیاست‌ها و پرچم‌های پرس‌وجو در حل‌کننده‌ها یکسان نیستند. اگر هنگام قطعی، پرس‌وجوهای DNSKEY از طریق حل‌کنندهٔ اعتبارسنج شکست می‌خورند، بررسی مستقیم سرویس DNS مقتدر فعال را نیز به مراحل عیب‌یابی اضافه کنید.
با یک پاسخ موفق از یک حل‌کننده بررسی را تمام نکنید. کش‌های مختلف ممکن است موقتاً تفویض‌ها و کلیدهای متفاوتی را نگه دارند. همچنین هر درخواست پشتیبانیِ باز را به‌روزرسانی کنید: دستور قبلی برای حذف تمام رکوردهای DS پس از انتشار یک DS جدید و سالم می‌تواند خطرناک شود. در پیگیری باید صریحاً بر حفظ کلید فعال تأکید کنید و در صورت نیاز حذف فقط رکورد منسوخ را بخواهید.
علت خرابی، آدرس اشتباه وب‌سرور نبود. مشکل از اینجا ناشی شد که محل ارائهٔ پاسخ‌های DNS تغییر کرد، بی‌آنکه اطلاعات اعتمادی که به حل‌کننده‌ها می‌گفت کدام پاسخ‌ها قابل‌اعتمادند با آن هماهنگ شود. بنابراین پرسش عملی پیش از هر تغییر نام‌سرور این است: ناحیهٔ والد چه رکوردهای DS منتشر می‌کند و آیا DNSKEY و امضاهای مقصد جدید با آن‌ها سازگارند؟