След два години разработка, консорциумът 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 е реализирана за опростяване на дебъгването и като слой за предаване на друг сървър във вътрешната мрежа (за изнасяне на шифроването на отделен сървър). На изнесения сървър за генериране на TLS трафик може да се използва nginx, по аналогия с начините, по които се организира обвивката HTTPS за сайтове.
Друг отличителен белег е интегрирането на DoH като общ транспорт, който може да се използва не само за обработка на запитвания от клиенти към резолвера, но и при обмен на данни между сървъри, при предаване на зони от авторитетния DNS сървър и при обработка на всякакви запитвания, поддържани от другите транспортни протоколи на DNS.
От недостатъците, които могат да бъдат компенсирани чрез деактивиране на сборката с DoH/DoT или изнасяне на шифроването на друг сървър, се откроява общото усложнение на кодовата база — включен е вграден HTTP сървър и TLS библиотека, които потенциално могат да съдържат уязвимости и да представляват допълнителни вектори за атаки. Също така, при използването на DoH се увеличава трафикът.
Напомняме, че DNS-over-HTTPS може да бъде полезен за предотвратяване на изтичане на информация за заявените имена на хостове чрез DNS-сървъри на доставчици, за борба с MITM атаки и подмяна на DNS трафик (например, при свързване към публични Wi-Fi), срещу блокировки на ниво DNS (DNS-over-HTTPS не може да замени в областта на заобикалянето на блокировки, реализирани на ниво DPI) или за организиране на работа в случай на невъзможност за директен достъп до DNS-сървъри (например, при работа през прокси). Ако в нормалната ситуация DNS запитванията се изпращат директно на определените в конфигурацията на системата DNS сървъри, то при DNS-over-HTTPS запитването за определяне на хост се инкапсулира в HTTPS трафик и се изпраща на HTTP сървър, на който резолверът обработва запитванията чрез Web API. VPN На изнесения сървър за генериране на TLS трафик може да се използва nginx, по аналогия с начините, по които се организира обвивката 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
