След две години на разработка, консорциумът на ISC пусна първата стабилна версия на основен нов клон на DNS сървъра BIND 9.18. Поддръжката за клон 9.18 ще бъде предоставена за три години до второто тримесечие на 2 г. като част от разширен цикъл на поддръжка. Поддръжката за клон 2025 ще приключи през март, а поддръжката за клон 9.11 в средата на 9.16 г. За да се развие функционалността на следващата стабилна версия на BIND, е създаден експериментален клон BIND 2023.
Изданието на BIND 9.18.0 се отличава с внедряването на поддръжка за DNS през HTTPS (DoH, DNS през HTTPS) и DNS през TLS (DoT, DNS през TLS), както и механизма XoT (XFR-over-TLS) за сигурно прехвърляне на DNS съдържание зони между сървъри (поддържат се зони за изпращане и получаване чрез XoT). С подходящите настройки един наименуван процес вече може да обслужва не само традиционни DNS заявки, но и заявки, изпратени чрез DNS-over-HTTPS и DNS-over-TLS. Клиентската поддръжка за DNS-over-TLS е вградена в помощната програма за копаене, която може да се използва за изпращане на заявки през TLS, когато е посочен флагът "+tls".
Изпълнението на протокола HTTP/2, използван в DoH, се основава на използването на библиотеката nghttp2, която е включена като незадължителна зависимост от асемблиране. Сертификатите за DoH и DoT могат да бъдат предоставени от потребителя или генерирани автоматично по време на стартиране.
Обработката на заявка с помощта на 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 { ключов файл "/path/to/priv_key.pem"; сертификат-файл "/path/to/cert_chain.pem"; }; http local-http-server { endpoints { "/dns-query"; }; }; опции { https-порт 443; порт за слушане 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 сървъра, където резолверът обработва заявки чрез уеб API.
„DNS през TLS“ се различава от „DNS през HTTPS“ по използването на стандартния DNS протокол (обикновено се използва мрежов порт 853), обвит в криптиран комуникационен канал, организиран с помощта на протокола TLS с проверка на валидността на хоста чрез сертифицирани TLS/SSL сертификати от сертифициращ орган. Съществуващият стандарт DNSSEC използва криптиране само за удостоверяване на клиента и сървъра, но не защитава трафика от прихващане и не гарантира поверителността на заявките.
Някои други иновации:
- Добавени са tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer и udp-send-buffer настройки за задаване на размерите на буферите, използвани при изпращане и получаване на заявки през TCP и UDP. На натоварените сървъри увеличаването на входящите буфери ще помогне да се избегне изпускането на пакети по време на пикове на трафика, а намаляването им ще помогне да се отървете от запушването на паметта със стари заявки.
- Добавена е нова категория журнал „rpz-passthru“, която ви позволява отделно да регистрирате действията за препращане на RPZ (зони за политика за отговор).
- В раздела за политика за отговор е добавена опцията „nsdname-wait-recurse“, когато е зададена на „не“, правилата на RPZ NSDNAME се прилагат само ако за заявката са намерени авторитетни сървъри за имена, присъстващи в кеша, в противен случай Правилото за RPZ NSDNAME се игнорира, но информацията се извлича на заден план и се прилага за последващи заявки.
- За записи с типове HTTPS и SVCB е реализирана обработка на секцията „ДОПЪЛНИТЕЛНО“.
- Добавени персонализирани типове правила за актуализиране - krb5-subdomain-self-rhs и ms-subdomain-self-rhs, които ви позволяват да ограничите актуализирането на SRV и PTR записи. Блоковете за политика за актуализиране също така добавят възможност за задаване на ограничения за броя на записите, индивидуални за всеки тип.
- Добавена е информация за транспортния протокол (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.
- Поддръжката на зонови файлове във формат „карта“ (masterfile-format map) е преустановена. На потребителите на този формат се препоръчва да конвертират зони в необработен формат с помощта на помощната програма named-compilezone.
- Поддръжката за по-стари DLZ (Динамично зареждащи се зони) драйвери е преустановена, заменена от DLZ модули.
- Поддръжката за изграждане и изпълнение за платформата Windows е преустановена. Последният клон, който може да бъде инсталиран на Windows, е BIND 9.16.
Източник: opennet.ru