DNS over HTTPS: Hvad det er, og hvordan det beskytter dine forespørgsler

Alfa-guide » Informática » DNS over HTTPS: Hvad det er, og hvordan det beskytter dine forespørgsler

Når du skriver en webadresse, er der en komponent, der arbejder bag kulisserne for at sikre, at du når det rigtige websted: Domain Name System (DNS). DNS oversætter let-at-huske navne til IP-adresser , som computere kan forstå. Det er praktisk, ja, men i årevis fungerede det med en betydelig sårbarhed: disse forespørgsler rejste ukrypteret. Derfor er DNS over HTTPS, også kendt som DoH, blevet så fremtrædende - et ekstra lag af beskyttelse, der gør det sværere for din internetudbyder at spore, hvilke domæner du besøger.

Det er vigtigt at præcisere én ting fra starten: DoH forbedrer privatlivets fred for DNS-forespørgsler, men det er ikke en VPN, og det forvandler heller ikke hele din forbindelse til en hemmelig tunnel . I denne artikel vil vi undersøge præcis, hvad det er, hvorfor det er blevet populært, hvordan man aktiverer det i Chrome, Edge og Firefox, dets fordele og ulemper, hvordan det adskiller sig fra DNS i forhold til TLS og en VPN, og omfanget af dets tekniske og praktiske begrænsninger.

Hvad er DNS, og hvorfor er det traditionelle system utilstrækkeligt?

DNS-servere er en af ​​de komponenter, som næsten ingen kigger på, men alligevel understøtter de en stor del af online browsing. Deres opgave er at forbinde et domænenavn til IP-adressen på den tilsvarende server . Når du besøger et websted, forstår din computer ikke bogstaver: den har brug for en IP-adresse for at vide, hvilken maskine den skal oprette forbindelse til. Mange routere leveres med DNS-servere, der allerede er konfigureret af internetudbyderen, hvilket gør processen praktisk, selvom det også efterlader et synligt spor for den, der kontrollerer denne infrastruktur.

Det underliggende problem er, at traditionelle DNS-forespørgsler foretages i almindelig tekst og uden beskyttelse . Dette åbner døren for aflytning, man-in-the-middle-angreb og manipulation af svaret. En internetudbyder kan lære, hvilke domæner du forespørger på, og hvornår; en angriber på et delt netværk kan forsøge at opsnappe anmodningen og returnere et svigagtigt svar. Denne teknik er kendt som DNS-kapring og kan i sidste ende føre dig til en falsk side, uønsket reklame eller et websted, der er designet til at stjæle data. Regeringer og internetudbydere har også historisk set udnyttet disse svagheder til at implementere censur, blokere domæner eller vise yderligere reklame.

• Passiv lytning: Nogen observerer forespørgslerne og udleder, hvilke tjenester eller websteder du hyppigt besøger.
• Mand-i-midten: Kommunikationen opfanges, og svaret ændres for at efterligne en server.
• Blokering og filtrering: Det forhindrer opløsningen af ​​bestemte domæner for at kontrollere adgangen til indhold.

DNS over HTTPS: Krypter forespørgslen, så den ikke er synlig for alle.

DNS over HTTPS, eller DoH, er en løsning, der udnytter HTTPS-protokollen til at transmittere DNS-forespørgsler og -svar i krypteret form . I stedet for at sende en klar DNS-anmodning, indkapsler enheden den i en sikker forbindelse, typisk ved hjælp af port 443, den samme port, der bruges af sikre websteder. Dette beskytter både forespørgslen og svaret og forhindrer en ekstern observatør i nemt at læse dem.

For at dette kan fungere, skal den DNS-server, der forespørges, også understøtte domænebaseret DNS (DoH ). Det er ikke nok blot at aktivere en indstilling i browseren: den valgte resolver skal overholde denne standard. Specifikationen har været under udvikling og betragtes stadig som en teknologi under udvikling, selvom virksomheder som Google og Mozilla Foundation har testet og integreret den siden 2018. Ud over forbedret privatliv viser tests, at DoH kan reducere latenstid og gøre forespørgsler hurtigere, fordi det ikke altid er nødvendigt at løse hele domænet, men kun den mindst nødvendige del.

Fordele ved DoH: mere privatliv, mindre manipulation og bedre ydeevne

Den mest åbenlyse fordel er sikkerhed. Fordi de sendes krypteret, er DNS-forespørgsler meget sværere at spionere på eller ændre . Dette komplicerer man-in-the-middle-angreb, reducerer eksponeringen på offentlige Wi-Fi-netværk og forhindrer en lokal operatør i tydeligt at se, hvilke domæner du anmoder om. Da DoH-trafik bruger port 443, blandes den med andre HTTPS-forbindelser og er vanskelig at skelne fra et normalt webbesøg.

Der er også årsager til ydeevnen. DoH kan reducere latenstid og fremskynde DNS-kommunikation takket være ændringer i, hvordan navne opløses, og bedre udnyttelse af cachen. For eksempel er GET-metoden i nogle API'er designet til at blive cachelagret mere effektivt. I praksis kan dette resultere i lidt hurtigere browsing, selvom det ikke er en magisk løsning, og forskellen er ikke altid mærkbar. Da den er implementeret i browseren, behøver brugeren desuden ikke at vente på, at deres internetudbyder aktiverer den.

Ulemper og debatter: når kryptering komplicerer livet

Ikke alle ser positivt på domænebaseret kryptering (DoH). Den samme kryptering, der beskytter brugeren, gør også netværksovervågning vanskeligere . Mange forældrekontrolprogrammer er afhængige af at inspicere DNS-forespørgsler for at bestemme, hvilke websteder børn forsøger at få adgang til; med DoH bliver denne opgave meget mere kompliceret og kan endda være umulig. En lignende situation gælder for virksomhedsnetværksadministratorer, som mister indsigt i de domæner, der forespørges på, og ikke kan håndhæve bestemte regler lige så let.

Internetudbydere mister også muligheden for at overvåge adgang og blokere specifikke domæner efter anmodning fra en institution. Dette skaber en legitim debat: Nogle ser det som en sejr for privatlivets fred, mens andre anser det for et kontrol- og administrationsproblem . I tilfældet med DoT kritiseres det også for at bruge sin egen genkendelige port, som muliggør identifikation af DNS-forespørgsler, selv uden at vide præcis, hvad der bliver spurgt om. DoH undgår dette klare signal ved at forklæde sig i HTTPS-trafik, men til gengæld har netværksadministratorer færre værktøjer til at styre deres kommunikation.

Sådan aktiverer du DoH i Chrome, Edge og Firefox

Det er normalt ligetil at aktivere Domain Name System (DNS) i en moderne browser, især hvis den er baseret på Chromium eller Firefox. Muligheden findes, selvom den i nogle tilfælde er skjult i avancerede indstillingsmenuer . Før du ændrer noget, er det vigtigt at forstå, at browseren kun beskytter sine egne forespørgsler: andre applikationer på enheden kan fortsætte med at bruge et andet DNS-system, hvis det ikke også er konfigureret på systemniveau.

Google Chrome

I Chrome er den hurtigste måde at skrive chrome://flags/#dns-over-https i adresselinjen. Det fører dig direkte til Chromes flag eller eksperimentelle funktioner.Du vil se en valgmulighed kaldet Sikre DNS-opslag valgt; klik på rullemenuen med teksten Standard, og vælg Aktiveret. Derefter skal du genstarte din browser for at ændringen kan træde i kraft.

Microsoft Edge

I Chromium-baserede Edge er processen stort set identisk. Åbn din browser og skriv edge://flags/#dns-over-https i søgefeltetDu indtaster Edges Flags, og den samme mulighed for sikker DNS-opslag vises. Skift standard til aktiveret, og genstart browseren, når du bliver bedt om det.

Mozilla Firefox

I Firefox behøver du ikke at gå til Flag. Klik på menuknappen i øverste højre hjørne, og vælg Indstillinger . I afsnittet Generelt skal du rulle ned til bunden og klikke på Netværksindstillinger. I det vindue, der åbnes, skal du markere feltet ud for Aktiver DNS over HTTPS. Du kan derefter vælge mellem udbydere som Cloudflare og NextDNS for at udføre kryptering over HTTPS.

DNS over TLS (DoT): den anden krypterede sti

DNS over TLS, eller DoT, er en anden måde at beskytte DNS-forespørgsler på. I stedet for at bruge HTTPS bruger den TLS over en TCP-forbindelse og en standardiseret port, 853. TLS er det samme sikkerhedsfundament som HTTPS, så ideen er den samme: at oprette en krypteret tunnel, hvor kun de to deltagere kan dekryptere og behandle informationen. Dette gør man-in-the-middle-angreb vanskeligere og forhindrer en tredjepart i at læse eller manipulere forespørgslen.

DotT har sine fordele, især sammenlignet med traditionel DNS, som ikke tilbyder nogen sikkerhedsforanstaltninger. Kryptering forhindrer cyberkriminelle i at opsnappe anmodninger og hindrer også visse censurforanstaltninger . Det kræver dog kompatibilitet fra både klienten og serveren. Flere udbydere tilbyder kompatible servere, men brug af det på en stationær eller bærbar computer kræver normalt installation af yderligere software; på moderne Android, i hvert fald siden Android 9, er det allerede integreret. Der findes løsninger til Windows og Linux, selvom de ikke altid er så gennemsigtige, som man måske ønsker.

Blandt ulemperne kritiserer mange databeskyttelseseksperter DoT for at bruge en enkelt, genkendelig port. Selvom det er umuligt at vide, hvilket websted der tilgås, er det muligt at registrere DNS-trafik . For nogle netværksadministratorer er dette nyttigt, fordi det giver dem mulighed for at bevare et overblik over, hvad der sker; for andre er det et signal, de hellere vil skjule. Desuden er DoT endnu ikke så udbredt som traditionel DNS, og dens serverside-adoption er begrænset. Der er bekymring for, at nogle få virksomheder i stigende grad vil koncentrere DNS-forespørgsler, hvilket potentielt skaber en slags internationalt monopol.

DoH vs. DoT: To måder at beskytte den samme ting på

Hovedforskellen mellem DoH og DoT ligger i porten og hvordan trafikken er skjult. DoT bruger sin egen port, 853, mens DoH bruger 443 og blander sig med normale HTTPS-forbindelser . Denne tilsyneladende lille forskel har udløst betydelig debat. Fra et privatlivsperspektiv er det en fordel, at DNS-forespørgsler ikke kan skelnes fra anden trafik: hvis de ikke genkendes, kan de ikke manipuleres lige så let. Fra et netværksadministrationsperspektiv mistes kontrollen dog, og det bliver vanskeligere at implementere sikkerheds- eller filtreringspolitikker.

I sin kerne er der to visioner. IETF, konsortiet der udvikler mange internetstandarder, står bag DoT , mens Google og Mozilla Foundation kraftigt har promoveret DoH. Disse er ikke modstridende teknologier, men de repræsenterer forskellige måder at forstå privatliv, netværkssynlighed og formidlernes rolle. Valget mellem den ene og den anden afhænger af, hvad der skal beskyttes, og hvem der skal administrere netværket.

DoH vs. en VPN: Det beskytter spørgsmålet, ikke hele rejsen

DoH og en VPN dukker ofte op i de samme samtaler om privatliv, men de gør ikke det samme. DoH beskytter navneforespørgslen; en VPN beskytter den vej, dine data tager . Den enkleste måde at forstå dette på er at forestille sig DoH, der lægger et følsomt spørgsmål i en lukket kuvert, mens en VPN sørger for, at hele rejsen går gennem en privat tunnel, før den vender tilbage til den offentlige vej. Begge kan forbedre privatlivets fred, men kun den ene er designet til omfattende at dække trafikken på telefoner, tablets og computere.

Hvad gør DNS, før en hjemmeside indlæses?

Før din browser kan indlæse et websted, skal din enhed kende dets placering. DNS fungerer som en telefonbog, der oversætter et webstedsnavn til en IP-adresse . Dette sker konstant: når du åbner en side, starter en app, opdaterer din e-mail eller afspiller en video. Det meste af tiden sker det lydløst, og du bemærker det ikke, hvilket er godt for bekvemmelighedens skyld, men det gør det også nemt at overse som et privatlivsproblem. Traditionelle DNS-forespørgsler er ikke krypterede, så din internetudbyder, din arbejdsgiver, din skole, en cafés Wi-Fi eller et hotelnetværk kan se, hvilke domæner din enhed forsøger at nå. De ser ikke det fulde indhold af en HTTPS-side, men de får en ret afslørende oversigt over din aktivitet.

En DNS-forespørgsel afslører ikke alle de sider, du har set, eller alt, hvad du skriver i en formular, men en liste over domæner kan afsløre vaner, interesser, arbejdsværktøjer, sundhedsforskning eller finansielle tjenester . Derfor er krypteret DNS blevet en nyttig privatlivsfunktion. Den afslører ikke alt, men den afslører mere, end mange mennesker er klar over.

Hvad skjuler DoH, og hvad afslører det?

DoH sender DNS-forespørgsler via HTTPS, den samme krypterede protokol, der bruges af sikre websteder. Anmodningen efterlader din enhed krypteret og ankommer til en resolver, der understøtter standarden . På offentlige Wi-Fi-netværk kan dette gøre det vanskeligt for netværksoperatøren utilsigtet at læse dine forespørgsler. Hvis din internetudbyder administrerer DNS, kan det at skifte til en DoH-resolver forhindre dem i at se disse forespørgsler på den sædvanlige måde. Desuden, hvis et netværk manipulerer resultaterne af navneopløsning, kan krypteret DNS reducere visse former for manipulation.

DoH skjuler nu forespørgslen, ikke hele samtalen. Det kan forhindre nogle observatører i tydeligt at se domæneopslaget, men det forvandler ikke hele din internetforbindelse til en krypteret tunnel . Når enheden kender IP-adressen, følger resten af ​​forbindelsen sin normale sti, medmindre et andet privatlivsværktøj ændrer denne rute. DoH skjuler ikke din rigtige IP-adresse fra de websteder, apps eller tjenester, du opretter forbindelse til, og det får dig heller ikke til at se ud som om, du befinder dig i en anden by eller et andet land. Hvis du logger ind på en konto, ved tjenesten, at det er dig. Hvis browseren har cookies, gemte sessioner, annonceringsidentifikatorer eller et genkendeligt fingeraftryk, sletter DoH ikke disse signaler.

Den beskytter heller ikke alle applikationer, medmindre de er konfigureret på systemniveau, og applikationen respekterer denne indstilling. Én browser kan bruge sikker DNS, mens en anden applikation på den samme enhed bruger en anden DNS-sti . Nogle apps administrerer deres eget netværk og stemmer ikke altid overens med system- eller browserindstillingerne. Derfor kan DoH skabe en falsk følelse af fuldstændig beskyttelse: den forbedrer privatlivets fred for DNS-forespørgsler, men den beskytter ikke filoverførsler, beskedtrafik, videoopkald, spilforbindelser, baggrundssynkronisering eller streamingapplikationer på samme måde som en VPN ville.

Hvad beskytter en VPN, og hvad kan den ikke skjule?

En VPN beskytter en anden del af din rejse. Den opretter en krypteret tunnel mellem din enhed og en VPN-server, der dirigerer din internettrafik gennem den server . Din internetudbyder eller dit lokale Wi-Fi-netværk ser en krypteret forbindelse til VPN-serveren, ikke et klart billede af alle websteder og tjenester, du opretter forbindelse til. Derudover ændrer VPN'en den offentlige IP-adresse, som websteder og apps ser: i stedet for din hjemme- eller mobiludbyders IP-adresse ser destinationen VPN-serverens IP-adresse. Dette kan reducere lokationsbaseret sporing, hjælpe dig med at omgå visse internetudbyderprofiler og gøre brugen af ​​offentlig Wi-Fi mere sikker.

En omfattende VPN kan beskytte browsere, streamingapps, e-mailklienter, cloud-backupværktøjer, beskedapps, spil og baggrundstjenester. Den kan også dirigere DNS-anmodninger gennem den krypterede tunnel, når den er korrekt konfigureret , og derfor er det en god idé at køre en DNS-lækagetest. Når det er sagt, er en VPN ikke magisk. Hvis du logger ind på et socialt netværk, en e-mailkonto, en streamingtjeneste eller en onlinebutik, ved den pågældende tjeneste stadig, hvem du er. Den kan skjule din oprindelige IP-adresse, men den anonymiserer ikke dit login. Det samme gælder for alt, hvad du sender direkte: dit navn, din e-mailadresse, dine betalingsoplysninger, din leveringsadresse, dine fotos eller dine beskeder.

Cookies og browserfingeraftryk spiller stadig en rolle. Apps kan skabe lignende problemer gennem reklameidentifikatorer, tilladelser, lokationsadgang, Bluetooth-scanning, Wi-Fi-navne i nærheden og scanningsværktøjer. Malware er en anden svær hindring, fordi den kan indsamle data, før den overhovedet når VPN-tunnelen . Kort sagt skjuler og krypterer en VPN en masse aktivitet, men den skjuler ikke alle digitale fingeraftryk.

DoH og en VPN kan bruges samtidigt

Ja, de kan kombineres, men den ideelle opsætning afhænger af, hvordan enheden, browseren og VPN-appen håndterer DNS. I mange tilfælde er den enkleste løsning at lade VPN'en håndtere DNS . En god app bør sende DNS-forespørgsler gennem den krypterede tunnel, så din internetudbyder ikke modtager dem direkte. På denne måde får du DNS-privatliv som en del af VPN-forbindelsen uden at skulle justere dine browserindstillinger separat.

Problemet opstår, når browseren bruger sin egen domæneautoritetskonfiguration (DoH), mens VPN'en forsøger at administrere DNS på systemniveau. Intet går måske i stykker, men der kan opstå forvirring : du tror måske, at alle forespørgsler går gennem VPN'en, men i virkeligheden sender browseren nogle af sig selv til en anden resolver. Det er her, en DNS-lækagetest kommer til nytte. Hvis du, efter at have oprettet forbindelse til VPN'en, ser din internetudbyders DNS-servere, fungerer noget ikke som forventet. Hvis du ser servere tilknyttet VPN'en, er det mere sandsynligt, at konfigurationen fungerer korrekt.

Hvornår er DoH tilstrækkeligt, og hvornår er en VPN tilrådelig?

DoH kan være tilstrækkeligt, når din primære bekymring er den grundlæggende fortrolighed af DNS-forespørgsler i din browser. På et betroet hjemmenetværk reducerer aktivering af sikker DNS eksponering i klartekst uden at kræve, at du ændrer din placering eller sikrer alle dine applikationer . Det er også nyttigt på netværk, hvor DNS-filtrering eller -manipulation er en bekymring, fordi det at rejse over HTTPS gør det vanskeligere nemt at inspicere eller ændre. Dette betyder ikke, at det omgår alle begrænsninger eller er censursikkert, men det er en betydelig forbedring i forhold til ukrypteret DNS. Desuden er det let: du behøver ikke at vælge en VPN-server eller ændre din routing væsentligt, og du vil typisk ikke bemærke en betydelig indflydelse på hastigheden.

En VPN giver mest mening, når du ønsker beskyttelse på hele enheden, ikke kun DNS-opslag. Dette inkluderer lufthavne, hoteller, skoler, coworking-områder, caféer og udlejningsboliger . På delte netværk ved du ikke, hvem der styrer routeren, hvem der ellers er forbundet, eller om nogen forsøger at opfange trafik. En VPN hjælper også, når du ikke ønsker, at din internetudbyder skal opbygge en profil af dine browsermønstre: Selvom HTTPS beskytter sideindhold, kan netværksmetadata stadig afsløre nyttige mønstre. Rejser er et andet tydeligt eksempel: en VPN kan gøre din forbindelse mere ensartet, beskytte dig på ukendte netværk og få websteder til at se VPN-serverens placering i stedet for din midlertidige lokale forbindelse.

Tekniske detaljer om Google Public DNS DoH API'er

Google Public DNS tilbyder to forskellige DoH API'er. Den ene er designet til RFC 8484 og accepterer GET- og POST-anmodninger på https://dns.google/dns-query; den anden er en JSON API, der kun understøtter GET-anmodninger på https://dns.google/resolve . Der er også en webgrænseflade på https://dns.google/, der viser JSON-resultater i browseren, men den implementerer ikke en fuld API. Denne grænseflade bør ikke forveksles med API-URL'er eller med https://dns.google/query. Tjenesten understøtter ikke usikrede HTTP-URL'er, og DoH understøttes også af Googles offentlige DNS64-tjeneste, selvom det i så fald kun er IPv6, der understøttes. Googles dokumentation for sikker transport indeholder eksempler på curl og detaljer om TLS, DoT og DoH.

Tilgængelige HTTP-metoder

GET-metoden kan reducere latenstid, fordi den cacher mere effektivt. RFC 8484 GET-anmodninger skal indeholde en `?dns=` parameter med en Base64Url-kodet DNS-meddelelse , og det er den eneste metode, der understøttes af JSON API'en. POST-metoden er også kun tilgængelig i RFC 8484 og bruger en binær DNS-meddelelse med `application/dns-message` i både anmodnings- og svarteksten. HEAD-metoden understøttes i øjeblikket ikke og returnerer en 400 Bad Request-fejl. Andre metoder returnerer 501 Not Implemented-fejl.

Statuskoder og fejl

API'en returnerer adskillige HTTP-koder, der er værd at kende. En 200 OK angiver, at HTTP-parsningen og kommunikationen med DNS-resolveren var vellykket ; svarteksten kan være et binært DNS-svar eller JSON afhængigt af slutpunktet, Accept-headeren og GET-parametrene. Bemærk: En HTTP-fejl kan også være en DNS-fejl, så det anbefales at kontrollere DNS-svarkoden, for eksempel "Status"-feltet i JSON'en, for fejl som SERVFAIL, FORMERR, REFUSED eller NOTIMP.

• 301 Flyttet permanent: Klienten skal gentage anmodningen på den URL, der er angivet i Placering. Hvis den oprindelige anmodning var POST, skal den kun gentage anmodningen med GET, hvis den nye URL angiver en DNS-parameter; ellers skal den gentages med POST. Statuskoder 302, 307 og 308 kan også vises, og DoH-klienter skal håndtere alle fire. Permanente statuskoder 301 og 308 kan cachelagres på ubestemt tid. POST-anmodninger, der modtager en statuskode 307 eller 308, skal altid gentages med POST.
• 400 Dårlig anmodning: Problemer med at parse GET-parametre eller en ugyldig DNS-anmodningsmeddelelse. De fleste ugyldige DNS-meddelelser modtager en 200 OK med FORMERR, men HTTP-fejl opstår for ulæselige meddelelser uden et spørgsmålsafsnit, med en QR-kode, der angiver et svar, eller med meningsløse kodekombinationer.
• 413 Nyttelast for stor: Brødteksten i en POST RFC 8484-anmodning overstiger den maksimale meddelelsesstørrelse på 512 bytes.
• 414 URI for lang: GET-forespørgselsheaderen var for stor, eller dns-parameteren oversteg 512 bytes.
• 415 Ikke-understøttet medietype: POST-brødteksten havde ikke indholdstypen header application/dns-message.
• 429 for mange anmodninger: Der er sendt for mange anmodninger i en given periode. Klienten skal vente indtil det tidspunkt, der er angivet i headeren "Retry-After".
• 500 intern serverfejl: Interne fejl i DoH-tjenesten.
• 501 Ikke implementeret: Kun GET og POST er implementeret; resten returnerer denne fejl.
• 502 Dårlig gateway: DoH-tjenesten kunne ikke kommunikere med Googles offentlige DNS-resolvere. Det kan muligvis virke at prøve en anden adresse, men en mere effektiv backupplan er at prøve en anden DoH-tjeneste eller skifte til traditionel DNS ved hjælp af UDP eller TCP på 8.8.8.8.

Bedste praksis for privatliv og ydeevne

DoH-applikationsudviklere bør begrænse HTTP-headere. Headere som Cookie, User-Agent og Accept-Language kan afsløre oplysninger om klientimplementeringen og bidrage til deanonymisering . Det anbefales kun at sende de headere, der er nødvendige for DoH: Host, Content-Type (til POST-anmodninger) og, hvis det er nødvendigt, Accept. User-Agent-headeren bør inkluderes i udviklings- eller testversioner. Det anbefales også at bruge EDNS-padding-muligheder for at forkorte forespørgsler til almindelige længder og gøre trafikanalyse vanskeligere. HTTP/2-padding er mulig, men i modsætning til EDNS-padding genererer det ikke padding i DoH-serversvar.

POST-metoden i RFC 8484 bør kun bruges i privatlivsfølsomme applikationer eller browsertilstande. Brug af POST reducerer cachekapaciteten og kan øge latensen, så det anbefales generelt ikke . Det kan dog være tilrådeligt at reducere cachestørrelsen for applikationer, der ønsker at forhindre webapp-synkroniseringsangreb, der har til formål at finde ud af, hvilke domæner brugeren for nylig har besøgt. HTTPS-tilgangen har også praktiske fordele: HTTPS API'er er bredt tilgængelige og understøttede, hvilket forenkler implementeringen; en HTTPS-tjeneste giver webapps adgang til alle typer DNS-poster og undgår begrænsningerne i browser- eller operativsystem-API'er, der typisk er begrænset til opslag fra vært til adresse; og klienter, der implementerer HTTPS over UDP med QUIC, kan undgå problemer som linjehovedblokering, der opstår med TCP. Hvis du støder på en fejl eller ønsker at anmode om en ny funktion, bør du rapportere det DoH-relaterede problem via de sædvanlige kanaler.

Almindelige spørgsmål om DoH og VPN

Et af de oftest stillede spørgsmål er, om det giver mening at bruge DoH, når man allerede bruger en VPN. Det er muligt, men den mest praktiske fremgangsmåde er normalt at lade VPN'en håndtere DNS og verificere med en lækagetest, at forespørgslerne går gennem de korrekte kanaler. Hvis browseren sender sine egne forespørgsler én vej og VPN'en en anden, kan du blive udsat for en ubehagelig overraskelse.

Et andet almindeligt spørgsmål er, om DoH forhindrer din internetudbyder i at se, hvilke websteder du besøger. DoH skjuler DNS-forespørgsler fra mange observatører, men det fjerner ikke alle metadata eller skjuler din IP-adresse : din internetudbyder kan stadig se, hvilke IP-adresser du opretter forbindelse til, og andre netværksoplysninger. For bredere beskyttelse har du brug for en VPN eller en kombination af flere privatlivslag.

Det er også værd at spørge, om DomainHost (DoH) er tilstrækkeligt på offentlige Wi-Fi-netværk. Det kan hjælpe med at forhindre netværksoperatøren i nemt at læse dine DNS-forespørgsler, men det beskytter ikke hele forbindelsen eller trafikken for alle applikationer . I lufthavne, hoteller og caféer er brugen af ​​en VPN normalt mere omfattende, især hvis du ikke ved, hvem der styrer routeren, eller om andre personer er forbundet.

Domain Name System (DoH) og VPN'er er ikke direkte rivaler, men snarere værktøjer med forskellige funktioner. DoH krypterer domæneopslag og reducerer eksponeringen af ​​den del af processen; en VPN krypterer stien mellem din enhed og en server og ændrer den IP-adresse, som destinationer ser . Ingen af ​​delene gør dig usynlig: konti, cookies, browserfingeraftryk, apptilladelser, malware og alle data, du deler direkte, kan stadig identificere dig. Men det gør dem ikke ubrugelige. Det betyder blot, at hver især har sin rolle. DoH beskytter adresseopslaget; en VPN beskytter meget mere af den sti, dine data tager.