Разработчики DNS-сервера BIND сообщили о добавлении в экспериментальную ветку 9.17 реализации серверной поддержки технологий «DNS поверх HTTPS» (DoH, DNS over HTTPS) и DNS поверх TLS (DoT, DNS over TLS), а также механизма XFR-over-TLS для безопасной передачи содержимого DNS-зон между серверами. DoH доступен для тестирования в выпуске 9.17.10, а поддержка DoT присутствует начиная с выпуска 9.17.7. После стабилизации поддержка DoT и DoH будет бэкпортирована в стабильную ветку 9.16.
Реализация протокола HTTP/2, используемого в DoH, основана на применении библиотеки nghttp2, которая включена в число сборочных зависимостей (в дальнейшем библиотеку планируется перевести в число необязательных зависимостей). Поддерживаются как шифрованные (TLS), так и незашифрованные соединения по HTTP/2. При соответствующих настройках один процесс named теперь может обслуживать не только традиционные DNS-запросы, но и запросы, отправленные с использованием DoH (DNS-over-HTTPS) и DoT (DNS-over-TLS). Поддержка HTTPS на стороне клиента (dig) пока не реализована. поддержка XFR-over-TLS доступна как для входящих, так и для исходящих запросов.
Обработка запросов с использованием DoH и DoT включается через добавление опций http и tls в директиве listen-on. Для поддержки незашифрованного 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»; }; }; options { https-port 443; listen-on port 443 tls local-tls http myserver {any;}; }
Из особенностей реализации DoH в BIND отмечается интеграция в качестве общего транспорта, который может применяться не только для обработки запросов клиентов к резолверу, но и при обмене данными между серверами, при передаче зон авторитетным DNS-сервером и при обработке любых запросов, поддерживаемых другими транспортами DNS.
Другой особенности является возможность выноса операций шифрования для TLS на другой сервер, что может понадобиться в условиях, когда хранение TLS-сертификатов осуществляется на другой системе (например, в инфраструктуре с web-серверами) и обслуживается другим персоналом. Поддержка незашифрованного DNS-over-HTTP реализована для упрощения отладки и как уровень для проброса во внутренней сети, на базе которого на другом сервере может быть организовано шифрование. На выносном сервере для формирования TLS-трафика может использоваться nginx, по аналогии с тем, как организуется обвязка HTTPS для сайтов.
Kordame, et DNS-over-HTTPS võib olla kasulik, et vältida teenusteandmete leket DNS-serverite kaudu, võidelda MITM-rünnakute ja DNS-traafiku vale edastamise vastu (näiteks avalikus Wi-Fi-võrgus), seista vastu DNS-tasandi blokeeringutele (DNS-over-HTTPS ei saa asendada VPN blokeeringute vältimist DPI tasemel) või kutsuda esile töö korraldamise juhul, kui ei ole võimalik otse DNS-serveritele pöörduda (näiteks proxy kaudu töötades). Kui tavaliselt saadetakse DNS-päringud otse süsteemi konfigureeritud DNS-serveritele, siis DNS-over-HTTPS korral saadetakse päring hosti määratlemiseks IP-aadressid HTTPS-i liiklusesse ja saadetakse HTTP-serverisse, kus resolver töötab päringute kaudu Web API.
„DNS over TLS“ erineb „DNS over HTTPS“ tavalise DNS-protokolli (tavaliselt kasutatakse võrguporti 853) rakendamise poolest, mis on pakitud krüpteeritud suhtluskanalisse, mis on korraldatud TLS-protokolli abil ning mille hosti valideerimine toimub TLS/SSL-sertifikaatide kaudu, mille on allkirjastanud sertifitseerimiskeskus. Praegune DNSSEC-i standard kasutab krüpteerimist ainult kliendi ja serveri autentimiseks, kuid ei kaitse liiklust pealtkuulamise eest ja ei taga päringute konfidentsiaalsust.
Allikas: opennet.ru
