توسعه دهندگان سرور BIND DNS از اضافه شدن پشتیبانی سرور برای DNS از طریق HTTPS (DoH, DNS over HTTPS) و DNS over TLS (DoT, DNS over TLS) و همچنین مکانیزم XFR-over-TLS برای ایمن شدن خبر دادند. انتقال محتویات مناطق DNS بین سرورها. DoH برای آزمایش در نسخه 9.17 در دسترس است و پشتیبانی DoT از نسخه 9.17.10 وجود دارد. پس از تثبیت، پشتیبانی DoT و DoH به شاخه پایدار 9.17.7 بکپورت می شود.
اجرای پروتکل HTTP/2 مورد استفاده در DoH بر اساس استفاده از کتابخانه nghttp2 است که در بین وابستگی های اسمبلی گنجانده شده است (در آینده قرار است کتابخانه به تعداد وابستگی های اختیاری منتقل شود). هر دو اتصال رمزگذاری شده (TLS) و HTTP/2 رمزگذاری نشده پشتیبانی می شوند. با تنظیمات مناسب، یک فرآیند نام‌گذاری شده تنها می‌تواند نه تنها پرس‌وجوهای DNS سنتی، بلکه پرس‌وجوهایی که با استفاده از DoH (DNS-over-HTTPS) و DoT (DNS-over-TLS) ارسال می‌شوند را نیز ارائه دهد. پشتیبانی HTTPS در سمت کلاینت (dig) هنوز اجرا نشده است. پشتیبانی XFR-over-TLS برای درخواست های ورودی و خروجی در دسترس است.
پردازش درخواست با استفاده از DoH و DoT با افزودن گزینه‌های http و tls به دستورالعمل گوش دادن فعال می‌شود. برای پشتیبانی از DNS-over-HTTP رمزگذاری نشده، باید "tls none" را در تنظیمات مشخص کنید. کلیدها در قسمت "tls" تعریف شده اند. پورت های شبکه پیش فرض 853 برای DoT، 443 برای DoH و 80 برای DNS-over-HTTP را می توان از طریق پارامترهای tls-port، https-port و http-port لغو کرد. به عنوان مثال: tls local-tls { key-file "/path/to/priv_key.pem"; cert-file "/path/to/cert_chain.pem"؛ }; http local-http-server { endpoints { "/dns-query"; }; }; گزینه ها { https-port 443; پورت listen-on 443 tls local-tls http myserver {any;}; }
در میان ویژگی‌های پیاده‌سازی DoH در BIND، یکپارچه‌سازی به‌عنوان یک انتقال عمومی ذکر شده است که می‌تواند نه تنها برای پردازش درخواست‌های مشتری به حل‌کننده، بلکه هنگام تبادل داده‌ها بین سرورها، هنگام انتقال مناطق توسط یک سرور DNS معتبر و هنگام پردازش هر درخواستی که توسط سایر انتقالات DNS پشتیبانی می شود.
ویژگی دیگر، امکان انتقال عملیات رمزگذاری برای TLS به سرور دیگری است، که ممکن است در شرایطی که گواهی‌های TLS در سیستم دیگری ذخیره می‌شوند (مثلاً در یک زیرساخت با سرورهای وب) و توسط سایر پرسنل نگهداری می‌شوند، ضروری باشد. پشتیبانی از DNS-over-HTTP رمزگذاری نشده برای ساده کردن اشکال زدایی و به عنوان یک لایه برای ارسال در شبکه داخلی اجرا می شود که بر اساس آن می توان رمزگذاری را روی سرور دیگری سازماندهی کرد. در یک سرور راه دور، nginx می تواند برای تولید ترافیک TLS، مشابه نحوه سازماندهی اتصال HTTPS برای وب سایت ها استفاده شود.
به یاد بیاوریم که DNS-over-HTTPS می تواند برای جلوگیری از درز اطلاعات در مورد نام میزبان درخواستی از طریق سرورهای DNS ارائه دهندگان، مبارزه با حملات MITM و جعل ترافیک DNS (به عنوان مثال، هنگام اتصال به Wi-Fi عمومی)، مقابله مفید باشد. مسدود کردن در سطح DNS (DNS-over-HTTPS نمی تواند جایگزین VPN در دور زدن مسدودسازی اجرا شده در سطح DPI شود) یا برای سازماندهی کار در زمانی که دسترسی مستقیم به سرورهای DNS غیرممکن است (مثلاً هنگام کار از طریق یک پروکسی). اگر در شرایط عادی درخواست‌های DNS مستقیماً به سرورهای DNS تعریف‌شده در پیکربندی سیستم ارسال می‌شوند، در مورد DNS-over-HTTPS، درخواست تعیین آدرس IP میزبان در ترافیک HTTPS کپسوله شده و به سرور HTTP ارسال می‌شود. حل کننده درخواست ها را از طریق Web API پردازش می کند.
«DNS over TLS» با «DNS over HTTPS» در استفاده از پروتکل استاندارد DNS متفاوت است (درگاه شبکه 853 معمولاً استفاده می‌شود)، پیچیده شده در یک کانال ارتباطی رمزگذاری‌شده که با استفاده از پروتکل TLS با بررسی اعتبار میزبان از طریق گواهی‌های TLS/SSL تأیید شده است. توسط یک مرجع صدور گواهینامه استاندارد موجود DNSSEC از رمزگذاری فقط برای احراز هویت مشتری و سرور استفاده می کند، اما از ترافیک در برابر رهگیری محافظت نمی کند و محرمانه بودن درخواست ها را تضمین نمی کند.
منبع: opennet.ru