Пасля двух гадоў распрацоўкі кансорцыўм ISC прадставіў першы стабільны рэліз новай значнай галіны DNS-сервера BIND 9.18. Падтрымка галіны 9.18 будзе ажыццяўляцца на працягу трох гадоў да 2 квартала 2025 года ў рамках пашыранага цыкла суправаджэння. Падтрымка веткі 9.11 спыніцца ў сакавіку, а веткі 9.16 у сярэдзіне 2023 года. Для развіцця функцыянальнасці наступнай стабільнай версіі BIND сфарміравана эксперыментальная галінка BIND 9.19.0.
Выпуск BIND 9.18.0 адметны рэалізацыяй падтрымкі тэхналогій «DNS па-над HTTPS» (DoH, DNS па-над HTTPS) і DNS па-над TLS (DoT, DNS па-над 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-сертыфікатаў ажыццяўляецца на іншай сістэме (напрыклад, у інфраструктуры з web-серверамі) і абслугоўваецца іншым персаналам. Падтрымка незашыфраванага 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 не можа замяніць 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