قفل TLS داریم و DNSSEC هم راه افتاده؛ آیا پرس‌وجوی DNS از دید شبکه پنهان شده است؟ هنوز نه. امشب سه کنترل متفاوت را روی نقشه می‌گذاریم تا ابزار درست را برای مشکل درست انتخاب کنیم.

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

محیط تمرین: Ubuntu 24.04؛ OpenSSL، dig و zone آزمایشگاهی؛ گواهی server.crt شب پنجم.

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

سه سؤال مستقل#

CAA تعیین می‌کند کدام CAها مجاز به صدور گواهی برای دامنه‌اند؛ خط‌مشی صدور است و کلاینت وب را جایگزین نمی‌کند. DANE از رکورد TLSA برای بیان ارتباط سرویس TLS با گواهی یا کلید استفاده می‌کند؛ اعتماد آن به DNSSEC معتبر وابسته است. DNS over TLS یا DoT و DNS over HTTPS یا DoH، مسیر انتقال پرس‌وجو را رمز می‌کنند؛ resolver همچنان درخواست را می‌بیند.

به‌جای یک فهرست از مخفف‌ها، سه رخداد تصور کن: صدور ناخواستهٔ گواهی، جایگزینی گواهی سرویس و شنود نام مقصد روی مسیر. به ترتیب، سیاست CAA، سازوکار DANE در کلاینت سازگار و رمزنگاری انتقال DNS به این رخدادها مربوط‌اند.

رکوردها را از دادهٔ واقعی بساز#

در zone آموزشی، نمونهٔ CAA می‌تواند این باشد:

@ IN CAA 0 issue "letsencrypt.org"

این رکورد روی .test مجوز گرفتن گواهی عمومی ایجاد نمی‌کند؛ فقط شکل سیاست را نشان می‌دهد. برای گواهی مستقیم درس پنجم، اثر انگشت DER کامل گواهی را بساز:

cd ~/lpic303/pki
openssl x509 -in server.crt -outform DER | openssl dgst -sha256

در فایل zone، خروجی هگز واقعی را به‌جای placeholder بگذار:

_443._tcp.library IN TLSA 3 0 1 SHA256_OF_DER_CERTIFICATE

در این نمونه usage برابر ۳، selector برابر صفر و matching type برابر ۱ است: اتصال مستقیم به گواهی انتهایی با digest SHA-256. اگر selector را ۱ کنی، ورودی digest باید SubjectPublicKeyInfo باشد؛ استفاده از هش فایل PEM نتیجهٔ مشابه نمی‌دهد.

serial را افزایش بده، zone را بررسی و دوباره امضا کن. از همان سرور محلی:

dig @127.0.0.1 -p 5353 example.test CAA
dig @127.0.0.1 -p 5353 _443._tcp.library.example.test TLSA +dnssec

هدف دیدن مقادیر درست و اعتبار امضا در مسیر validation درس قبل است. curl معمولی الزاماً DANE را اعمال نمی‌کند؛ صرف وجود TLSA، رفتار تمام مرورگرها را تغییر نمی‌دهد. تغییر گواهی بدون به‌روزرسانی TLSA می‌تواند کلاینت DANE را قطع کند.

DoT، DoH و نام‌های محلی#

DoT معمولاً روی TCP/853 و DoH روی HTTPS کار می‌کند. باید resolver، اعتماد TLS و سیاست شبکه مشخص باشند؛ DoHِ یک برنامه ممکن است DNS مرکزی سازمان را دور بزند. mDNS برای کشف نام‌های محلی در multicast است؛ از آن زنجیرهٔ اعتماد جهانی DNSSEC انتظار نداشته باش.

تمرین تصمیم‌گیری#

برای کتابخانه یک جدول «چه کسی درخواست را می‌بیند؟» رسم کن: اتصال عادی DNS، DoT تا resolver خصوصی و DoH تا resolver بیرونی. آیا رمزنگاری مسیر، resolver بدخواه را درستکار می‌کند؟ پاسخ: نه، مدل اعتماد هنوز باید تعریف شود.

منابع استاندارد: CAA؛ RFC 8659 ، DANE؛ RFC 6698 ، DoT؛ RFC 7858 و DoH؛ RFC 8484 .