Firefox Programistoj pri ebligo de DNS super HTTPS (DoH, DNS super HTTPS) defaŭlte por usonaj uzantoj. Ĉifrado de DNS-trafiko estas konsiderata esence grava faktoro por protekti uzantojn. Ekde hodiaŭ, ĉiuj novaj instalaĵoj de usonaj uzantoj havos DoH ebligita defaŭlte. Ekzistantaj usonaj uzantoj estas planitaj por esti ŝanĝitaj al DoH ene de kelkaj semajnoj. En Eŭropa Unio kaj aliaj landoj, aktivigu DoH defaŭlte nuntempe .
Post aktivigo de DoH, averto montriĝas al la uzanto, kio permesas, se ĝi deziras, rifuzi kontakti centralizitajn DNS-servilojn de DoH kaj reveni al la tradicia skemo sendi neĉifritajn demandojn 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. Nuntempe, laboro estas ofertita per du DNS-provizantoj - CloudFlare (defaŭlte) kaj .
Ŝanĝu provizanton aŭ malŝaltu DoH en la agordoj de retkonekto. Ekzemple, vi povas specifi alternativan DoH-servilon "https://dns.google/dns-query" por aliri Google-servilojn, "https://dns.quad9.net/dns-query" - Quad9 kaj "https:/ /doh .opendns.com/dns-query" - OpenDNS. About:config ankaŭ provizas la agordon network.trr.mode, per kiu vi povas ŝanĝi la operaciumon de DoH: valoro de 0 tute malŝaltas DoH; 1 - DNS aŭ DoH estas uzata, kiu ajn estas pli rapida; 2 - DoH estas uzata defaŭlte, kaj DNS estas uzata kiel rezerva opcio; 3 - nur DoH estas uzata; 4 - spegula reĝimo en kiu DoH kaj DNS estas uzataj paralele.
Ni rememoru, ke DoH povas esti utila por malhelpi likojn de informoj pri la petitaj gastigantnomoj tra la DNS-serviloj de provizantoj, kontraŭbatali MITM-atakojn kaj DNS-trafikan falsigon (ekzemple, kiam li konektas al publika Wi-Fi), kontraŭbatali blokadon ĉe la DNS. nivelo (DoH ne povas anstataŭigi VPN en la areo de preterpasi blokadon efektivigita ĉe la DPI-nivelo) aŭ por organizado de laboro se 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 DoH, la peto por determini la IP-adreson de la gastiganto estas enkapsuligita en HTTPS-trafiko kaj sendita al la HTTP-servilo, kie la solvilo procesas. petoj per la Reta API. 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.
Por elekti la DoH-provizantojn proponitajn en Firefox, al fidindaj DNS-solvintoj, laŭ kiuj la DNS-funkciigisto povas uzi la datumojn ricevitajn por rezolucio nur por certigi la funkciadon de la servo, ne devas konservi ŝtipojn dum pli ol 24 horoj, ne povas transdoni datumojn al triaj kaj devas malkaŝi informojn pri metodoj de prilaborado de datumoj. La servo ankaŭ devas konsenti ne cenzuri, filtri, malhelpi aŭ bloki DNS-trafikon, krom en situacioj antaŭviditaj de leĝo.
DoH devas esti uzata singarde. Ekzemple, en la Rusa Federacio, IP-adresoj 104.16.248.249 kaj 104.16.249.249 asociitaj kun la defaŭlta DoH-servilo mozilla.cloudflare-dns.com ofertita en Firefox, в laŭ peto de la Stavropola tribunalo de la 10.06.2013.
DoH ankaŭ povas kaŭzi problemojn en areoj kiel gepatra kontrolo-sistemoj, aliro al internaj nomspacoj en kompaniaj sistemoj, elekto de itineroj en enhavaj liveraj optimumigo-sistemoj kaj plenumo de juĝaj ordonoj en la areo de kontraŭbatalado de la distribuado de kontraŭleĝa enhavo kaj ekspluatado de. neplenaĝuloj. Por eviti tiajn problemojn, kontrolsistemo estis efektivigita kaj testita, kiu aŭtomate malŝaltas DoH sub certaj kondiĉoj.
Por identigi entreprenajn solvantojn, maltipaj unuanivelaj domajnoj (TLDoj) estas kontrolitaj kaj la sistema solvilo resendas intraretajn adresojn. Por determini ĉu gepatraj kontroloj 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 Guglo kaj Jutubo ankaŭ estas kontrolitaj kiel signoj por vidi ĉu ili estis anstataŭigitaj per restrict.youtube.com, forcesafesearch.google.com kaj restrictmoderate.youtube.com. Ĉi tiuj kontroloj permesas atakantojn, kiuj kontrolas la funkciadon de la solvanto aŭ kapablas enmiksiĝi kun trafiko, simuli tian konduton por malŝalti ĉifradon de DNS-trafiko.
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.
fonto: opennet.ru