Post du jaroj da evoluo, la ISC-konsorcio publikigis la unuan stabilan eldonon de grava nova branĉo de la BIND 9.18 DNS-servilo. Subteno por branĉo 9.18 estos provizita por tri jaroj ĝis la 2-a kvarono de 2025 kiel parto de plilongigita subtena ciklo. Subteno por la branĉo 9.11 finiĝos en marto, kaj subteno por la branĉo 9.16 meze de 2023. Por evoluigi la funkciecon de la sekva stabila versio de BIND, eksperimenta branĉo BIND 9.19.0 estis formita.
La liberigo de BIND 9.18.0 estas rimarkinda pro la efektivigo de subteno por DNS super HTTPS (DoH, DNS super HTTPS) kaj DNS super TLS (DoT, DNS super TLS), same kiel la mekanismo XoT (XFR-over-TLS). por sekura translokigo de DNS-enhavo.zonoj inter serviloj (kaj sendantaj kaj ricevantaj zonoj per XoT estas subtenataj). Kun la taŭgaj agordoj, ununura nomita procezo nun povas servi ne nur tradiciajn DNS-demandojn, sed ankaŭ demandojn senditajn per DNS-over-HTTPS kaj DNS-over-TLS. Klienta subteno por DNS-over-TLS estas enkonstruita en la dig ilo, kiu povas esti uzata por sendi petojn per TLS kiam la "+tls" flago estas specifita.
La efektivigo de la HTTP/2-protokolo uzata en DoH baziĝas sur la uzo de la nghttp2-biblioteko, kiu estas inkluzivita kiel laŭvola asemblea dependeco. Atestiloj por DoH kaj DoT povas esti provizitaj de la uzanto aŭ generitaj aŭtomate ĉe lanĉtempo.
Peto-traktado uzante DoH kaj DoT estas ebligita aldonante la "http" kaj "tls" opciojn al la aŭskulta direktivo. Por subteni neĉifritan DNS-super-HTTP, vi devus specifi "tls none" en la agordoj. Ŝlosiloj estas difinitaj en la sekcio "tls". La defaŭltaj retaj havenoj 853 por DoT, 443 por DoH kaj 80 por DNS-over-HTTP povas esti anstataŭitaj per la parametroj tls-port, https-port kaj http-port. Ekzemple:
tls local-tls { ŝlosildosiero "/path/to/priv_key.pem"; cert-dosiero "/path/to/cert_chain.pem"; }; http local-http-server { finpunktoj { "/dns-query"; }; }; opcioj { https-port 443; aŭskultebla haveno 443 tls loka-tls http mia servilo {iu;}; }
Unu el la trajtoj de la DoH-efektivigo en BIND estas la kapablo movi ĉifrajn operaciojn por TLS al alia servilo, kio povas esti necesa en kondiĉoj kie TLS-atestiloj estas stokitaj en alia sistemo (ekzemple, en infrastrukturo kun retserviloj) kaj konservitaj. de alia personaro. Subteno por neĉifrita DNS-super-HTTP estas efektivigita por simpligi sencimigon kaj kiel tavolo por plusendado al alia servilo en la interna reto (por movi ĉifradon al aparta servilo). Sur fora servilo, nginx povas esti uzata por generi TLS-trafikon, simile al kiel HTTPS-ligado estas organizita por retejoj.
Alia trajto estas la integriĝo de DoH kiel ĝenerala transporto, kiu povas esti uzata ne nur por trakti klientpetojn al la solvanto, sed ankaŭ dum komunikado inter serviloj, dum transdono de zonoj per aŭtoritata DNS-servilo, kaj dum prilaborado de ajnaj demandoj subtenataj de aliaj DNS. transportoj.
Inter la mankoj, kiujn oni povas kompensi malŝaltante la konstruon kun DoH/DoT aŭ movante la ĉifradon al alia servilo, elstaras la ĝenerala komplikaĵo de la koda bazo - aldoniĝas enkonstruita HTTP-servilo kaj TLS-biblioteko, kiuj eble povus enhavi. vundeblecoj kaj agas kiel aldonaj vektoroj por atakoj. Ankaŭ, kiam vi uzas DoH, trafiko pliiĝas.
Ni rememoru, ke DNS-over-HTTPS povas esti utila por malhelpi likojn de informoj pri la petitaj gastigantnomoj tra la DNS-serviloj de provizantoj, kontraŭbatali MITM-atakojn kaj DNS-trafiko-falsadon (ekzemple, kiam vi konektas al publika Wi-Fi), kontraŭbatali. blokado ĉe la DNS-nivelo (DNS-over-HTTPS ne povas anstataŭigi VPN en preterpasi blokadon efektivigitan ĉe la DPI-nivelo) aŭ por organizado de laboro kiam estas neeble rekte aliri DNS-servilojn (ekzemple, kiam vi laboras per prokurilo). Se en normala situacio DNS-petoj estas rekte senditaj al DNS-serviloj difinitaj en la sistema agordo, tiam en la kazo de DNS-over-HTTPS la peto por determini la gastigantan IP-adreson estas enkapsuligita en HTTPS-trafiko kaj sendita al la HTTP-servilo, kie la solvanto procesas petojn per Web API.
"DNS super TLS" diferencas de "DNS super HTTPS" en la uzo de la norma DNS-protokolo (reta haveno 853 estas kutime uzata), envolvita en ĉifrita komunika kanalo organizita per la TLS-protokolo kun gastiganta valideco kontrolanta tra TLS/SSL-atestiloj atestitaj. de atestadaŭtoritato. La ekzistanta DNSSEC-normo uzas ĉifradon nur por aŭtentikigi la klienton kaj servilon, sed ne protektas trafikon kontraŭ interkapto kaj ne garantias la konfidencon de petoj.
Iuj aliaj novigoj:
- Aldonitaj agordoj de tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer kaj udp-send-buffer por agordi la grandecojn de bufroj uzataj dum sendado kaj ricevado de petoj super TCP kaj UDP. Sur okupataj serviloj, pliigi envenantajn bufrojn helpos eviti ke pakaĵetoj estu faligitaj dum trafikpintoj, kaj malpliigi ilin helpos forigi memorŝtopadon kun malnovaj petoj.
- Nova ŝtipkategorio "rpz-passthru" estis aldonita, kiu ebligas al vi aparte ensaluti RPZ (Respons Policy Zones) plusendajn agojn.
- En la sekcio de respondo-politiko, la opcio "nsdname-wait-recurse" estis aldonita, kiam agordita al "ne", la RPZ NSDNAME reguloj estas aplikataj nur se aŭtoritataj nomserviloj ĉeestantaj en la kaŝmemoro estas trovitaj por la peto, alie la RPZ NSDNAME regulo estas ignorita, sed la informoj estas prenitaj en la fono kaj validas por postaj petoj.
- Por rekordoj kun HTTPS kaj SVCB-tipoj, prilaborado de la "ALDONA" sekcio estis efektivigita.
- Aldonitaj kutimaj ĝisdatigaj-politikaj reguloj - krb5-subdomain-self-rhs kaj ms-subdomain-self-rhs, kiuj permesas vin limigi la ĝisdatigon de SRV kaj PTR-rekordoj. La ĝisdatig-politikaj blokoj ankaŭ aldonas la kapablon fiksi limojn pri la nombro da rekordoj, individuaj por ĉiu tipo.
- Aldonitaj informoj pri la transportprotokolo (UDP, TCP, TLS, HTTPS) kaj DNS64-prefiksoj al la eligo de la dig-utilo. Por sencimigaj celoj, dig aldonis la kapablon specifi specifan petan identigilon (dig +qid= ).
- Aldonita subteno por OpenSSL 3.0 biblioteko.
- Por trakti problemojn pri IP-fragmentiĝo dum prilaborado de grandaj DNS-mesaĝoj identigitaj de DNS Flag Day 2020, kodo kiu ĝustigas la EDNS-bufrgrandecon kiam ne ekzistas respondo al peto estis forigita de la solvilo. La EDNS-bufrgrandeco nun estas agordita al konstanta (edns-udp-size) por ĉiuj eksiĝintaj petoj.
- La konstrusistemo estis ŝanĝita al uzado de kombinaĵo de autoconf, automake kaj libtool.
- Subteno por zondosieroj en la "mapo" formato (majstra dosiero-formata mapo) estis nuligita. Uzantoj de ĉi tiu formato estas rekomenditaj konverti zonojn al kruda formato uzante la named-compilezone ilo.
- Subteno por pli malnovaj DLZ (Dynamically Loadable Zones) ŝoforoj estis nuligita, anstataŭigita per DLZ-moduloj.
- Konstrui kaj ruli subtenon por la Vindoza platformo estis nuligita. La lasta branĉo instalebla en Vindozo estas BIND 9.16.
fonto: opennet.ru