DNS-serveri BIND 9.18.0 väljaandmine DNS-over-TLS ja DNS-over-HTTPS toe kanssa

Kaks aastat kestnud arendustööd ISC konsortsium on tutvustanud uue olulise haru DNS-serverist BIND 9.18 esimest stabiilset väljaannet. Haru 9.18 tuge toetatakse kolm aastat kuni 2025. aasta teise kvartalini laiendatud toe tsükli raames. Haru 9.11 toetus lõppeb märtsis ja haru 9.16 keskel 2023. Funktsionaalsuse arendamiseks järgmiseks stabiilseks versiooniks on loodud eksperimentaalne haru BIND 9.19.0.

BIND 9.18.0 väljaande selgeim omadus on toetuse teostamine tehnoloogiate jaoks nagu 'DNS HTTPS-i kaudu' (DoH, DNS over HTTPS) ja DNS TLS-i kaudu (DoT, DNS over TLS), samuti mehhanismi XoT (XFR-over-TLS) rakendamine DNS-tsoonide turvaliseks edastamiseks serverite vahel (toetatakse nii kandeid kui ka vastuvõtte tsoonide kaudu XoT). Vastava seadistusega võib üks named protsess nüüd teenindada mitte ainult traditsioonilisi DNS-päringuid, vaid ka päringute vastuvõtmist, mis saadeti DNS-over-HTTPS ja DNS-over-TLS abil. DNS-over-TLS klienttugi on integreeritud utiliiti dig, mida saab kasutada TLS-i kaudu päringute saatmiseks, kui määrata lipp '+tls'.

HTTP/2 protokolli rakendamine, mida kasutatakse DoH-is, põhineb nghttp2 teegil, mis kuulub valikuline kompileerimise sõltuvus. Sertifikaate DoH ja DoT jaoks võib pakkuda kasutaja või genereerida automaatselt käivitamisel.

DoH ja DoT päringute töötlemine lülitatakse sisse, lisades 'http' ja 'tls' valikud listen-on direktiivi. Tootes tuleb määrata 'tls none', et toetada krüpteerimata DNS-over-HTTP. Võtmed määratakse 'tls' sektsioonis. Standardseid võrguporte 853 DoT-i, 443 DoH-i ja 80 DNS-over-HTTP jaoks saab üle kirjutada tls-port, https-port ja http-port parameetrite 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 rakendamise eripära on võimalus viia TLS-i krüpteerimise toimingud teisele serverile. See võib osutuda vajalikuks situatsioonides, kus TLS-sertifikaate hoitakse teises süsteemis (näiteks veebiserverite infrastruktuuris) ja haldab seda teine personal. Dešifreerimata DNS-over-HTTP toetus on rakendatud silumise lihtsustamiseks ja kui tasand, mis võimaldab suunata teisele serverile sisevõrgus (et viia krüpteerimine eraldi serverile). TLS-i liikluse genereerimiseks välisse serveris saab kasutada nginx-i, sarnaselt sellele, kuidas on korraldatud HTTPS-i sidumine veebilehtede jaoks.

Teine eripära on DoH-i integreerimine üldiseks transpordiks, mida ei rakendata ainult kliendi päringute töötlemiseks resolveri poole, vaid ka serverite vahelise andmevahetuse, tsoonide edastamise autoriteetse DNS-serveri kaudu ja igasuguste päringute töötlemisel, mida toetavad muud DNS-i transpordid.

Puudustest, mida on võimalik kompenseerida DoH/DoT koostamise väljalülitamise või krüptimise viimisele teisele serverile, tõuseb esile üldine koodibaasi keerukuse suurenemine — lisandub sisseehitatud HTTP-server ja TLS-raamatukogu, mis võivad potentsiaalselt sisaldada nõrkusi ja olla täiendavad rünnaku sihtmärgid. Samuti DoH-i kasutamisel suureneb liiklus.

Tuletame meelde, et DNS-over-HTTPS võib olla kasulik, et vältida andmete leket päringute nimekirjast DNS-teenuse pakkujate kaudu, võidelda MITM-rünnakute ja DNS-liikluse asendamisega (näiteks avaliku Wi-Fi kaudu ühenduse loomisel), samuti vastu seista DNS-i taseme blokeerimisele (DNS-over-HTTPS ei saa asendada VPN DPI-taseme blokeeringute ületamisel või töö korraldamisel, kui ei ole võimalik otse DNS-serveritega ühendust saada (nt proxy kaudu töötamisel). Kui tavaliselt DNS-päringud saadetakse otse süsteemi konfigureeritud DNS-serveritele, siis DNS-over-HTTPS korral on hosti määramine kaasatud HTTPS-i liiklusesse ja saadetud HTTP-serverile, kus resolver käitleb päringud Web API kaudu. IP-aadressid Päring hosti määramiseks on saadetud HTTPS-i liikluses ja suunatud HTTP-serverisse, kus resolver töötleb päringud Web API kaudu.

DNS over TLS erineb DNS over HTTPS-ist, kuna kasutab tavapärast DNS-protokolli (tavaliselt kasutatakse võrgupesa 853), mis on krüpteeritud TLS-protokolli abil loodud sidekanalis ja mille käigus kontrollitakse hosti kehtivust TLS/SSL-sertifikaatide kaudu, mis on allkirjastatud sertifitseerimiskeskuse poolt. Olemasolev DNSSEC standard kasutab krüptimist ainult kliendi ja serveri autentimiseks, kuid ei kaitse liiklust pealtkuulamise eest ega garanteeri päringute konfidentsiaalsust.

Mõned muud uuendused:

• On lisatud tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer ja udp-send-buffer seaded, et määrata buferite suurused, mida kasutatakse TCP ja UDP kaudu päringute saatmisel ja vastuvõtmisel. Suure koormuse all olevatel serveritel võimaldab sissetulevate buferite suurendamine vältida pakettide ära viskamist liikluspiikide ajal, samas kui vähendamine aitab vabastada mälu vanadest päringust.
• On lisatud uus logide kategooria „rpz-passthru“, mis võimaldab eraldi logida RPZ (Response Policy Zones) edastamise tegevust.
• Response-policy sektsioonis on lisatud valik «nsdname-wait-recurse», mille korral kehtivad RPZ NSDNAME reeglid ainult siis, kui päringu jaoks leitud autoriteetsed nimeserverid on vahemikus, vastasel juhul ignoreeritakse RPZ NSDNAME reeglit, kuid teavet koostatakse taustal ja rakendatakse järgnevatele päringutele.
• HTTPS ja SVCB tüüpidega rekordite puhul on rakendatud ADDITION sektsiooni töötlemine.
• Lisatud kohandatavad update-policy reegli tüübid — krb5-subdomain-self-rhs ja ms-subdomain-self-rhs, mis võimaldavad piirata SRV ja PTR rekordite uuendamist. Update-policy plokkides on samuti lisatud võimalus määrata rekordite arvu piiranguid, mis on iga tüübi jaoks eraldi.
• Dig utiliidi väljundisse on lisatud teave ülekande protokolli (UDP, TCP, TLS, HTTPS) ja DNS64 eesliidete kohta. Debugimise eesmärkidel on digis lisatud võimalus määrata kindel päringu identifikaator (dig +qid=).
• Lisatud tugi OpenSSL 3.0 raamatukogule.
• Suure DNS-sõnumite töötlemise IP-fragmentatsiooniprobleemide lahendamiseks, mis on määratud DNS Flag Day 2020 algatusega, on resolverist eemaldatud kood, mis kohandab EDNS-i pufferi suurust, kui päringule ei ole vastust. EDNS-i puhvri suurus määratakse nüüd konstantseks (edns-udp-size) kõigi väljaminevate päringute jaoks.
• Kogumissüsteem on üle viidud autoconf, automake ja libtool-i kombinatsiooni kasutamisele.
• Zone-faile formaadis "map" (masterfile-format map) ei toetata enam. Kasutajatele, kes kasutavad seda formaati, soovitatakse zone'd konverteerida formaati raw abiks utiliidiga named-compilezone.
• Vanade DLZ (Dynamically Loadable Zones) draiverite tugi on lõpetatud ning nende asemel on kasutusele võetud DLZ moodulid.
• Windowsi platvormi jaoks ei toeta enam koostamist ja käivitamist. Viimane haru, mille saab Windowsi installida, on BIND 9.16.

Allikas: opennet.ru