Firefox Programistoj pri la kompletigo de testa subteno por DNS super HTTPS (DoH, DNS super HTTPS) kaj la intenco ebligi ĉi tiun teknologion defaŭlte por usonaj uzantoj fine de septembro. La aktivigo efektiviĝos iom post iom, komence por kelkaj procentoj de uzantoj, kaj se ne estas problemoj, iom post iom pliiĝos al 100%. Post kiam Usono estas kovrita, DoH estos konsiderata por inkludo en aliaj landoj.
Provoj faritaj dum la tuta jaro montris la fidindecon kaj bonan rendimenton de la servo, kaj ankaŭ ebligis identigi iujn situaciojn, kie DoH povas konduki al problemoj kaj evoluigi solvojn por eviti ilin (ekzemple malmuntitaj). kun trafika optimumigo en enhavo-liveraj retoj, gepatraj kontroloj kaj kompaniaj internaj DNS-zonoj).
La graveco de ĉifrado de DNS-trafiko estas taksita kiel esence grava faktoro por protekti uzantojn, do estis decidite ebligi DoH defaŭlte, sed en la unua etapo nur por uzantoj de Usono. Post aktivigo de DoH, la uzanto ricevos averton, kiu permesos, se ĝi deziras, rifuzi kontakti centralizitajn DNS-servilojn de DoH kaj reveni al la tradicia skemo sendi neĉifritajn petojn al la DNS-servilo de la provizanto (anstataŭ distribuita infrastrukturo de DNS-solviloj, DoH uzas ligadon al specifa DoH-servo, kiu povas esti konsiderita ununura punkto de fiasko).
Se DoH estas aktivigita, gepatra kontrolo-sistemoj kaj entreprenaj retoj kiuj uzas la internan retan nuran DNS-nomstrukturon por solvi intraretajn adresojn kaj kompaniajn gastigantojn povas esti interrompitaj. Por solvi problemojn kun tiaj sistemoj, sistemo de kontroloj estis aldonita, kiu aŭtomate malŝaltas DoH. Kontroloj estas faritaj ĉiufoje kiam la retumilo estas lanĉita aŭ kiam subreta ŝanĝo estas detektita.
Aŭtomata reveno al uzado de la norma operaciuma solvilo ankaŭ estas disponigita se fiaskoj okazas dum rezolucio per DoH (ekzemple, se rethavebleco kun la DoH-provizanto estas interrompita aŭ fiaskoj okazas en ĝia infrastrukturo). La signifo de tiaj kontroloj estas dubinda, ĉar neniu malhelpas atakantojn, kiuj kontrolas la funkciadon de la solvilo aŭ kapablas malhelpi trafikon simulado de simila konduto por malŝalti ĉifradon de DNS-trafiko. La problemo estis solvita aldonante la eron "DoH ĉiam" al la agordoj (silente neaktiva), kiam ĝi estas agordita, aŭtomata ĉesigo ne estas aplikata, kio estas akceptebla kompromiso.
Por identigi entreprenajn solvantojn, maltipaj unuanivelaj domajnoj (TLDoj) estas kontrolitaj kaj la sistema solvilo resendas intraretajn adresojn. Por determini ĉu gepatra kontrolo estas ebligitaj, oni provos solvi la nomon exampleadultsite.com kaj se la rezulto ne kongruas kun la reala IP, oni konsideras, ke plenkreska enhavo-blokado estas aktiva ĉe la DNS-nivelo. IP-adresoj de Google kaj YouTube ankaŭ estas kontrolitaj kiel signoj por vidi ĉu ili estis anstataŭigitaj per restrict.youtube.com, forcesafesearch.google.com kaj restrictmoderate.youtube.com. Plia Mozilo efektivigi ununuran testan gastiganton , kiun ISP-oj kaj gepatra kontrolo-servoj povas uzi kiel flagon por malŝalti DoH (se la gastiganto ne estas detektita, Firefox malŝaltas DoH).
Labori tra ununura DoH-servo ankaŭ eble povas konduki al problemoj kun trafikoptimumigo en enhavliverretoj kiuj ekvilibrigas trafikon uzante DNS (la DNS-servilo de la CDN-reto generas respondon konsiderante la solvidan adreson kaj disponigas la plej proksiman gastiganton por ricevi la enhavon). Sendi DNS-demandon de la solvanto plej proksima al la uzanto en tiaj CDNoj rezultigas resendi la adreson de la gastiganto plej proksima al la uzanto, sed sendi DNS-demandon de alcentrigita solvilo resendos la mastro-adreson plej proksiman al la DNS-super-HTTPS-servilo. . Testado en praktiko montris, ke la uzo de DNS-over-HTTP dum uzado de CDN kaŭzis preskaŭ neniujn prokrastojn antaŭ la komenco de enhavtranslokigo (por rapidaj konektoj, prokrastoj ne superis 10 milisekundojn, kaj eĉ pli rapida rendimento estis observita sur malrapidaj komunikaj kanaloj. ). La uzo de la EDNS Client Subnet-etendaĵo ankaŭ estis konsiderita disponigi klientlokinformojn al la CDN-solvilo.
Memoru, ke DoH povas esti utila por malhelpi likojn de informoj pri la petitaj gastigantnomoj tra la DNS-serviloj de provizantoj, por kontraŭbatali MITM-atakojn kaj DNS-trafikon, por rezisti blokadon ĉe la DNS-nivelo, aŭ por organizi laboron en kazo de neebleco de rekta rekta. aliro al DNS-serviloj (ekzemple, kiam vi laboras per prokurilo). Dum en normala situacio DNS-petoj estas rekte senditaj al la DNS-serviloj difinitaj en la sistema agordo, en la kazo de DoH, la peto por determini la gastigantan IP-adreson estas enkapsuligita en HTTPS-trafiko kaj sendita al la HTTP-servilo, sur kiu la solvilo. prilaboras petojn per la Reta API. La nuna 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.
Por ebligi DoH en about:config, ŝanĝu la valoron de la variablo network.trr.mode, kiu estas subtenata ekde Firefox 60. Valoro de 0 malŝaltas DoH tute; 1 - DNS aŭ DoH estas uzata, kiu ajn estas pli rapida; 2 - DoH estas uzata defaŭlte, kaj DNS estas uzata kiel rezerva; 3 - nur DoH estas uzata; 4 - spegula reĝimo en kiu DoH kaj DNS estas uzataj paralele. La DNS-servilo de CloudFlare estas uzata defaŭlte, sed ĝi povas esti ŝanĝita per la parametro network.trr.uri, ekzemple, vi povas agordi "https://dns.google.com/experimental" aŭ "https://9.9.9.9". /dns-demando ".
fonto: opennet.ru