DNS HTTPS-i kaudu: mis see on ja kuidas see teie päringuid kaitseb

Alfa juhend » IT » DNS HTTPS-i kaudu: mis see on ja kuidas see teie päringuid kaitseb

Veebiaadressi sisestamisel töötab kulisside taga komponent, mis tagab õigele saidile jõudmise: domeeninimede süsteem (DNS). DNS tõlgib kergesti meeldejäävad nimed IP-aadressideks , millest arvutid aru saavad. See on mugav, jah, aga aastaid toimis see olulise haavatavusega: need päringud edastati krüpteerimata kujul. Seetõttu on HTTPS-i kaudu toimiv DNS, tuntud ka kui DoH, muutunud nii silmapaistvaks – see on täiendav kaitsekiht, mis raskendab teie internetiteenuse pakkujal jälgida, milliseid domeene te külastate.

Oluline on kohe alguses üks asi selgeks teha: DoH parandab DNS-päringute privaatsust, kuid see ei ole VPN ega muuda kogu teie ühendust salajaseks tunneliks . Selles artiklis uurime täpselt, mis see on, miks see on populaarseks muutunud, kuidas seda Chrome'is, Edge'is ja Firefoxis aktiveerida, selle eeliseid ja puudusi, kuidas see erineb TLS-i ja VPN-i kaudu DNS-ist ning selle tehniliste ja praktiliste piirangute ulatust.

Mis on DNS ja miks traditsiooniline süsteem selleks otstarbeks ei sobi?

DNS-serverid on üks neist komponentidest, mida peaaegu keegi ei vaata, kuid ometi on need suure osa veebisirvimise aluseks. Nende ülesanne on siduda domeeninimi vastava serveri IP-aadressiga . Veebisaiti külastades ei saa teie arvuti tähtedest aru: see vajab IP-aadressi, et teada, millise masinaga ühendust luua. Paljudel ruuteritel on internetiteenuse pakkuja poolt juba konfigureeritud DNS-serverid, mis muudab protsessi mugavaks, kuigi see jätab ka nähtava jälje selle infrastruktuuri haldaja kohta.

Põhiprobleem seisneb selles, et traditsioonilised DNS-päringud tehakse lihttekstina ja ilma kaitseta . See avab ukse pealtkuulamisele, vahemehe rünnakutele ja vastuste manipuleerimisele. Internetiteenuse pakkuja saab teada, milliseid domeene ja millal te päringu esitate; jagatud võrgus olev ründaja saab proovida päringut pealt kuulata ja petturliku vastuse tagastada. Seda tehnikat nimetatakse DNS-i kaaperdamiseks ja see võib teid lõpuks viia võltsitud lehele, soovimatule reklaamile või saidile, mis on loodud andmete varastamiseks. Valitsused ja internetiteenuse pakkujad on neid nõrkusi ajalooliselt ära kasutanud ka tsensuuri rakendamiseks, domeenide blokeerimiseks või lisareklaami kuvamiseks.

• Passiivne kuulamine: Keegi jälgib päringuid ja järeldab, milliseid teenuseid või veebisaite te sageli külastate.
• Mees keskel: Side pealt kuulatakse ja vastust muudetakse serveri jäljendamiseks.
• Blokeerimine ja filtreerimine: See takistab teatud domeenide eraldamist, et kontrollida juurdepääsu sisule.

DNS HTTPS-i kaudu: krüpteerige päring, et see poleks kõigile nähtav.

DNS HTTPS-i kaudu ehk DoH on lahendus, mis kasutab HTTPS-protokolli DNS-päringute ja -vastuste krüptitud kujul edastamiseks . Selge DNS-päringu saatmise asemel kapseldab seade selle turvalisse ühendusse, kasutades tavaliselt porti 443, sama porti, mida kasutavad turvalised veebisaidid. See kaitseb nii päringut kui ka vastust, takistades välisel vaatlejal neid hõlpsalt lugeda.

Selle toimimiseks peab päringule vastav DNS-server toetama ka domeenipõhist DNS-i (DoH ). Ainult brauseris valiku lubamisest ei piisa: valitud lahendaja peab sellele standardile vastama. Spetsifikatsioon on pidevalt arenenud ja seda peetakse endiselt arenevaks tehnoloogiaks, kuigi alates 2018. aastast on ettevõtted nagu Google ja Mozilla Foundation seda testinud ja integreerinud. Lisaks privaatsuse parandamisele näitavad testid, et DoH võib vähendada latentsust ja muuta päringud kiiremaks, kuna pole alati vaja lahendada kogu domeeni, vaid ainult minimaalset vajalikku osa.

DoH eelised: rohkem privaatsust, vähem manipuleerimist ja parem jõudlus

Kõige ilmsemaks eeliseks on turvalisus. Kuna DNS-päringud edastatakse krüpteeritult, on neid palju raskem jälgida või muuta . See raskendab vahemehe rünnakuid, vähendab avalike WiFi-võrkude haavatavust ja takistab kohalikul operaatoril selgelt näha, milliseid domeene te taotlete. Kuna DoH liiklus kasutab porti 443, sulandub see teiste HTTPS-ühendustega ja seda on raske tavalisest veebikülastusest eristada.

Samuti on jõudlusega seotud põhjuseid. DoH võib vähendada latentsust ja kiirendada DNS-kommunikatsiooni tänu muudatustele nimede lahendamises ja vahemälu paremale kasutamisele. Näiteks on mõnede API-de GET-meetod loodud tõhusamaks vahemällu salvestamiseks. Praktikas võib see tähendada veidi kiiremat sirvimist, kuigi see pole imerohi ja erinevus pole alati märgatav. Lisaks, kuna see on brauseris rakendatud, ei pea kasutaja ootama, kuni internetiteenuse pakkuja selle aktiveerib.

Puudused ja vaidlused: kui krüpteerimine elu keerulisemaks teeb

Mitte kõik ei suhtu domeenipõhisesse krüptimisse (DoH) soodsalt. Sama krüptimine, mis kaitseb kasutajat, muudab ka võrgu jälgimise keerulisemaks . Paljud vanemliku kontrolli programmid tuginevad DNS-päringute kontrollimisele, et teha kindlaks, millistele veebisaitidele lapsed üritavad ligi pääseda; DoH puhul muutub see ülesanne palju keerulisemaks ja võib isegi võimatuks. Sarnane olukord on ka ettevõtte võrguadministraatoritel, kes kaotavad nähtavuse päringuga hõlmatud domeenide üle ja ei saa teatud reegleid sama lihtsalt jõustada.

Internetipakkujad kaotavad ka võimaluse jälgida juurdepääsu ja blokeerida teatud domeene institutsiooni palvel. See tekitab õigustatud arutelu: mõned näevad seda privaatsuse võiduna, teised aga kontrolli- ja haldusprobleemina . DoT puhul kritiseeritakse seda ka oma äratuntava pordi kasutamise pärast, mis võimaldab DNS-päringuid tuvastada isegi teadmata täpselt, mida küsitakse. DoH väldib seda selget signaali, maskeerudes HTTPS-liikluse sisse, kuid vastutasuks jääb võrguadministraatoritele vähem tööriistu oma suhtluse haldamiseks.

Kuidas lubada DoH Chrome'is, Edge'is ja Firefoxis

Domeeninimede süsteemi (DNS) lubamine tänapäevases brauseris on tavaliselt lihtne, eriti kui see põhineb Chromiumil või Firefoxil. See valik on olemas, kuigi mõnel juhul on see peidetud täpsemate seadete menüüdesse . Enne millegi muutmist on oluline mõista, et brauser kaitseb ainult oma päringuid: teised seadme rakendused võivad jätkata erineva DNS-süsteemi kasutamist, kui see pole samuti süsteemitasandil konfigureeritud.

Google Chrome

Chrome'is on kiireim viis tippida chrome://flags/#dns-over-https aadressiribal. See viib teid otse Chrome'i lippude või eksperimentaalsete funktsioonide juurde.Näete valitud valikut nimega Turvalised DNS-otsingud; klõpsake rippmenüül nimega Vaikimisi ja valige Lubatud. Seejärel peate muudatuse jõustumiseks brauseri taaskäivitama.

Microsoft Edge

Chromiumi-põhises Edge'is on protsess praktiliselt identne. Ava brauser ja kirjuta edge://flags/#dns-over-https otsinguribalSisestades Edge'i lipud, ilmub sama turvalise DNS-i otsingu valik. Muutke vaikesäte väärtuseks Enabled ja taaskäivitage brauser, kui seda küsitakse.

Mozilla Firefox

Firefoxis ei pea te lippe avama. Klõpsake paremas ülanurgas menüünupul ja valige Valikud . Kerige jaotises Üldine alla ja klõpsake nuppu Võrgusätted. Avanevas aknas märkige ruut „Luba DNS HTTPS-i kaudu”. Seejärel saate HTTPS-i kaudu krüptimiseks valida pakkujate, näiteks Cloudflare ja NextDNS, hulgast.

DNS TLS-i kaudu (DoT): teine ​​krüpteeritud tee

TLS-i kaudu edastatav DNS ehk DoT on veel üks viis DNS-päringute kaitsmiseks. HTTPS-i asemel kasutab see TLS-i TCP-ühenduse ja standardiseeritud pordi 853 kaudu. TLS on sama turvalisuse alus mis HTTPS-il, seega on idee sarnane: luua krüpteeritud tunnel, kus ainult kaks osalejat saavad teavet dekrüpteerida ja töödelda. See muudab vahemehe rünnakud raskemaks ja takistab kolmandal osapoolel päringu lugemist või manipuleerimist.

DotT-l on oma eelised, eriti võrreldes traditsioonilise DNS-iga, mis ei paku turvameetmeid. Krüptimine takistab küberkurjategijatel päringute pealtkuulamist ja takistab ka teatud tsensuurimeetmeid . See nõuab aga nii kliendi kui ka serveri ühilduvust. Mitmed pakkujad pakuvad ühilduvaid servereid, kuid selle kasutamine laua- või sülearvutil nõuab tavaliselt täiendava tarkvara installimist; tänapäeva Androidis on see vähemalt alates Android 9-st juba integreeritud. Lahendused on olemas nii Windowsi kui ka Linuxi jaoks, kuigi need pole alati nii läbipaistvad, kui võiks soovida.

Puuduste hulgas kritiseerivad paljud andmekaitseeksperdid DoT-d ühe äratuntava pordi kasutamise pärast. Kuigi on võimatu teada, millisele veebisaidile ligi pääsetakse, on DNS-liiklust võimalik tuvastada . Mõne võrguadministraatori jaoks on see kasulik, kuna see võimaldab neil toimuvast ülevaadet saada; teiste jaoks on see signaal, mida nad pigem varjaksid. Lisaks pole DoT veel nii laialt levinud kui traditsiooniline DNS ja selle serveripoolne kasutuselevõtt on piiratud. On mure, et mõned ettevõtted koondavad üha enam DNS-päringuid, mis võib luua omamoodi rahvusvahelise monopoli.

DoH vs. DoT: kaks viisi sama asja kaitsmiseks

Peamine erinevus DoH ja DoT vahel seisneb pordis ja liikluse varjamises. DoT kasutab oma porti 853, samas kui DoH kasutab 443 ja sulandub tavaliste HTTPS-ühendustega . See pealtnäha väike erinevus on tekitanud märkimisväärset vaidlust. Privaatsuse seisukohast on DNS-päringute eristamatus muust liiklusest eeliseks: kui neid ei tuvastata, ei saa neid nii lihtsalt manipuleerida. Võrguhalduse seisukohast aga kaob kontroll ja turva- või filtreerimispoliitikate rakendamine muutub keerulisemaks.

Selle tuumaks on kaks visiooni. DoT taga on IETF, konsortsium, mis arendab paljusid internetistandardeid, samas kui Google ja Mozilla Foundation on DoH-d tugevalt propageerinud. Need ei ole vastandlikud tehnoloogiad, kuid esindavad erinevaid viise privaatsuse, võrgu nähtavuse ja vahendajate rolli mõistmiseks. Valik ühe ja teise vahel sõltub sellest, mida on vaja kaitsta ja kes peab võrku haldama.

DoH vs. VPN: see kaitseb küsimust, mitte kogu teekonda

DoH ja VPN tulevad privaatsust puudutavates vestlustes sageli jutuks, kuid nende eesmärk ei ole sama. DoH kaitseb nimepäringut; VPN kaitseb teie andmete liikumisteed . Lihtsaim viis selle mõistmiseks on mõelda, et DoH paneb tundliku küsimuse suletud ümbrikusse, samas kui VPN laseb kogu teekonna enne avalikule teele naasmist läbi privaatse tunneli. Mõlemad võivad privaatsust parandada, kuid ainult üks on loodud telefonide, tahvelarvutite ja arvutite liikluse terviklikuks katmiseks.

Mida teeb DNS enne saidi laadimist?

Enne kui brauser saab veebisaidi laadida, peab teie seade teadma selle asukohta. DNS töötab nagu telefoniraamat, tõlgides veebisaidi nime IP-aadressiks . See juhtub pidevalt: kui avate lehe, käivitate rakenduse, värskendate oma e-posti või esitate videot. Enamasti toimub see vaikselt ja te ei märka seda, mis on mugav, kuid see muudab selle ka privaatsusprobleemina kergesti tähelepanuta jäetuks. Traditsioonilised DNS-päringud ei ole krüptitud, seega võivad teie internetiteenuse pakkuja, tööandja, kool, kohviku WiFi või hotellivõrk näha, millistele domeenidele teie seade üritab ligi pääseda. Nad ei näe HTTPS-lehe täielikku sisu, kuid saavad teie tegevusest üsna paljastava ülevaate.

DNS-päring ei paljasta kõiki vaadatud lehti ega kõike, mida vormile sisestate, kuid domeenide loend võib paljastada harjumusi, huvisid, töövahendeid, terviseuuringuid või finantsteenuseid . Seetõttu on krüptitud DNS-ist saanud kasulik privaatsusfunktsioon. See ei paljasta kõike, aga paljastab rohkem, kui paljud inimesed arvavad.

Mida DoH varjab ja mida see paljastab?

DoH saadab DNS-päringuid HTTPS-i kaudu, mis on sama krüpteeritud protokoll, mida kasutavad turvalised veebisaidid. Päring jätab teie seadme krüpteerituna ja jõuab lahendajani, mis toetab standardit . Avalikus WiFi-võrgus võib see võrguoperaatoril teie päringute kogemata lugemist raskendada. Kui teie internetiteenuse pakkuja haldab DNS-i, võib DoH lahendajale üleminek takistada neil neid päringuid tavapärasel viisil nägemast. Lisaks, kui võrk manipuleerib nimede lahendamise tulemustega, võib krüpteeritud DNS vähendada mõningaid manipuleerimise vorme.

Nüüd peidab DoH päringu, mitte kogu vestlust. See võib takistada mõnel vaatlejal domeeniotsingu selgelt nägemist, kuid see ei muuda kogu teie internetiühendust krüpteeritud tunneliks . Kui seade IP-aadressi teab, järgib ülejäänud ühendus oma tavapärast rada, välja arvatud juhul, kui mõni muu privaatsustööriist seda marsruuti muudab. DoH ei peida teie tegelikku IP-aadressi veebisaitide, rakenduste või teenuste eest, millega te ühenduse loote, ega jäta teid muljet nagu oleksite teises linnas või riigis. Kui logite kontole sisse, teab teenus, et see olete teie. Kui brauseril on küpsiseid, salvestatud seansse, reklaamiidentifikaatoreid või äratuntavat sõrmejälge, siis DoH neid signaale ei kustuta.

Samuti ei kaitse see iga rakendust, kui see pole süsteemitasandil konfigureeritud ja rakendus seda sätet austab. Üks brauser võib kasutada turvalist DNS-i, samal ajal kui teine ​​rakendus samas seadmes kasutab erinevat DNS-teed . Mõned rakendused haldavad oma võrku ja ei ole alati süsteemi või brauseri sätetega kooskõlas. Seetõttu võib DoH luua vale mulje täielikust kaitsest: see parandab DNS-päringute privaatsust, kuid ei kaitse failiedastust, sõnumside liiklust, videokõnesid, mänguühendusi, taustal sünkroonimist ega voogesitusrakendusi nii nagu VPN.

Mida VPN kaitseb ja mida mitte?

VPN kaitseb teie teekonna teistsugust osa. See loob teie seadme ja VPN-serveri vahele krüpteeritud tunneli, suunates teie internetiliikluse läbi selle serveri . Teie internetiteenuse pakkuja või kohalik WiFi-võrk näeb VPN-serveriga krüpteeritud ühendust, mitte selget vaadet igast saidist ja teenusest, millega te ühenduse loote. Lisaks muudab VPN avalikku IP-aadressi, mida veebisaidid ja rakendused näevad: teie kodu- või mobiilsideoperaatori IP-aadressi asemel näeb sihtkoht VPN-serveri IP-aadressi. See võib vähendada asukohapõhist jälgimist, aidata teil mööda minna mõnest Interneti-teenuse pakkuja profiilist ja muuta avaliku WiFi-võrgu kasutamise turvalisemaks.

Põhjalik VPN suudab kaitsta brausereid, voogedastusrakendusi, e-posti kliente, pilve varundustööriistu, sõnumsiderakendusi, mänge ja taustateenuseid. Õigesti konfigureerituna saab see suunata DNS-päringuid ka krüpteeritud tunneli kaudu , mistõttu on hea mõte käivitada DNS-lekke test. Siiski pole VPN maagia. Kui logite sisse sotsiaalvõrgustikku, e-posti kontole, voogedastusteenusesse või veebipoodi, teab see teenus ikkagi, kes te olete. See võib teie algse IP-aadressi peita, kuid see ei anonüümi teie sisselogimist. Sama kehtib kõige kohta, mida otse saadate: teie nimi, e-posti aadress, makseandmed, saatmisaadress, fotod või sõnumid.

Küpsised ja brauseri sõrmejälgede võtmine on endiselt olulised. Rakendused võivad tekitada sarnaseid probleeme reklaamiidentifikaatorite, lubade, asukohale juurdepääsu, Bluetoothi ​​skannimise, lähedalasuvate WiFi-võrkude nimede ja skannimistööriistade kaudu. Pahavara on veel üks keeruline takistus, kuna see suudab andmeid jäädvustada enne, kui need VPN-tunnelisse jõuavad . Lühidalt öeldes peidab ja krüpteerib VPN palju tegevust, kuid see ei varja iga digitaalset sõrmejälge.

DoH-d ja VPN-i saab kasutada samaaegselt

Jah, neid saab kombineerida, kuid ideaalne seadistus sõltub sellest, kuidas seade, brauser ja VPN-i rakendus DNS-i haldavad. Paljudel juhtudel on lihtsaim lahendus lasta VPN-il DNS-i hallata . Hea rakendus peaks saatma DNS-päringuid krüpteeritud tunneli kaudu, et teie internetiteenuse pakkuja neid otse ei saaks. Nii saate VPN-ühenduse osana DNS-i privaatsuse ilma, et peaksite oma brauseri seadeid eraldi muutma.

Probleem tekib siis, kui brauser kasutab oma domeeniautoriteedi (DoH) konfiguratsiooni, samal ajal kui VPN üritab DNS-i süsteemitasandil hallata. Midagi ei pruugi katki minna, kuid segadus tekib : võite arvata, et kõik päringud läbivad VPN-i, kuid tegelikkuses saadab brauser osa neist ise teisele lahendajale. Siin tuleb kasuks DNS-i lekketest. Kui pärast VPN-iga ühenduse loomist näete oma internetiteenuse pakkuja DNS-servereid, ei tööta midagi ootuspäraselt; kui näete VPN-iga seotud servereid, töötab konfiguratsioon tõenäolisemalt õigesti.

Millal on DoH piisav ja millal on VPN soovitatav?

Turvalise DNS-i lubamisest võib piisata, kui teie peamine mure on teie brauseri DNS-päringute privaatsus. Usaldusväärses koduvõrgus vähendab turvalise DNS-i lubamine lihtteksti nähtavust ilma, et peaksite oma asukohta muutma või kõiki oma rakendusi turvama . See on kasulik ka võrkudes, kus DNS-i filtreerimine või manipuleerimine on probleemiks, sest HTTPS-i kaudu liikumine muudab selle hõlpsa kontrollimise või muutmise keerulisemaks. See ei tähenda, et see möödub kõigist piirangutest või on tsensuurikindel, kuid see on märkimisväärne edasiminek võrreldes krüpteerimata DNS-iga. Lisaks on see kerge: te ei pea valima VPN-serverit ega oma marsruutimist oluliselt muutma ning tavaliselt ei märka te kiirusele olulist mõju.

VPN on kõige mõistlikum siis, kui soovite kaitset kogu seadmele, mitte ainult DNS-päringuid. See hõlmab lennujaamu, hotelle, koole, ühistööruume, kohvikuid ja üürimajutusi . Jagatud võrkudes ei tea te, kes ruuterit kontrollib, kes veel on ühendatud või kas keegi üritab liiklust pealt kuulata. VPN on abiks ka siis, kui te ei soovi, et teie internetiteenuse pakkuja teie sirvimismustrite profiili looks: kuigi HTTPS kaitseb lehtede sisu, võivad võrgu metaandmed siiski paljastada kasulikke mustreid. Reisimine on veel üks selge näide: VPN võib muuta teie ühenduse järjepidevamaks, kaitsta teid tundmatutes võrkudes ja panna veebisaidid nägema VPN-serveri asukohta teie ajutise kohaliku ühenduse asemel.

Google'i avaliku DNS-i DoH API-de tehnilised üksikasjad

Google'i avalik DNS pakub kahte erinevat DoH API-t. Üks on loodud RFC 8484 jaoks ja aktsepteerib GET- ja POST-päringuid aadressil https://dns.google/dns-query; teine ​​on JSON API, mis toetab ainult GET-päringuid aadressil https://dns.google/resolve . Samuti on aadressil https://dns.google/ veebiliides, mis kuvab brauseris JSON-tulemusi, kuid see ei rakenda täielikku API-t. Seda liidest ei tohiks segi ajada API URL-ide ega https://dns.google/query-ga. Teenus ei toeta turvamata HTTP URL-e ja DoH-d toetab ka Google'i avalik DNS64 teenus, kuigi sel juhul toetatakse ainult IPv6-d. Google'i turvalise transpordi dokumentatsioon sisaldab curl-näiteid ja üksikasju TLS-i, DoT-i ja DoH kohta.

Saadaval olevad HTTP-meetodid

GET-meetod aitab latentsust vähendada, kuna see vahemällu salvestab tõhusamalt. RFC 8484 GET-päringud peavad sisaldama parameetrit `?dns=` koos Base64Url-kodeeringuga DNS-sõnumiga ning see on ainus meetod, mida JSON API toetab. POST-meetod on saadaval ainult RFC 8484-s ja kasutab binaarset DNS-sõnumit, mille nii päringu kui ka vastuse sisus on `application/dns-message`. HEAD-meetod pole praegu toetatud ja tagastab vea 400 Bad Request. Teised meetodid tagastavad vea 501 Not Implemented.

Olekukoodid ja vead

API tagastab mitu HTTP-koodi, mida tasub teada. 200 OK näitab, et HTTP parsimine ja DNS-i lahendajaga suhtlemine olid edukad ; vastuse sisu võib olla binaarne DNS-vastus või JSON, olenevalt lõpp-punktist, Accept päisest ja GET-parameetritest. Märkus: HTTP-viga võib olla ka DNS-i tõrge, seega on soovitatav kontrollida DNS-i vastusekoodi, näiteks JSON-i välja "Status", selliste vigade suhtes nagu SERVFAIL, FORMERR, REFUSED või NOTIMP.

• 301 Jäädavalt ümber paigutatud: Klient peab päringut uuesti proovima asukohas määratud URL-il. Kui algne päring oli POST, peaks see GET-iga uuesti proovima ainult siis, kui uus URL määrab DNS-parameetri; vastasel juhul peab see POST-iga korduma. Võivad ilmuda ka olekukoodid 302, 307 ja 308 ning DoH kliendid peavad kõiki nelja käsitlema. Püsivaid olekukoode 301 ja 308 saab vahemällu salvestada määramata ajaks. POST-päringuid, mis saavad olekukoodi 307 või 308, tuleb alati POST-iga uuesti proovida.
• 400 halb päring: Probleemid GET-parameetrite või sobimatu DNS-päringu sõnumi parsimisel. Enamik sobimatuid DNS-sõnumeid saab vastuseks FORMERR-i, kuid HTTP-vead esinevad loetamatute sõnumite puhul, millel puudub küsimuse osa, QR-kood, mis näitab vastust, või mõttetute koodikombinatsioonide korral.
• 413 Kasulik koormus on liiga suur: POST RFC 8484 päringu sisu ületab maksimaalse sõnumi suuruse 512 baiti.
• 414 URI on liiga pikk: GET-päringu päis oli liiga suur või DNS-parameeter ületas 512 baiti.
• 415 Toetamata meediatüüp: POST-i sisul puudus sisutüübi päis application/dns-message.
• 429 Liiga palju päringuid: Antud aja jooksul on saadetud liiga palju päringuid. Klient peab ootama päises „Retry-After” määratud ajani.
• 500i sisemise serveri viga: DoH teenuse sisemised vead.
• 501 Pole rakendatud: Ainult GET ja POST on rakendatud; ülejäänud tagastavad selle vea.
• 502 Vigane värav: DoH teenus ei suutnud Google'i avalike DNS-i lahendajatega suhelda. Teise aadressi proovimine võib toimida, kuid tõhusam varuplaan on proovida mõnda teist DoH teenust või lülituda traditsioonilisele DNS-ile, kasutades UDP-d või TCP-d aadressil 8.8.8.8.

Privaatsuse ja jõudluse parimad tavad

DoH rakenduste arendajad peaksid HTTP päiseid piirama. Päised nagu „Cookie”, „User-Agent” ja „Accept-Language” võivad paljastada teavet kliendi implementatsiooni kohta ja aidata kaasa deanonümiseerimisele . Soovitatav on saata ainult DoH jaoks vajalikud päised: Host, Content-Type (POST-päringute jaoks) ja vajadusel Accept. User-Agent päis tuleks lisada arendus- või testversioonidesse. Samuti on soovitatav kasutada EDNS-i täitevalikuid, et lühendada päringuid tavapäraste pikkusteni ja muuta liikluse analüüs keerulisemaks. HTTP/2 täitmine on võimalik, kuid erinevalt EDNS-i täitest ei genereeri see DoH serveri vastustes täiteid.

RFC 8484-s kirjeldatud POST-meetodit tuleks kasutada ainult privaatsust tundlikes rakendustes või brauserirežiimides. POST-meetodi kasutamine vähendab vahemälu mahtu ja võib suurendada latentsust, seega pole see üldiselt soovitatav . Vahemälu suuruse vähendamine võib aga olla soovitatav rakenduste jaoks, mis soovivad vältida veebirakenduste sünkroonimisrünnakuid, mille eesmärk on avastada, milliseid domeene kasutaja on hiljuti külastanud. HTTPS-lähenemisviisil on ka praktilisi eeliseid: HTTPS-i API-d on laialdaselt saadaval ja toetatud, mis lihtsustab rakendamist; HTTPS-teenus annab veebirakendustele juurdepääsu igat tüüpi DNS-kirjetele, vältides brauseri või operatsioonisüsteemi API-de piiranguid, mis tavaliselt piirduvad hosti-aadressi otsingutega; ja kliendid, kes rakendavad HTTPS-i UDP kaudu QUIC-iga, saavad vältida probleeme, nagu reapealkirja blokeerimine, mis tekivad TCP-ga. Kui teil tekib viga või soovite taotleda uut funktsiooni, peaksite DoH-ga seotud probleemist teatama tavapäraste kanalite kaudu.

Korduma kippuvad küsimused DoH ja VPN-i kohta

Üks sagedamini esitatavaid küsimusi on see, kas VPN-i kasutamise korral on mõttekas kasutada DoH-i. See on võimalik, kuid kõige praktilisem lähenemisviis on tavaliselt lasta VPN-il DNS-iga tegeleda ja lekketestiga kontrollida, kas päringud läbivad õigeid kanaleid. Kui brauser saadab oma päringuid ühte ja VPN teistpidi, võib teid oodata ebameeldiv üllatus.

Teine levinud küsimus on, kas DoH takistab teie internetiteenuse pakkujal nägemast, milliseid veebisaite te külastate. DoH peidab DNS-päringuid paljude vaatlejate eest, kuid see ei eemalda kõiki metaandmeid ega peida teie IP-aadressi : teie internetiteenuse pakkuja näeb endiselt, millistele IP-aadressidele te ühenduse loote ja muud võrguteavet. Laiema kaitse tagamiseks vajate VPN-i või mitme privaatsuskihi kombinatsiooni.

Samuti tasub küsida, kas DomainHost (DoH) on avalikus WiFi-võrgus piisav. See võib aidata takistada võrguoperaatoril teie DNS-päringute lihtsat lugemist, kuid see ei kaitse kogu ühendust ega kõigi rakenduste liiklust . Lennujaamades, hotellides ja kohvikutes on VPN-i kasutamine tavaliselt ulatuslikum, eriti kui te ei tea, kes ruuterit kontrollib või kas on ühendatud ka teisi inimesi.

Domeeninimede süsteem (DoH) ja VPN-id ei ole otsesed konkurendid, vaid pigem erinevate võimalustega tööriistad. DoH krüpteerib domeeniotsingu ja vähendab selle protsessi osa nähtavust; VPN krüpteerib tee teie seadme ja serveri vahel ning muudab sihtkohtadele nähtavat IP-aadressi . Kumbki ei tee teid nähtamatuks: kontod, küpsised, brauseri sõrmejäljed, rakenduste load, pahavara ja kõik otse jagatud andmed saavad teid ikkagi tuvastada. Kuid see ei tee neid kasutuks. See tähendab lihtsalt, et igal neist on oma roll. DoH kaitseb aadressiotsingut; VPN kaitseb palju suuremat osa teie andmete liikumisest.