پاسخ DNS امضا دارد، ولی این امضا را چه کسی تأیید کرده است؟ امشب zone کتابخانه را امضا می‌کنیم و می‌بینیم فرق «رکورد امضا موجود است» با «زنجیرهٔ اعتماد معتبر است» چقدر مهم است.

این جلسه بخشی از دورهٔ لینوکس ۳۰۳ در ۴۰ شب است.

محیط تمرین: Ubuntu 24.04 و BIND 9.18؛ پوشه و zone شب دهم؛ ساعت سیستم درست؛ بدون دامنهٔ عمومی.

جایگاه در دوره: هدف‌های 331.4 آزمون 303-300.

کلیدها و رکوردهای همراه#

DNSKEY کلید عمومی را منتشر می‌کند؛ RRSIG امضای مجموعهٔ رکوردهاست. DS در zone والد، کلید فرزند را به زنجیرهٔ اعتماد پیوند می‌دهد. در طرح دارای دو نقش، KSK برای امضای مجموعهٔ کلیدها و ZSK برای دادهٔ zone استفاده می‌شود؛ همهٔ طراحی‌ها الزاماً دو کلید مستقل ندارند.

NSEC و NSEC3 برای اثبات معتبرِ نبودن نام یا نوع رکورد هستند. NSEC3PARAM پارامترهای NSEC3 را بیان می‌کند. آن‌ها رمزنگاری پرس‌وجو نیستند و نام‌های zone را الزاماً از تحلیل پنهان نمی‌کنند.

امضای دستی برای دیدن اجزا#

فرایند named شب دهم را متوقف کن. در همان پوشه:

cd /var/lib/bind/lpic303
umask 077
zsk=$(dnssec-keygen -a ECDSAP256SHA256 -n ZONE example.test)
ksk=$(dnssec-keygen -a ECDSAP256SHA256 -f KSK -n ZONE example.test)
dnssec-signzone -n 1 -S -o example.test db.example.test
dnssec-verify -o example.test db.example.test.signed
dnssec-dsfromkey "$ksk.key"
dnssec-settime -p all "$zsk"

فایل .private راز است؛ .key عمومی است. -S کلیدهای مناسب را برای امضا پیدا می‌کند؛ -n 1 تعداد workerهای این آزمایش کوچک را محدود می‌کند. خروجی verify باید امضاها را تأیید کند. DS تولیدشده را ثبت کن؛ برای .test آن را در DNS عمومی منتشر نمی‌کنیم.

در named.conf فقط مقدار file مربوط به zone را به db.example.test.signed تغییر بده، named-checkconf را اجرا و فرایند foreground را دوباره آغاز کن. سپس:

dig @127.0.0.1 -p 5353 library.example.test A +dnssec
dig @127.0.0.1 -p 5353 example.test DNSKEY +dnssec

RRSIG باید دیده شود. این سرور authoritative است؛ از آن انتظار اثبات validation برای کلاینت نداریم. وجود امضا یا حتی flagهای دریافتی، بدون اعتماد به resolver، پایان آزمایش نیست.

آزمایش validation محلی#

برای delv یک فایل trust-anchor.conf بساز. مقدار کلید عمومی را از فایل KSK همین آزمایش بردار؛ متن زیر قالب است و رشتهٔ داخل کوتیشن باید با دادهٔ واقعی DNSKEY جایگزین شود:

trust-anchors {
    "example.test." static-key 257 3 13 "BASE64_PUBLIC_KEY_FROM_KSK";
};

delv -a trust-anchor.conf +root=example.test \
  @127.0.0.1 -p 5353 library.example.test A

گزینهٔ +root مرز اعتماد این آزمایش را example.test تعیین می‌کند؛ بدون آن، delv به‌طور پیش‌فرض anchor ریشهٔ . را می‌خواهد. هدف، نتیجهٔ معتبر زیر trust anchor آزمایشگاه است. یک کپی از zone امضاشده را دست‌کاری کن، سرور را روی آن کپی راه بینداز و دوباره بررسی کن: تغییر داده بدون امضای تازه باید شکست اعتبارسنجی ایجاد کند. فایل اصلی را حفظ کن تا برگشت آسان باشد.

چرخش کلید مسابقهٔ حذف فایل نیست#

در rollover باید زمان cache، انتشار کلید جدید، امضای مناسب و به‌روزرسانی DS والد هماهنگ شوند. حذف زودهنگام کلید یا DS، zone سالم را bogus می‌کند. برای بهره‌برداری روزمره، dnssec-policy در BIND چرخهٔ کلید را مدیریت می‌کند؛ امضای دستی این درس و policy خودکار را بدون طراحی با هم مخلوط نکن.

تمرین: اگر dig +dnssec امضا نشان دهد ولی delv شکست بخورد، ساعت، trust anchor، زمان اعتبار امضا و تطابق DS را بررسی کن. راهنما: پاسخ unsigned زیر یک delegation امن می‌تواند مسئله باشد، ولی unsigned بودن همهٔ zoneها ذاتاً خطا نیست.

منابع: راهنمای DNSSEC در BIND و ابزارهای DNSSEC و delv .