Pärast kahte aastat arendust esitles ISC konsortsium DNS-serveri BIND 9.18 esimese stabiilse väljaande uut olulist haru. Haru 9.18 toetamist jätkatakse kolme aasta jooksul kuni 2025. aasta teise kvartalini laiendatud hooldustsükli raames. Haru 9.11 tugi lõpeb märtsis ja haru 9.16 keskpaiku 2023. aastal. Järgmise stabiilse versiooni funktsionaalsuse arendamiseks on loodud katseharu BIND 9.19.0.
BIND 9.18.0 väljaanne on tähelepanuväärne tehnoloogiate „DNS HTTPS-i kaudu” (DoH, DNS over HTTPS) ja DNS TLS-i kaudu (DoT, DNS over TLS) toe rakendamise ning DNS-vööndite sisu turvaliseks edastamiseks mõeldud XoT (XFR-over-TLS) mehhanismi osas (toetatakse nii vööndite saatmist kui ka vastuvõttu XoT kaudu). Vastava seadistuse korral saab üks named protsess teenindada mitte ainult traditsioonilisi DNS-päringuid, vaid ka päringuid, mis on saadetud DNS-over-HTTPS ja DNS-over-TLS abil. Klientide tugi DNS-over-TLS-le on integreeritud utiliiti dig, mida saab kasutada päringute saatmiseks TLS-kihi kaudu, kui määrata lipp „+tls”.
DoH-is kasutatava HTTP/2 protokolli rakendamine põhineb nghttp2 teegi kasutamisel, mis on hõlmatud valikuliste ehituse sõltuvuste hulka. DoH ja DoT sertifikaadid võivad olla kasutaja pakutud või genereeritud automaatselt käivitamise ajal.
Päringute töötlemine DoH ja DoT abil sisselülitatakse, lisades direktiivi listen-on valikuid „http” ja „tls”. Krüpteerimata DNS-over-HTTP toetamiseks tuleks seadistustes näidata „tls none”. Lõppvõtmed määratakse „tls” sektsioonis. Standardsed võrguportid 853 DoT-i, 443 DoH-i ja 80 DNS-over-HTTP jaoks võivad olla üle kirjutatud parameetrite tls-port, https-port ja http-port kaudu. Näiteks:
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;}; }
BINDi DoH-i teostuse eripäradest on märgitud võimalust viia TLS krüpteerimise toimingud teisele serverile, mis võib olla vajalik olukordades, kus TLS-sertifikaatide hoidmine toimub teisel süsteemil (näiteks veebiserverite infrastruktuuris) ja seda haldab teine personal. Tugi krüpteerimata DNS-over-HTTP-le on rakendatud tõrkeotsingu lihtsustamiseks ja tasemena, et suunata andmed teisele serverile sisevõrgus (krüpteerimise viimiseks eraldi serverisse). Nginx-i võib kasutada välises serveris TLS-traafiku genereerimiseks, sarnaselt sellele, kuidas korraldatakse HTTPS-i vahetus veebilehtede jaoks.
Teine eripära on DoH-i integreerimine üldise transpordina, mida saab kasutada mitte ainult kliendi päringute töötlemiseks resolvijale, vaid ka serverite vahel andmete vahetamisel, autoriteetse DNS-serveri kaudu tsoonide edastamisel ja igasuguste päringute töötlemisel, mida toetavad teised DNS-i transpordid.
Puudustest, mida saab kõrvaldada DoH/DoT kogumise keelamise või krüpteerimise viimisega teisele serverile, toome esile üldise koodibaasi keerukuse — koos lisatakse sisseehitatud HTTP-server ja TLS-kämpus, mis võib potentsiaalselt sisaldada haavatavusi ning olla täiendavate rünnakute vektoriteks. Samuti, kui kasutatakse DoH-i, suureneb liiklus.
Kordame, et DNS-over-HTTPS võib olla kasulik, et vältida teenusteandmete leket DNS-serverite kaudu, võidelda MITM-rünnakute ja DNS-traafiku vale edastamise vastu (näiteks avalikus Wi-Fi-võrgus), seista vastu DNS-tasandi blokeeringutele (DNS-over-HTTPS ei saa asendada VPN blokeeringute vältimist DPI tasemel) või kutsuda esile töö korraldamise juhul, kui ei ole võimalik otse DNS-serveritele pöörduda (näiteks proxy kaudu töötades). Kui tavaliselt saadetakse DNS-päringud otse süsteemi konfigureeritud DNS-serveritele, siis DNS-over-HTTPS korral saadetakse päring hosti määratlemiseks IP-aadressid HTTPS-i liiklusesse ja saadetakse HTTP-serverisse, kus resolver töötab päringute kaudu Web API.
„DNS over TLS“ erineb „DNS over HTTPS“ tavalise DNS-protokolli (tavaliselt kasutatakse võrguporti 853) rakendamise poolest, mis on pakitud krüpteeritud suhtluskanalisse, mis on korraldatud TLS-protokolli abil ning mille hosti valideerimine toimub TLS/SSL-sertifikaatide kaudu, mille on allkirjastanud sertifitseerimiskeskus. Praegune DNSSEC-i standard kasutab krüpteerimist ainult kliendi ja serveri autentimiseks, kuid ei kaitse liiklust pealtkuulamise eest ja ei taga päringute konfidentsiaalsust.
Mõned teised uuendused:
- Lisatud tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer ja udp-send-buffer seaded, mis määravad TCP ja UDP päringute saatmisel ja vastuvõtmisel kasutatavate puhvrite suurused. Koormatud serveritel võimaldab suurte sissetulevate puhvrite suurendamine vältida pakettide kukutamist liikluskaisease hetkedel, samas kui vähendamine aitab vabaneda vana liiklusest mälu ummistumise eest.
- Lisatud uus logikategooria „rpz-passthru“, mis võimaldab eraldi ajaloos registreerida RPZ (Response Policy Zones) edastamise tegevusi.
- Response-policy sektsiooni on lisatud valik „nsdname-wait-recurse“, mille seadistamisel väärtusele „ei“ rakendatakse RPZ NSDNAME reeglid ainult juhul, kui päringu jaoks leiti mälus kohalolevad autoriteetsed nimiserverid, vastasel juhul ignoreeritakse RPZ NSDNAME reeglit, kuid teave kaevandatakse taustal ja rakendatakse järgmistele päringutele.
- HTTPS ja SVCB tüübi kirjade jaoks on rakendatud „ADDITIONAL“ sektsiooni töötlemine.
- Lisatud kohandatavad värskendusreeglite tüübid update-policy - krb5-subdomain-self-rhs ja ms-subdomain-self-rhs, mis võimaldavad piirata SRV ja PTR kirjade värskendamist. Värskendusreeglite plokkides on lisatud ka võimalus seada kirjade arvu piiranguid, mis on erinevad iga tüübi jaoks.
- Dig utiliidi väljundisse on lisatud teave edastusprotokolli (UDP, TCP, TLS, HTTPS) ja DNS64 prefiksite kohta. Silumise eesmärkidel on dig utiliidile lisatud võimalus määrata konkreetne päringu identifikaator (dig +qid=).
- Lisatud OpenSSL 3.0 toe tugi.
- IP-fragmentatsiooniprobleemide lahendamiseks suurte DNS-sõnumite töötlemisel, mille on näidanud DNS Flag Day 2020 algatus, on resolverist eemaldatud kood, mis kohandab EDNS puhvri suurust, kui vastust päringule pole. EDNS puhvri suurus seotakse nüüd konstantseks (edns-udp-size) kõigi väljuvate päringute puhul.
- Kogumissüsteem on üle viidud autoconfi, automake‘i ja libtool’i kogumisse.
- Toetatud zonifailide toetamine formaadis „map“ (masterfile-format map) on lõpetatud. Selle formaadi kasutajatele soovitatakse tsoonid konverteerida raw formaati utiliidi named-compilezone abil.
- Vanade DLZ (Dynamically Loadable Zones) draiverite toetus on lõpetatud ning nende asemel on kasutusele võetud DLZ moodulid.
- Windowsi platvormi jaoks ei toeta enam kogumist ja käivitamist. Viimane versioon, mille Windowsi saab installida, on BIND 9.16.
Allikas: opennet.ru
