După doi ani de dezvoltare, consorțiul ISC a lansat prima lansare stabilă a unei noi ramuri majore a serverului DNS BIND 9.18. Sprijinul pentru ramura 9.18 va fi furnizat timp de trei ani până în al doilea trimestru al anului 2, ca parte a unui ciclu de suport extins. Suportul pentru ramura 2025 se va încheia în martie, iar suportul pentru ramura 9.11 la jumătatea anului 9.16. Pentru a dezvolta funcționalitatea următoarei versiuni stabile a BIND, a fost creată o ramură experimentală BIND 2023.
Lansarea BIND 9.18.0 se remarcă prin implementarea suportului pentru DNS peste HTTPS (DoH, DNS peste HTTPS) și DNS peste TLS (DoT, DNS peste TLS), precum și mecanismul XoT (XFR-over-TLS). pentru transferul securizat al conținutului DNS între servere (sunt acceptate atât zonele de trimitere, cât și cele de recepție prin XoT). Cu setările corespunzătoare, un singur proces numit poate servi acum nu numai interogări DNS tradiționale, ci și interogări trimise folosind DNS-over-HTTPS și DNS-over-TLS. Suportul pentru clienți pentru DNS-over-TLS este încorporat în utilitarul dig, care poate fi folosit pentru a trimite cereri prin TLS atunci când este specificat indicatorul „+tls”.
Implementarea protocolului HTTP/2 utilizat în DoH se bazează pe utilizarea bibliotecii nghttp2, care este inclusă ca dependență de asamblare opțională. Certificatele pentru DoH și DoT pot fi furnizate de utilizator sau generate automat la momentul pornirii.
Procesarea cererilor folosind DoH și DoT este activată prin adăugarea opțiunilor „http” și „tls” la directiva listen-on. Pentru a accepta DNS-over-HTTP necriptat, ar trebui să specificați „tls none” în setări. Cheile sunt definite în secțiunea „tls”. Porturile de rețea implicite 853 pentru DoT, 443 pentru DoH și 80 pentru DNS-over-HTTP pot fi suprascrise prin parametrii tls-port, https-port și http-port. De exemplu:
tls local-tls { key-file "/path/to/priv_key.pem"; fișier-cert „/path/to/cert_chain.pem”; }; http local-http-server { endpoints { "/dns-query"; }; }; opțiuni { https-port 443; portul de ascultare 443 tls local-tls http serverul meu {oricare;}; }
Una dintre caracteristicile implementării DoH în BIND este capacitatea de a muta operațiunile de criptare pentru TLS pe un alt server, ceea ce poate fi necesar în condițiile în care certificatele TLS sunt stocate pe alt sistem (de exemplu, într-o infrastructură cu servere web) și întreținute. de către alt personal. Suportul pentru DNS-over-HTTP necriptat este implementat pentru a simplifica depanarea și ca strat pentru redirecționarea către un alt server din rețeaua internă (pentru mutarea criptării pe un server separat). Pe un server la distanță, nginx poate fi utilizat pentru a genera trafic TLS, similar modului în care este organizată legarea HTTPS pentru site-uri web.
O altă caracteristică este integrarea DoH ca transport general care poate fi folosit nu numai pentru a gestiona cererile clientului către solutor, ci și atunci când se comunică între servere, când se transferă zone de către un server DNS autorizat și când se procesează orice interogări acceptate de alte DNS. transporturi.
Printre deficiențele care pot fi compensate prin dezactivarea build-ului cu DoH/DoT sau prin mutarea criptării pe alt server, iese în evidență complicația generală a bazei de cod - se adaugă un server HTTP încorporat și o bibliotecă TLS, care ar putea conține vulnerabilități. și acționează ca vectori de atac suplimentari. De asemenea, atunci când utilizați DoH, traficul crește.
Vă reamintim că DNS-over-HTTPS poate fi util pentru prevenirea scurgerilor de informații despre numele de gazdă solicitate prin serverele DNS ale furnizorilor, combaterea atacurilor MITM și a substituției traficului DNS (de exemplu, la conectarea la Wi-Fi public) și rezistența la blocarea la nivel DNS (DNS-over-HTTPS nu poate înlocui VPN în domeniul ocolirii blocării implementate la nivel DPI) sau pentru organizarea muncii în cazurile în care accesul direct la serverele DNS este imposibil (de exemplu, atunci când se lucrează printr-un proxy). În timp ce într-o situație normală, interogările DNS sunt trimise direct către serverele DNS definite în configurația sistemului, în cazul DNS-over-HTTPS, cererea de determinare adrese IP Gazda este încapsulată în trafic HTTPS și trimisă către un server HTTP, unde resolver-ul procesează cererile prin intermediul API-ului Web.
„DNS over TLS” diferă de „DNS over HTTPS” prin utilizarea protocolului DNS standard (de obicei se folosește portul de rețea 853), ambalat într-un canal de comunicare criptat organizat folosind protocolul TLS cu verificarea validității gazdei prin certificate TLS/SSL certificate de către o autoritate de certificare. Standardul DNSSEC existent folosește criptarea doar pentru a autentifica clientul și serverul, dar nu protejează traficul de interceptări și nu garantează confidențialitatea solicitărilor.
Alte inovații:
- S-au adăugat setările tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer și udp-send-buffer pentru a seta dimensiunile bufferelor utilizate la trimiterea și primirea cererilor prin TCP și UDP. Pe serverele ocupate, creșterea bufferelor de intrare va ajuta la evitarea pierderii pachetelor în timpul vârfurilor de trafic, iar scăderea acestora va ajuta să scăpați de înfundarea memoriei cu cererile vechi.
- A fost adăugată o nouă categorie de jurnal „rpz-passthru”, care vă permite să înregistrați separat acțiunile de redirecționare RPZ (zone de politică de răspuns).
- În secțiunea răspuns-politică, a fost adăugată opțiunea „nsdname-wait-recurse”, când este setată la „nu”, regulile RPZ NSDNAME sunt aplicate numai dacă serverele de nume autorizate prezente în cache sunt găsite pentru cerere, în caz contrar, Regula RPZ NSDNAME este ignorată, dar informațiile sunt preluate în fundal și se aplică solicitărilor ulterioare.
- Pentru înregistrările cu tipuri HTTPS și SVCB, a fost implementată procesarea secțiunii „SUPLIMENTARE”.
- S-au adăugat tipuri personalizate de reguli de politică de actualizare - krb5-subdomain-self-rhs și ms-subdomain-self-rhs, care vă permit să limitați actualizarea înregistrărilor SRV și PTR. Blocurile de actualizare-politică adaugă, de asemenea, capacitatea de a stabili limite pentru numărul de înregistrări, individuale pentru fiecare tip.
- S-au adăugat informații despre protocolul de transport (UDP, TCP, TLS, HTTPS) și prefixele DNS64 la ieșirea utilitarului dig. În scopuri de depanare, dig a adăugat posibilitatea de a specifica un anumit identificator de cerere (dig +qid= ).
- S-a adăugat suport pentru biblioteca OpenSSL 3.0.
- Pentru a rezolva problemele legate de fragmentarea IP la procesarea mesajelor DNS mari identificate de DNS Flag Day 2020, codul care ajustează dimensiunea bufferului EDNS atunci când nu există niciun răspuns la o solicitare a fost eliminat din soluție. Dimensiunea buffer-ului EDNS este acum setată la constantă (edns-udp-size) pentru toate cererile trimise.
- Sistemul de compilare a fost trecut la utilizarea unei combinații de autoconf, automake și libtool.
- Suportul pentru fișierele de zonă în formatul „hartă” (hartă în format masterfile) a fost întrerupt. Utilizatorilor acestui format li se recomandă să convertească zonele în format brut folosind utilitarul named-compilezone.
- Suportul pentru driverele DLZ (Zone cu încărcare dinamică) mai vechi a fost întrerupt, înlocuit cu module DLZ.
- Asistența pentru compilare și rulare a platformei a fost întreruptă. WindowsUltima ramură care poate fi instalată în Windows, BIND 9.16 rămâne.
Sursa: opennet.ru
