La programistoj de la BIND DNS-servilo anoncis la aldonon de servila subteno por la DNS super HTTPS (DoH, DNS super HTTPS) kaj DNS super TLS (DoT, DNS super TLS) teknologioj, same kiel la mekanismon XFR-over-TLS por sekura. transdonante la enhavon de DNS-zonoj inter serviloj. DoH estas disponebla por testado en eldono 9.17, kaj DoT-subteno ĉeestas ekde eldono 9.17.10. Post stabiligo, DoT kaj DoH-subteno estos retroportita al la stabila 9.17.7-branĉo.
La efektivigo de la HTTP/2-protokolo uzata en DoH baziĝas sur la uzo de la nghttp2-biblioteko, kiu estas inkluzivita inter la asembleaj dependecoj (en la estonteco, la biblioteko estas planita esti transdonita al la nombro da laŭvolaj dependecoj). Ambaŭ ĉifritaj (TLS) kaj neĉifritaj HTTP/2-konektoj estas subtenataj. Kun la taŭgaj agordoj, ununura nomita procezo nun povas servi ne nur tradiciajn DNS-demandojn, sed ankaŭ demandojn senditajn per DoH (DNS-over-HTTPS) kaj DoT (DNS-over-TLS). HTTPS-subteno ĉe la klienta flanko (dig) ankoraŭ ne estas efektivigita. XFR-over-TLS-subteno disponeblas por kaj enirantaj kaj elirantaj petoj.
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 { key-file "/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;}; }
Inter la trajtoj de la DoH-efektivigo en BIND, integriĝo notiĝas kiel ĝenerala transporto, kiu povas esti uzata ne nur por prilabori klientpetojn al la solvanto, sed ankaŭ dum interŝanĝado de datumoj inter serviloj, dum transdono de zonoj per aŭtoritata DNS-servilo, kaj kiam vi prilaboras ajnajn petojn subtenatajn de aliaj DNS-transportoj.
Alia trajto estas la kapablo movi ĉifrajn operaciojn por TLS al alia servilo, kio povas esti necesa en kondiĉoj kie TLS-atestiloj estas stokitaj sur alia sistemo (ekzemple, en infrastrukturo kun retserviloj) kaj konservitaj fare de alia personaro. Subteno por neĉifrita DNS-over-HTTP estas efektivigita por simpligi sencimigon kaj kiel tavolo por plusendado en la interna reto, surbaze de kiu ĉifrado povas esti organizita sur alia servilo. Sur fora servilo, nginx povas esti uzata por generi TLS-trafikon, simile al kiel HTTPS-ligado estas organizita por retejoj.
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.
fonto: opennet.ru