По две години развој, конзорциумот ISC го објави првото стабилно издание на голема нова гранка на BIND 9.18 DNS серверот. Поддршката за филијалата 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 е вградена во алатката dig, која може да се користи за испраќање барања преку 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 { key-file "/path/to/priv_key.pem"; cert-датотека "/path/to/cert_chain.pem"; }; http локален-http-сервер { крајни точки { "/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, каде што решавачот обработува барања преку Web 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.
- Поддршката за зонските датотеки во формат „мапа“ (мапа со формат на мастер датотека) е прекината. На корисниците на овој формат им се препорачува да ги конвертираат зоните во необработен формат користејќи ја алатката named-compilezone.
- Поддршката за постарите драјвери за DLZ (Dynamically Loadable Zones) е прекината, заменета со DLZ модули.
- Поддршката за изградба и стартување за платформата Windows е прекината. Последната гранка што може да се инсталира на Windows е BIND 9.16.
Извор: opennet.ru