Po dveh letih razvoja je konzorcij ISC izdal prvo stabilno izdajo večje nove veje strežnika BIND 9.18 DNS. Podpora za vejo 9.18 bo zagotovljena tri leta do 2. četrtletja 2025 kot del razširjenega cikla podpore. Podpora za vejo 9.11 se bo končala marca, podpora za vejo 9.16 pa sredi leta 2023. Za razvoj funkcionalnosti naslednje stabilne različice BIND je bila oblikovana poskusna veja BIND 9.19.0.
Izdaja BIND 9.18.0 je znana po izvedbi podpore za DNS prek HTTPS (DoH, DNS prek HTTPS) in DNS prek TLS (DoT, DNS prek TLS), kot tudi mehanizem XoT (XFR-over-TLS). za varen prenos vsebine DNS cone med strežniki (podprta sta tako pošiljajoča kot sprejemna cona prek XoT). Z ustreznimi nastavitvami lahko en sam poimenovan proces zdaj služi ne samo tradicionalnim poizvedbam DNS, ampak tudi poizvedbam, poslanim z uporabo DNS-over-HTTPS in DNS-over-TLS. Odjemalska podpora za DNS-over-TLS je vgrajena v pripomoček dig, ki se lahko uporablja za pošiljanje zahtev prek TLS, ko je navedena zastavica "+tls".
Implementacija protokola HTTP/2, uporabljenega v DoH, temelji na uporabi knjižnice nghttp2, ki je vključena kot izbirna odvisnost sestava. Potrdila za DoH in DoT lahko zagotovi uporabnik ali pa se ustvarijo samodejno ob zagonu.
Obdelava zahtev z uporabo DoH in DoT je omogočena z dodajanjem možnosti »http« in »tls« v direktivo poslušanja. Če želite podpreti nešifrirani DNS prek HTTP, morate v nastavitvah določiti »tls none«. Ključi so definirani v razdelku "tls". Privzeta omrežna vrata 853 za DoT, 443 za DoH in 80 za DNS-over-HTTP je mogoče preglasiti s parametri tls-port, https-port in http-port. Na primer:
tls local-tls { ključna datoteka "/path/to/priv_key.pem"; datoteka-cert "/path/to/cert_chain.pem"; }; http lokalni-http-strežnik { končne točke { "/dns-poizvedba"; }; }; možnosti { https-vrata 443; vrata za poslušanje 443 tls local-tls http myserver {any;}; }
Ena od značilnosti implementacije DoH v BIND je zmožnost premika operacij šifriranja za TLS na drug strežnik, kar je lahko potrebno v pogojih, ko so potrdila TLS shranjena v drugem sistemu (na primer v infrastrukturi s spletnimi strežniki) in vzdrževana s strani drugega osebja. Podpora za nešifrirani DNS prek HTTP je implementirana za poenostavitev odpravljanja napak in kot plast za posredovanje na drug strežnik v notranjem omrežju (za premik šifriranja na ločen strežnik). Na oddaljenem strežniku lahko nginx uporabite za ustvarjanje prometa TLS, podobno kot je vezava HTTPS organizirana za spletna mesta.
Druga značilnost je integracija DoH kot splošnega transporta, ki se lahko uporablja ne le za obravnavanje zahtev odjemalcev do razreševalnika, ampak tudi pri komunikaciji med strežniki, pri prenosu območij s strani avtoritativnega strežnika DNS in pri obdelavi poizvedb, ki jih podpirajo drugi DNS prevozi.
Med pomanjkljivostmi, ki jih lahko kompenziramo z onemogočanjem gradnje z DoH/DoT ali prestavitvijo šifriranja na drug strežnik, izstopa splošna zapletenost kodne baze - dodana sta vgrajen strežnik HTTP in knjižnica TLS, ki bi potencialno lahko vsebovala ranljivosti in delujejo kot dodatni vektorji za napade. Tudi pri uporabi DoH se promet poveča.
Spomnimo se, da je DNS-over-HTTPS lahko koristen za preprečevanje uhajanja informacij o zahtevanih imenih gostiteljev prek strežnikov DNS ponudnikov, boj proti napadom MITM in ponarejanje prometa DNS (na primer pri povezovanju z javnim omrežjem Wi-Fi), preprečevanje blokiranje na ravni DNS (DNS-over-HTTPS ne more nadomestiti VPN-ja pri obhodu blokade, implementirane na ravni DPI) ali za organizacijo dela, ko ni mogoče neposredno dostopati do strežnikov DNS (na primer pri delu prek proxyja). Če so v običajnem primeru zahteve DNS neposredno poslane strežnikom DNS, definiranim v sistemski konfiguraciji, potem je v primeru DNS prek HTTPS zahteva za določitev naslova IP gostitelja enkapsulirana v promet HTTPS in poslana strežniku HTTP, kjer razreševalec obdela zahteve prek spletnega API-ja.
»DNS prek TLS« se razlikuje od »DNS prek HTTPS« po uporabi standardnega protokola DNS (običajno se uporabljajo omrežna vrata 853), zavitega v šifriran komunikacijski kanal, organiziran z uporabo protokola TLS s preverjanjem veljavnosti gostitelja s potrjenimi certifikati TLS/SSL s strani certifikacijskega organa. Obstoječi standard DNSSEC uporablja šifriranje samo za avtentikacijo odjemalca in strežnika, vendar ne ščiti prometa pred prestrezanjem in ne zagotavlja zaupnosti zahtev.
Nekaj drugih novosti:
- Dodane nastavitve tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer in udp-send-buffer nastavitve za nastavitev velikosti medpomnilnikov, ki se uporabljajo pri pošiljanju in prejemanju zahtev prek TCP in UDP. Na zasedenih strežnikih bo povečanje dohodnih medpomnilnikov pomagalo preprečiti, da bi paketi padli med prometnimi konicami, njihovo zmanjšanje pa bo pomagalo odpraviti zamašitev pomnilnika s starimi zahtevami.
- Dodana je bila nova kategorija dnevnika »rpz-passthru«, ki vam omogoča ločeno beleženje dejanj posredovanja RPZ (Response Policy Zones).
- V razdelku pravilnika odziva je bila dodana možnost »nsdname-wait-recurse«, ko je nastavljena na »ne«, se pravila RPZ NSDNAME uporabijo le, če so za zahtevo najdeni avtoritativni imenski strežniki, prisotni v predpomnilniku, sicer Pravilo RPZ NSDNAME je prezrto, vendar se informacije pridobijo v ozadju in veljajo za naslednje zahteve.
- Za zapise s tipoma HTTPS in SVCB je implementirana obdelava razdelka »DODATNO«.
- Dodani tipi pravil pravilnika posodabljanja po meri - krb5-subdomain-self-rhs in ms-subdomain-self-rhs, ki vam omogočajo, da omejite posodobitev zapisov SRV in PTR. Bloki pravilnika o posodabljanju prav tako dodajajo možnost nastavitve omejitev števila zapisov, za vsako vrsto posebej.
- Dodane informacije o transportnem protokolu (UDP, TCP, TLS, HTTPS) in predponah DNS64 v izhodu pripomočka dig. Za namene odpravljanja napak je dig dodal možnost podajanja posebnega identifikatorja zahteve (dig +qid= ).
- Dodana podpora za knjižnico OpenSSL 3.0.
- Za odpravo težav z razdrobljenostjo IP pri obdelavi velikih sporočil DNS, ki jih identificira dan zastave DNS 2020, je bila koda, ki prilagodi velikost vmesnega pomnilnika EDNS, ko ni odgovora na zahtevo, odstranjena iz razreševalnika. Velikost medpomnilnika EDNS je zdaj nastavljena na konstantno (edns-udp-size) za vse odhodne zahteve.
- Sistem gradnje je bil preklopljen na uporabo kombinacije autoconf, automake in libtool.
- Podpora za conske datoteke v formatu »map« (masterfile-format map) je bila ukinjena. Uporabnikom tega formata priporočamo pretvorbo območij v neobdelani format z uporabo pripomočka named-compilezone.
- Podpora za starejše gonilnike DLZ (Dynamically Loadable Zones) je bila ukinjena in nadomeščeni z moduli DLZ.
- Podpora za gradnjo in izvajanje za platformo Windows je bila ukinjena. Zadnja veja, ki jo lahko namestite v Windows, je BIND 9.16.
Vir: opennet.ru