DNS over HTTPS: hva det er og hvordan det beskytter spørringene dine

Alfaguide » datamaskiner » DNS over HTTPS: hva det er og hvordan det beskytter spørringene dine

Når du skriver inn en nettadresse, er det en komponent som jobber bak kulissene for å sikre at du kommer til riktig nettsted: Domain Name System (DNS). DNS oversetter navn som er lette å huske til IP-adresser som datamaskiner kan forstå. Det er praktisk, ja, men i årevis opererte det med en betydelig sårbarhet: disse spørringene reiste ukryptert. Dette er grunnen til at DNS over HTTPS, også kjent som DoH, har blitt så fremtredende – et ekstra lag med beskyttelse som gjør det vanskeligere for internettleverandøren din å spore hvilke domener du besøker.

Det er viktig å avklare én ting fra starten av: DoH forbedrer personvernet til DNS-forespørsler, men det er ikke et VPN, og det gjør heller ikke hele forbindelsen din til en hemmelig tunnel . Gjennom denne artikkelen skal vi utforske nøyaktig hva det er, hvorfor det har blitt populært, hvordan du aktiverer det i Chrome, Edge og Firefox, fordelene og ulempene, hvordan det skiller seg fra DNS i forhold til TLS og et VPN, og omfanget av dets tekniske og praktiske begrensninger.

Hva er DNS, og hvorfor kommer det tradisjonelle systemet til kort?

DNS-servere er en av de komponentene som nesten ingen ser på, men de ligger til grunn for en stor del av nettsurfing. Deres jobb er å koble et domenenavn til IP-adressen til den tilsvarende serveren . Når du besøker et nettsted, forstår ikke datamaskinen din bokstaver: den trenger en IP-adresse for å vite hvilken maskin den skal koble til. Mange rutere leveres med DNS-servere som allerede er konfigurert av internettleverandøren, noe som gjør prosessen praktisk, selv om den også etterlater et synlig spor for den som kontrollerer den infrastrukturen.

Det underliggende problemet er at tradisjonelle DNS-forespørsler gjøres i ren tekst og uten beskyttelse . Dette åpner døren for avlytting, «man-in-the-middle»-angrep og manipulering av svaret. En internettleverandør kan lære hvilke domener du spør om og når; en angriper på et delt nettverk kan prøve å avskjære forespørselen og returnere et falskt svar. Denne teknikken er kjent som DNS-kapring og kan til slutt føre deg til en falsk side, uønsket reklame eller et nettsted som er designet for å stjele data. Myndigheter og internettleverandører har også historisk sett utnyttet disse svakhetene til å implementere sensur, blokkere domener eller vise ytterligere reklame.

• Passiv lytting: Noen observerer spørringene og utleder hvilke tjenester eller nettsteder du besøker ofte.
• Mann-i-midten: Kommunikasjonen blir avlyttet, og svaret blir endret for å utgi seg for å være en server.
• Blokkering og filtrering: Det forhindrer oppløsning av visse domener for å kontrollere tilgangen til innhold.

DNS over HTTPS: Krypter spørringen slik at den ikke er synlig for alle.

DNS over HTTPS, eller DoH, er en løsning som bruker HTTPS-protokollen til å overføre DNS-forespørsler og -svar i kryptert form . I stedet for å sende en tydelig DNS-forespørsel, innkapsler enheten den i en sikker forbindelse, vanligvis ved hjelp av port 443, den samme porten som brukes av sikre nettsteder. Dette beskytter både forespørselen og svaret, og hindrer en ekstern observatør i å lese dem enkelt.

For at dette skal fungere, må DNS-serveren som spørres også støtte domenebasert DNS (DoH ). Det er ikke nok å bare aktivere et alternativ i nettleseren: den valgte resolveren må overholde denne standarden. Spesifikasjonen har vært i utvikling og anses fortsatt som en teknologi under utvikling, selv om selskaper som Google og Mozilla Foundation har testet og integrert den siden 2018. I tillegg til forbedret personvern, indikerer tester at DoH kan redusere ventetid og gjøre spørringer raskere, fordi det ikke alltid er nødvendig å løse hele domenet, men bare den minste nødvendige delen.

Fordeler med DoH: mer personvern, mindre manipulasjon og bedre ytelse

Den mest åpenbare fordelen er sikkerhet. Fordi de går kryptert, er DNS-forespørsler mye vanskeligere å spionere på eller endre . Dette kompliserer mellommann-angrep, reduserer eksponering på offentlige Wi-Fi-nettverk og forhindrer at en lokal operatør tydelig ser hvilke domener du ber om. Siden DoH-trafikk bruker port 443, blander den seg med andre HTTPS-tilkoblinger og er vanskelig å skille fra et vanlig nettbesøk.

Det finnes også ytelsesmessige årsaker. DoH kan redusere latens og øke hastigheten på DNS-kommunikasjon takket være endringer i hvordan navn løses og bedre bruk av hurtigbufferen. For eksempel er GET-metoden til noen API-er designet for å bli hurtigbufret mer effektivt. I praksis kan dette føre til litt raskere nettlesing, selv om det ikke er en magisk løsning, og forbedringen er ikke alltid merkbar. Videre, siden den er implementert i nettleseren, trenger ikke brukeren å vente på at internettleverandøren skal aktivere den.

Ulemper og debatter: når kryptering kompliserer livet

Ikke alle ser positivt på domenebasert kryptering (DoH). Den samme krypteringen som beskytter brukeren gjør også nettverksovervåking vanskeligere . Mange foreldrekontrollprogrammer er avhengige av å inspisere DNS-spørringer for å finne ut hvilke nettsteder barn prøver å få tilgang til. Med DoH blir denne oppgaven mye mer komplisert og kan til og med være umulig. En lignende situasjon eksisterer for bedriftsnettverksadministratorer, som mister innsikt i domenene som blir spurt om og ikke kan håndheve visse regler like lett.

Internettleverandører mister også muligheten til å overvåke tilgang og blokkere bestemte domener på oppdrag fra en institusjon. Dette skaper en legitim debatt: noen ser det som en seier for personvernet, mens andre anser det som et kontroll- og administrasjonsproblem . Når det gjelder DoT, blir det også kritisert for å bruke sin egen gjenkjennelige port, som tillater identifisering av DNS-forespørsler selv uten å vite nøyaktig hva som blir spurt om. DoH unngår dette klare signalet ved å skjule seg i HTTPS-trafikk, men til gjengjeld sitter nettverksadministratorer igjen med færre verktøy for å administrere kommunikasjonen sin.

Slik aktiverer du DoH i Chrome, Edge og Firefox

Det er vanligvis enkelt å aktivere Domain Name System (DNS) i en moderne nettleser, spesielt hvis den er basert på Chromium eller Firefox. Alternativet finnes, men i noen tilfeller er det skjult i avanserte innstillingsmenyer . Før du endrer noe, er det viktig å forstå at nettleseren bare beskytter sine egne spørringer: andre applikasjoner på enheten kan fortsette å bruke et annet DNS-system hvis det ikke også er konfigurert på systemnivå.

Google Chrome

I Chrome er den raskeste måten å skrive chrome://flags/#dns-over-https i adressefeltet. Det tar deg direkte til Chromes flagg eller eksperimentelle funksjoner.Du vil se et alternativ kalt Sikre DNS-oppslag valgt. Klikk på rullegardinmenyen som sier Standard og velg Aktivert. Deretter må du starte nettleseren på nytt for at endringen skal tre i kraft.

Microsoft Edge

I Chromium-baserte Edge er prosessen så godt som identisk. Åpne nettleseren din og skriv inn edge://flags/#dns-over-https i søkefeltetDu skriver inn Edges flagg, og det samme alternativet for sikker DNS-søk vil vises. Endre standard til aktivert og start nettleseren på nytt når du blir bedt om det.

Mozilla Firefox

I Firefox trenger du ikke å gå til Flagg. Klikk på menyknappen øverst til høyre og velg Alternativer . I Generelt-delen blar du ned til bunnen og klikker på Nettverksinnstillinger. I vinduet som åpnes, merker du av i boksen ved siden av Aktiver DNS over HTTPS. Du kan deretter velge mellom leverandører som Cloudflare og NextDNS for å utføre kryptering over HTTPS.

DNS over TLS (DoT): den andre krypterte banen

DNS over TLS, eller DoT, er en annen måte å beskytte DNS-spørringer på. I stedet for å bruke HTTPS, bruker den TLS over en TCP-tilkobling og en standardisert port, 853. TLS er det samme sikkerhetsfundamentet som HTTPS, så ideen er lik: å lage en kryptert tunnel der bare de to deltakerne kan dekryptere og behandle informasjonen. Dette gjør man-in-the-middle-angrep vanskeligere og forhindrer en tredjepart i å lese eller manipulere spørringen.

DotT har sine fordeler, spesielt sammenlignet med tradisjonell DNS, som ikke tilbyr noen sikkerhetstiltak. Kryptering hindrer nettkriminelle i å fange opp forespørsler og hindrer også visse sensurtiltak . Det krever imidlertid kompatibilitet fra både klienten og serveren. Flere leverandører tilbyr kompatible servere, men bruk av det på en stasjonær eller bærbar datamaskin krever vanligvis installasjon av tilleggsprogramvare. På moderne Android, i hvert fall siden Android 9, er det allerede integrert. Løsninger finnes for Windows og Linux, selv om de ikke alltid er så transparente som man skulle ønske.

Blant ulempene kritiserer mange databeskyttelseseksperter DoT for å bruke én enkelt, gjenkjennelig port. Selv om det er umulig å vite hvilket nettsted som blir besøkt, er det mulig å oppdage DNS-trafikk . For noen nettverksadministratorer er dette nyttig fordi det lar dem holde oversikt over hva som skjer; for andre er det et signal de heller vil skjule. Videre er DoT ennå ikke like utbredt som tradisjonell DNS, og serversideadopsjonen er begrenset. Det er bekymring for at noen få selskaper i økende grad vil konsentrere DNS-spørringer, noe som potensielt kan skape et slags internasjonalt monopol.

DoH vs. DoT: To måter å beskytte det samme på

Hovedforskjellen mellom DoH og DoT ligger i porten og hvordan trafikken er kamuflert. DoT bruker sin egen port, 853, mens DoH bruker 443 og blander seg med vanlige HTTPS-tilkoblinger . Denne tilsynelatende små forskjellen har utløst betydelig debatt. Fra et personvernperspektiv er det en fordel at DNS-forespørsler ikke kan skilles fra annen trafikk: hvis de ikke gjenkjennes, kan de ikke manipuleres like lett. Fra et nettverksadministrasjonsperspektiv går imidlertid kontrollen tapt, og det blir vanskeligere å implementere sikkerhets- eller filtreringspolicyer.

I kjernen er det to visjoner. IETF, konsortiet som utvikler mange internettstandarder, står bak DoT , mens Google og Mozilla Foundation har promotert DoH sterkt. Dette er ikke motstridende teknologier, men de representerer ulike måter å forstå personvern, nettverkssynlighet og mellomleddenes rolle på. Valget mellom den ene og den andre avhenger av hva som må beskyttes og hvem som må administrere nettverket.

DoH vs. et VPN: Det beskytter spørsmålet, ikke hele reisen

DoH og et VPN dukker ofte opp i de samme samtalene om personvern, men de gjør ikke det samme. DoH beskytter navnespørringen; et VPN beskytter veien dataene dine tar . Den enkleste måten å forstå dette på er å tenke på DoH som legger et sensitivt spørsmål i en forseglet konvolutt, mens et VPN sørger for at hele reisen går gjennom en privat tunnel før den returnerer til offentlig vei. Begge kan forbedre personvernet, men bare én er designet for å dekke trafikken til telefoner, nettbrett og datamaskiner fullstendig.

Hva gjør DNS før et nettsted lastes inn?

Før nettleseren din kan laste inn et nettsted, må enheten din vite hvor det befinner seg. DNS fungerer som en telefonkatalog, og oversetter et nettstedsnavn til en IP-adresse . Dette skjer konstant: når du åpner en side, starter en app, oppdaterer e-posten din eller spiller av en video. Som oftest skjer det stille, og du legger ikke merke til det, noe som er flott for enkelhets skyld, men det gjør det også enkelt å overse som et personvernproblem. Tradisjonelle DNS-spørringer er ikke kryptert, så internettleverandøren din, arbeidsgiveren din, skolen din, Wi-Fi-nettverket til en kafé eller et hotellnettverk kan se hvilke domener enheten din prøver å nå. De ser ikke hele innholdet på en HTTPS-side, men de får en ganske avslørende oversikt over aktiviteten din.

En DNS-forespørsel avslører ikke alle sider du har sett eller alt du skriver inn i et skjema, men en liste over domener kan avsløre vaner, interesser, arbeidsverktøy, helseforskning eller finansielle tjenester . Derfor har kryptert DNS blitt en nyttig personvernfunksjon. Den avslører ikke alt, men den avslører mer enn mange er klar over.

Hva skjuler DoH og hva avslører det?

DoH sender DNS-spørringer over HTTPS, den samme krypterte protokollen som brukes av sikre nettsteder. Forespørselen krypterer enheten din og ankommer en resolver som støtter standarden . På offentlig Wi-Fi kan dette gjøre det vanskelig for nettverksoperatøren å lese spørringene dine utilsiktet. Hvis internettleverandøren din administrerer DNS, kan det å bytte til en DoH-resolver forhindre at de ser disse spørringene på vanlig måte. Dessuten, hvis et nettverk manipulerer resultater av navneløsning, kan kryptert DNS redusere noen former for manipulasjon.

Nå skjuler DoH spørringen, ikke hele samtalen. Det kan hindre noen observatører i å se domenesøket tydelig, men det gjør ikke hele internettforbindelsen din om til en kryptert tunnel . Når enheten kjenner IP-adressen, følger resten av forbindelsen sin normale bane, med mindre et annet personvernverktøy endrer den ruten. DoH skjuler ikke din virkelige IP-adresse fra nettstedene, appene eller tjenestene du kobler til, og det får deg heller ikke til å se ut som om du er i en annen by eller et annet land. Hvis du logger deg på en konto, vet tjenesten at det er deg. Hvis nettleseren har informasjonskapsler, lagrede økter, annonseidentifikatorer eller et gjenkjennelig fingeravtrykk, sletter ikke DoH disse signalene.

Den beskytter heller ikke alle applikasjoner med mindre de er konfigurert på systemnivå og applikasjonen respekterer denne innstillingen. Én nettleser kan bruke sikker DNS, mens en annen applikasjon på samme enhet bruker en annen DNS-bane . Noen apper administrerer sitt eget nettverk og er ikke alltid i samsvar med system- eller nettleserinnstillingene. Derfor kan DoH skape en falsk følelse av fullstendig beskyttelse: den forbedrer personvernet til DNS-spørringer, men den beskytter ikke filoverføringer, meldingstrafikk, videosamtaler, spilltilkoblinger, bakgrunnssynkronisering eller strømmeapplikasjoner slik en VPN ville gjort.

Hva beskytter en VPN, og hva kan den ikke skjule?

Et VPN beskytter en annen del av reisen din. Det oppretter en kryptert tunnel mellom enheten din og en VPN-server, og ruter internettrafikken din gjennom den serveren . Internettleverandøren din eller det lokale Wi-Fi-nettverket ser en kryptert forbindelse til VPN-serveren, ikke en klar visning av alle nettsteder og tjenester du kobler til. I tillegg endrer VPN-et den offentlige IP-adressen som nettsteder og apper ser: i stedet for IP-adressen til hjemme- eller mobiloperatøren din, ser destinasjonen VPN-serverens IP-adresse. Dette kan redusere stedsbasert sporing, hjelpe deg med å omgå noen internettleverandørprofiler og gjøre bruk av offentlig Wi-Fi tryggere.

Et omfattende VPN kan beskytte nettlesere, strømmeapper, e-postklienter, verktøy for sikkerhetskopiering i skyen, meldingsapper, spill og bakgrunnstjenester. Det kan også rute DNS-forespørsler gjennom den krypterte tunnelen når det er riktig konfigurert , og derfor er det lurt å kjøre en DNS-lekkasjetest. Når det er sagt, er ikke et VPN magisk. Hvis du logger deg på et sosialt nettverk, en e-postkonto, en strømmetjeneste eller en nettbutikk, vet den tjenesten fortsatt hvem du er. Den kan skjule din opprinnelige IP-adresse, men den anonymiserer ikke påloggingen din. Det samme gjelder alt du sender direkte: navn, e-postadresse, betalingsdetaljer, leveringsadresse, bilder eller meldinger.

Informasjonskapsler og fingeravtrykk i nettleseren er fortsatt viktige. Apper kan skape lignende problemer gjennom annonseringsidentifikatorer, tillatelser, posisjonstilgang, Bluetooth-skanning, Wi-Fi-navn i nærheten og skanneverktøy. Skadelig programvare er en annen vanskelig hindring fordi den kan fange opp data før den i det hele tatt når VPN-tunnelen . Kort sagt, et VPN skjuler og krypterer mye aktivitet, men det skjuler ikke alle digitale fingeravtrykk.

DoH og VPN kan brukes samtidig

Ja, de kan kombineres, men det ideelle oppsettet avhenger av hvordan enheten, nettleseren og VPN-appen håndterer DNS. I mange tilfeller er den enkleste løsningen å la VPN-et håndtere DNS . En god app bør sende DNS-forespørsler gjennom den krypterte tunnelen, slik at internettleverandøren din ikke mottar dem direkte. På denne måten får du DNS-personvern som en del av VPN-tilkoblingen uten å måtte justere nettleserinnstillingene separat.

Problemet oppstår når nettleseren bruker sin egen domeneautoritetskonfigurasjon (DoH) mens VPN-et prøver å administrere DNS på systemnivå. Ingenting kan gå i stykker, men forvirring kan oppstå : du tror kanskje at alle spørringer går gjennom VPN-et, men i virkeligheten sender nettleseren noen av dem på egenhånd til en annen resolver. Det er her en DNS-lekkasjetest kommer godt med. Hvis du ser internettleverandørens DNS-servere etter at du har koblet til VPN-et, fungerer ikke noe som forventet. Hvis du ser servere tilknyttet VPN-et, er det mer sannsynlig at konfigurasjonen fungerer som den skal.

Når er DoH tilstrekkelig, og når er et VPN tilrådelig?

DoH kan være tilstrekkelig når din primære bekymring er det grunnleggende personvernet til DNS-spørringer i nettleseren din. På et pålitelig hjemmenettverk reduserer aktivering av sikker DNS eksponering for klartekst uten at du må endre posisjonen din eller sikre alle applikasjonene dine . Det er også nyttig i nettverk der DNS-filtrering eller manipulering er et problem, fordi det å reise over HTTPS gjør det vanskeligere å enkelt inspisere eller endre. Dette betyr ikke at det omgår alle restriksjoner eller er sensursikkert, men det er en betydelig forbedring i forhold til ukryptert DNS. Videre er det lett: du trenger ikke å velge en VPN-server eller endre rutingen din betydelig, og du vil vanligvis ikke merke en betydelig innvirkning på hastigheten.

Et VPN er mest fornuftig når du ønsker enhetsomfattende beskyttelse, ikke bare DNS-oppslag. Dette inkluderer flyplasser, hoteller, skoler, kontorfellesskap, kafeer og utleieboliger . På delte nettverk vet du ikke hvem som kontrollerer ruteren, hvem andre som er tilkoblet, eller om noen prøver å avlytte trafikk. Et VPN hjelper også når du ikke vil at internettleverandøren din skal bygge en profil av nettlesermønstrene dine: selv om HTTPS beskytter sideinnhold, kan nettverksmetadata fortsatt avsløre nyttige mønstre. Reising er et annet tydelig eksempel: et VPN kan gjøre forbindelsen din mer konsistent, beskytte deg på ukjente nettverk og få nettsteder til å se VPN-serverens plassering i stedet for din midlertidige lokale forbindelse.

Tekniske detaljer om Google Public DNS DoH API-ene

Google Public DNS tilbyr to distinkte DoH API-er. Den ene er designet for RFC 8484 og godtar GET- og POST-forespørsler på https://dns.google/dns-query; den andre er en JSON API som bare støtter GET-forespørsler på https://dns.google/resolve . Det finnes også et webgrensesnitt på https://dns.google/ som viser JSON-resultater i nettleseren, men det implementerer ikke et fullstendig API. Dette grensesnittet bør ikke forveksles med API-URL-ene eller med https://dns.google/query. Tjenesten støtter ikke usikrede HTTP-URL-er, og DoH støttes også av Googles offentlige DNS64-tjeneste, men i så fall støttes bare IPv6. Googles dokumentasjon for sikker transport inkluderer eksempler på curl og detaljer om TLS, DoT og DoH.

Tilgjengelige HTTP-metoder

GET-metoden kan redusere latens fordi den mellomlagrer mer effektivt. RFC 8484 GET-forespørsler må inneholde en `?dns=`-parameter med en Base64Url-kodet DNS-melding , og det er den eneste metoden som støttes av JSON API. POST-metoden er også bare tilgjengelig i RFC 8484 og bruker en binær DNS-melding med `application/dns-message` i både forespørsels- og svarinnholdet. HEAD-metoden støttes for øyeblikket ikke og returnerer en 400 Bad Request-feil. Andre metoder returnerer 501 Not Implemented-feil.

Statuskoder og feil

API-et returnerer flere HTTP-koder som er verdt å kjenne til. En 200 OK indikerer at HTTP-parsingen og kommunikasjonen med DNS-resolveren var vellykket . Svarinnholdet kan være et binært DNS-svar eller JSON, avhengig av endepunktet, Accept-headeren og GET-parameterne. Merk: en HTTP-feil kan også være en DNS-feil, så det anbefales å sjekke DNS-svarkoden, for eksempel "Status"-feltet i JSON-en, for feil som SERVFAIL, FORMERR, REFUSED eller NOTIMP.

• 301 Flyttet permanent: Klienten må prøve forespørselen på nytt på URL-en som er angitt i Plassering. Hvis den opprinnelige forespørselen var POST, skal den bare prøve på nytt med GET hvis den nye URL-en spesifiserer en DNS-parameter; ellers må den gjentas med POST. Statuskodene 302, 307 og 308 kan også vises, og DoH-klienter må håndtere alle fire. Permanente statuskoder 301 og 308 kan mellomlagres på ubestemt tid. POST-forespørsler som mottar en statuskode 307 eller 308 må alltid prøves på nytt med POST.
• 400 dårlig forespørsel: Problemer med å analysere GET-parametere eller en ugyldig DNS-forespørselsmelding. De fleste ugyldige DNS-meldinger får en 200 OK med FORMERR, men HTTP-feil oppstår for uleselige meldinger uten en spørsmålsseksjon, med en QR-kode som indikerer et svar, eller med meningsløse kodekombinasjoner.
• 413 Nyttelasten er for stor: Innholdet i en POST RFC 8484-forespørsel overskrider den maksimale meldingsstørrelsen på 512 byte.
• 414 URI for lang: GET-spørrehodet var for stort, eller dns-parameteren overskred 512 byte.
• 415 Medietype som ikke støttes: POST-brødteksten hadde ikke innholdstypen header application/dns-message.
• 429 for mange forespørsler: For mange forespørsler er sendt i løpet av en gitt periode. Klienten må vente til tiden som er angitt i Retry-After-headeren.
• 500 intern serverfeil: Interne feil i DoH-tjenesten.
• 501 Ikke implementert: Bare GET og POST er implementert; resten returnerer denne feilen.
• 502 Dårlig gateway: DoH-tjenesten kunne ikke kommunisere med Google Public DNS-resolvere. Det kan fungere å prøve en annen adresse, men en mer effektiv reserveplan er å prøve en annen DoH-tjeneste eller bytte til tradisjonell DNS ved hjelp av UDP eller TCP på 8.8.8.8.

Beste praksis for personvern og ytelse

Utviklere av DoH-applikasjoner bør begrense HTTP-overskrifter. Overskrifter som Cookie, User-Agent og Accept-Language kan avsløre informasjon om klientimplementeringen og bidra til avanonymisering . Det anbefales å bare sende overskriftene som er nødvendige for DoH: Host, Content-Type (for POST-forespørsler) og, om nødvendig, Accept. User-Agent-overskriften bør inkluderes i utviklings- eller testversjoner. Det anbefales også å bruke EDNS-polstringsalternativer for å forkorte spørringer til vanlige lengder og gjøre trafikkanalyse vanskeligere. HTTP/2-polstring er mulig, men i motsetning til EDNS-polstring genererer den ikke polstring i DoH-serversvar.

POST-metoden i RFC 8484 bør kun brukes i personvernsensitive applikasjoner eller nettlesermoduser. Bruk av POST reduserer hurtigbufferkapasiteten og kan øke latensen, så det anbefales vanligvis ikke . Det kan imidlertid være tilrådelig å redusere hurtigbufferstørrelsen for applikasjoner som ønsker å forhindre synkroniseringsangrep for nettapps som tar sikte på å oppdage hvilke domener brukeren nylig har besøkt. HTTPS-tilnærmingen har også praktiske fordeler: HTTPS API-er er allment tilgjengelige og støttet, noe som forenkler implementeringen; en HTTPS-tjeneste gir nettapper tilgang til alle typer DNS-poster, og unngår begrensningene til nettleser- eller operativsystem-API-er som vanligvis er begrenset til oppslag fra vert til adresse; og klienter som implementerer HTTPS over UDP med QUIC kan unngå problemer som linjehodeblokkering som oppstår med TCP. Hvis du støter på en feil eller ønsker å be om en ny funksjon, bør du rapportere det DoH-relaterte problemet gjennom de vanlige kanalene.

Vanlige spørsmål om DoH og VPN

Et av de vanligste spørsmålene er om det er fornuftig å bruke DoH når man allerede bruker et VPN. Det er mulig, men den mest praktiske tilnærmingen er vanligvis å la VPN-et håndtere DNS og bekrefte med en lekkasjetest at spørringene går gjennom de riktige kanalene. Hvis nettleseren sender sine egne spørringer én vei og VPN-et en annen, kan du få deg en ubehagelig overraskelse.

Et annet vanlig spørsmål er om DoH hindrer internettleverandøren din i å se hvilke nettsteder du besøker. DoH skjuler DNS-forespørsler fra mange observatører, men det fjerner ikke alle metadata eller skjuler IP-adressen din : internettleverandøren din kan fortsatt se hvilke IP-adresser du kobler til og annen nettverksinformasjon. For bredere beskyttelse trenger du et VPN eller en kombinasjon av flere personvernlag.

Det er også verdt å spørre om DomainHost (DoH) er tilstrekkelig på offentlige Wi-Fi-nettverk. Det kan bidra til å forhindre at nettverksoperatøren enkelt leser DNS-spørringene dine, men det beskytter ikke hele forbindelsen eller trafikken til alle applikasjoner . På flyplasser, hoteller og kafeer er bruk av VPN vanligvis mer omfattende, spesielt hvis du ikke vet hvem som kontrollerer ruteren eller om andre personer er tilkoblet.

Domenenavnsystemet (DoH) og VPN-er er ikke direkte konkurrenter, men snarere verktøy med forskjellige funksjoner. DoH krypterer domenesøk og reduserer eksponeringen for den delen av prosessen; et VPN krypterer banen mellom enheten din og en server og endrer IP-adressen som sees av destinasjoner . Ingen av delene gjør deg usynlig: kontoer, informasjonskapsler, nettleserfingeravtrykk, apptillatelser, skadelig programvare og eventuelle data du deler direkte kan fortsatt identifisere deg. Men det gjør dem ikke ubrukelige. Det betyr ganske enkelt at hver av dem har sin rolle. DoH beskytter adressesøket; et VPN beskytter mye mer av banen dataene dine tar.