Публикация на DNS-сървъра BIND 9.18.0 с поддръжка на DNS-over-TLS и DNS-over-HTTPS

След като разработката продължи две години, консорциумът ISC представи първия стабилен релиз на новата значима версия на DNS сървъра BIND 9.18. Поддръжката на версия 9.18 ще продължи три години до второто тримесечие на 2025 г. Поддръжката на версия 9.11 ще бъде прекратена през март, а на версия 9.16 в средата на 2023 г. За развитие на функционалността на следващата стабилна версия на BIND е създадена експериментална версия BIND 9.19.0.

Издаването на BIND 9.18.0 е забележително с внедряването на поддръжка за технологии «DNS върху HTTPS» (DoH, DNS over HTTPS) и DNS върху TLS (DoT, DNS over TLS), а също и механизма XoT (XFR-over-TLS) за сигурен трансфер на съдържание на DNS зони между сървъри (поддържа се както предаване, така и приемане на зони по XoT). При съответна конфигурация един процес named вече може да обслужва не само традиционни DNS запитвания, но и запитвания, изпратени чрез DNS-over-HTTPS и DNS-over-TLS. Клиентската поддръжка на DNS-over-TLS е вградена в утилитата dig, която може да се използва за изпращане на запитвания върху TLS, като се посочи флагът «+tls».

Имплементацията на протокола HTTP/2, използван в DoH, се базира на използването на библиотеката nghttp2, която е включена в списъка с опционални зависимости за компилация. Сертификатите за DoH и DoT могат да бъдат предоставени от потребителя или генерирани автоматично по време на стартиране.

Обработката на запитвания с използване на 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 е че шифровъчните операции за TLS могат да се прехвърлят на сървър, различен от основния. Това е полезно в ситуации, когато TLS сертификатите се съхраняват на друга система (например, в инфраструктура с уеб сървъри) и са управлявани от друг екип. Поддръжката на незашифрован DNS-over-HTTP е внедрена за улесняване на дебъгването и служи за преход към друг сървър в вътрешната мрежа (за прехвърляне на шифроването на отделен сървър). Nginx може да се използва на преносимия сървър за генериране на TLS трафик, аналогично на начина, по който се организира обвивката на HTTPS за сайтове.

Друга особеност е интеграцията на DoH като общ транспорт, който може да се използва не само за обработка на заявки от клиентите към резолвера, но и при обмен на данни между сървъри, при прехвърляне на зони от авторитетен DNS сървър и при обработка на всякакви заявки, поддържани от другите DNS транспорти.

Сред недостатъците, които могат да бъдат компенсирани с деактивиране на изграждането с DoH/DoT или прехвърляне на шифроването на друг сървър, е общото усложнение на кодовата база — добавя се вграден HTTP сървър и TLS библиотека, които потенциално може да съдържат уязвимости и да представляват допълнителни вектори за атаки. Също така, използването на DoH увеличава трафика.

Напомняме, че 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 използва криптиране само за удостоверяване на клиента и сървъра, но не защитава трафика от прихващане и не гарантира конфиденциалността на заявките.

Някои други нововъведения:

• Добавени са настройки tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer и udp-send-buffer за задаване на размерите на буферите, използвани при изпращане и получаване на заявки по TCP и UDP. На натоварени сървъри, увеличаването на входящите буфери ще помогне да се избегне отхвърлянето на пакети по време на пиково натоварване, а намаляването ще помогне да се избегне запълването на паметта с остарели заявки.
• Добавена е нова категория логове «rpz-passthru», която позволява да се журнализират отделно действията по пробросване на RPZ (Response Policy Zones).
• В секцията response-policy е добавена опция «nsdname-wait-recurse», при задаване на стойност «no», правилата RPZ NSDNAME се прилагат само ако за заявката са намерени налични кеширани авторитетни имена сървъри, в противен случай правилото RPZ NSDNAME се игнорира, но информацията се извлича във фонов режим и се прилага към последващите заявки.
• За записи с типове HTTPS и SVCB е реализирана обработка на секцията «ADDITIONAL».
• Добавени са настраиваеми типове правила update-policy — krb5-subdomain-self-rhs и ms-subdomain-self-rhs, позволяващи ограничаване обновлението на SRV и PTR записи. В блоковете update-policy също е добавена възможността за задаване на ограничения в броя записи, специфични за всеки тип.
• В изхода на инструмента dig са добавени данни за транспортния протокол (UDP, TCP, TLS, HTTPS) и префиксите DNS64. За отладъчни цели в dig е добавена възможност за указване на конкретен идентификатор на заявка (dig +qid=).
• Добавена е поддръжка на библиотеката OpenSSL 3.0.
• За решаване на проблеми с IP фрагментацията при обработка на големи DNS съобщения, обозначени от инициативата DNS Flag Day 2020, от резолвера е премахнат кодът, който коригира размера на буфера EDNS в случай на липса на отговор на заявката. Размерът на буфера EDNS сега се задава постоянно (edns-udp-size) за всички изходящи заявки.
• Системата за изграждане е преместена към използване на комбинация от autoconf, automake и libtool.
• Поддръжката на файлове с зони в формат «map» (masterfile-format map) е прекратена. На потребителите на този формат се препоръчва да преобразуват зоните в raw формат с помощта на утилитата named-compilezone.
• Поддръжката на старите драйвери DLZ (Dynamically Loadable Zones) е прекратена, като новите модули DLZ ги заменят.
• Поддръжката на компилация и стартиране за платформата Windows е прекратена. Последната версия, която може да бъде инсталирана в Windows, остава BIND 9.16.

Източник: opennet.ru