DNS över HTTPS: vad det är och hur det skyddar dina frågor

Alfaguide » Datorer » DNS över HTTPS: vad det är och hur det skyddar dina frågor

När du skriver en webbadress finns det en komponent som arbetar bakom kulisserna för att säkerställa att du når rätt webbplats: Domain Name System (DNS). DNS översätter lättkomna namn till IP-adresser som datorer kan förstå. Det är bekvämt, visserligen, men i åratal fungerade det med en betydande sårbarhet: dessa frågor skickades okrypterade. Det är därför DNS över HTTPS, även känt som DoH, har blivit så framträdande – ett extra skyddslager som gör det svårare för din internetleverantör att spåra vilka domäner du besöker.

Det är viktigt att förtydliga en sak från början: DoH förbättrar sekretessen för DNS-frågor, men det är inte ett VPN, och det förvandlar inte heller hela din anslutning till en hemlig tunnel . Genom den här artikeln kommer vi att utforska exakt vad det är, varför det har blivit populärt, hur man aktiverar det i Chrome, Edge och Firefox, dess fördelar och nackdelar, hur det skiljer sig från DNS jämfört med TLS och ett VPN, och omfattningen av dess tekniska och praktiska begränsningar.

Vad är DNS och varför misslyckas det traditionella systemet?

DNS-servrar är en av de komponenter som nästan ingen tittar på, men de ligger till grund för en stor del av onlinesurfandet. Deras uppgift är att länka ett domännamn till IP-adressen för motsvarande server . När du besöker en webbplats förstår din dator inte bokstäver: den behöver en IP-adress för att veta vilken maskin den ska ansluta till. Många routrar levereras med DNS-servrar som redan är konfigurerade av internetleverantören, vilket gör processen bekväm, även om den också lämnar ett synligt spår för den som kontrollerar den infrastrukturen.

Det underliggande problemet är att traditionella DNS-förfrågningar görs i klartext och utan skydd . Detta öppnar dörren för avlyssning, man-in-the-middle-attacker och manipulation av svaret. En internetleverantör kan lära sig vilka domäner du frågar och när; en angripare på ett delat nätverk kan försöka fånga upp begäran och returnera ett bedrägligt svar. Denna teknik kallas DNS-kapning och kan i slutändan leda dig till en falsk sida, oönskad reklam eller en webbplats som är utformad för att stjäla data. Regeringar och internetleverantörer har också historiskt utnyttjat dessa svagheter för att implementera censur, blockera domäner eller visa ytterligare reklam.

• Passivt lyssnande: Någon observerar frågorna och avgör vilka tjänster eller webbplatser du besöker ofta.
• Mannen i mitten: Kommunikationen avlyssnas och svaret modifieras för att imitera en server.
• Blockering och filtrering: Det förhindrar upplösning av vissa domäner för att kontrollera åtkomst till innehåll.

DNS över HTTPS: Kryptera frågan så att den inte är synlig för alla.

DNS över HTTPS, eller DoH, är en lösning som utnyttjar HTTPS-protokollet för att överföra DNS-frågor och svar i krypterad form . Istället för att skicka en tydlig DNS-förfrågan kapslar enheten in den i en säker anslutning, vanligtvis med port 443, samma port som används av säkra webbplatser. Detta skyddar både frågan och svaret och förhindrar att en extern observatör enkelt kan läsa dem.

För att detta ska fungera måste DNS-servern som efterfrågas också stödja domänbaserad DNS (DoH ). Att bara aktivera ett alternativ i webbläsaren räcker inte: den valda resolvern måste följa denna standard. Specifikationen har utvecklats och anses fortfarande vara en teknik under utveckling, även om företag som Google och Mozilla Foundation har testat och integrerat den sedan 2018. Förutom förbättrad integritet visar tester att DoH kan minska latensen och göra frågor snabbare, eftersom det inte alltid är nödvändigt att resolvera hela domänen, utan bara den minsta nödvändiga delen.

Fördelar med DoH: mer integritet, mindre manipulation och bättre prestanda

Den mest uppenbara fördelen är säkerhet. Eftersom de skickas krypterat är DNS-frågor mycket svårare att spionera på eller modifiera. Detta komplicerar man-in-the-middle-attacker, minskar exponeringen på offentliga Wi-Fi-nätverk och förhindrar att en lokal operatör tydligt ser vilka domäner du begär. Eftersom DoH-trafik använder port 443 smälter den in med andra HTTPS-anslutningar och är svår att skilja från ett vanligt webbbesök.

Det finns också prestandaskäl. DoH kan minska latensen och snabba upp DNS-kommunikation tack vare förändringar i hur namn tolkas och bättre användning av cachen. Till exempel är GET-metoden för vissa API:er utformad för att cacha mer effektivt. I praktiken kan detta leda till något snabbare surfning, även om det inte är en mirakelkur och förbättringen inte alltid är märkbar. Dessutom, eftersom den är implementerad i webbläsaren, behöver användaren inte vänta på att deras internetleverantör ska aktivera den.

Nackdelar och debatter: när kryptering komplicerar livet

Inte alla ser positivt på domänbaserad kryptering (DoH). Samma kryptering som skyddar användaren gör också nätverksövervakning svårare. Många föräldrakontrollprogram förlitar sig på att inspektera DNS-frågor för att avgöra vilka webbplatser barn försöker komma åt; med DoH blir denna uppgift mycket mer komplicerad och kan till och med vara omöjlig. En liknande situation finns för företagsnätverksadministratörer, som förlorar insyn i de domäner som efterfrågas och inte kan upprätthålla vissa regler lika enkelt.

Internetleverantörer förlorar också möjligheten att övervaka åtkomst och blockera specifika domäner på begäran av en institution. Detta skapar en legitim debatt: vissa ser det som en seger för integriteten, medan andra anser att det är ett kontroll- och hanteringsproblem. När det gäller DoT kritiseras det också för att använda sin egen igenkännbara port, vilket möjliggör identifiering av DNS-frågor även utan att veta exakt vad som efterfrågas. DoH undviker denna tydliga signal genom att dölja sig i HTTPS-trafik, men i gengäld har nätverksadministratörer färre verktyg för att hantera sin kommunikation.

Så här aktiverar du DoH i Chrome, Edge och Firefox

Att aktivera Domain Name System (DNS) i en modern webbläsare är oftast enkelt, särskilt om den är baserad på Chromium eller Firefox. Alternativet finns, även om det i vissa fall är dolt i avancerade inställningsmenyer . Innan du ändrar något är det viktigt att förstå att webbläsaren bara skyddar sina egna frågor: andra applikationer på enheten kan fortsätta att använda ett annat DNS-system om det inte också är konfigurerat på systemnivå.

Google Chrome

I Chrome är det snabbaste sättet att skriva chrome://flags/#dns-over-https i adressfältet. Det tar dig direkt till Chromes flaggor eller experimentella funktioner.Du kommer att se ett alternativ som heter Säkra DNS-sökningar markerat; klicka på rullgardinsmenyn som säger Standard och välj Aktiverad. Sedan måste du starta om webbläsaren för att ändringen ska träda i kraft.

Microsoft Edge

I Chromium-baserade Edge är processen praktiskt taget identisk. Öppna din webbläsare och skriv edge://flags/#dns-over-https i sökfältetDu anger Edges flaggor och samma alternativ för säkra DNS-sökningar visas. Ändra standardinställningen till aktiverad och starta om webbläsaren när du uppmanas till det.

Mozilla Firefox

I Firefox behöver du inte gå till Flaggor. Klicka på menyknappen i det övre högra hörnet och välj Alternativ . I avsnittet Allmänt skrollar du ner till botten och klickar på Nätverksinställningar. I fönstret som öppnas markerar du rutan bredvid Aktivera DNS över HTTPS. Du kan sedan välja mellan leverantörer som Cloudflare och NextDNS för att utföra kryptering över HTTPS.

DNS över TLS (DoT): den andra krypterade sökvägen

DNS över TLS, eller DoT, är ett annat sätt att skydda DNS-frågor. Istället för att använda HTTPS används TLS över en TCP-anslutning och en standardiserad port, 853. TLS är samma säkerhetsgrund som HTTPS, så idén är liknande: att skapa en krypterad tunnel där endast de två deltagarna kan dekryptera och bearbeta informationen. Detta försvårar man-in-the-middle-attacker och förhindrar att en tredje part läser eller manipulerar frågan.

DotT har sina fördelar, särskilt jämfört med traditionell DNS, som inte erbjuder några säkerhetsåtgärder. Kryptering förhindrar cyberbrottslingar från att avlyssna förfrågningar och hindrar även vissa censuråtgärder . Det kräver dock kompatibilitet från både klienten och servern. Flera leverantörer erbjuder kompatibla servrar, men att använda det på en stationär eller bärbar dator kräver vanligtvis installation av ytterligare programvara; på moderna Android, åtminstone sedan Android 9, är det redan integrerat. Lösningar finns för Windows och Linux, även om de inte alltid är så transparenta som man kan önska.

Bland nackdelarna kritiserar många dataskyddsexperter DoT för att använda en enda, igenkännbar port. Även om det är omöjligt att veta vilken webbplats som besöks, är det möjligt att upptäcka DNS-trafik . För vissa nätverksadministratörer är detta användbart eftersom det gör att de kan ha en överblick över vad som händer; för andra är det en signal de hellre döljer. Dessutom är DoT ännu inte lika utbrett som traditionell DNS, och dess serversidesanvändning är begränsad. Det finns oro för att ett fåtal företag i allt högre grad kommer att koncentrera DNS-frågor, vilket potentiellt skapar ett slags internationellt monopol.

DoH vs. DoT: Två sätt att skydda samma sak

Den största skillnaden mellan DoH och DoT ligger i porten och hur trafiken döljs. DoT använder sin egen port, 853, medan DoH använder 443 och smälter in med vanliga HTTPS-anslutningar . Denna till synes lilla skillnad har väckt avsevärd debatt. Ur ett integritetsperspektiv är det en fördel att DNS-frågor inte kan skiljas från annan trafik: om de inte känns igen kan de inte manipuleras lika lätt. Ur ett nätverkshanteringsperspektiv förloras dock kontrollen, och det blir svårare att implementera säkerhets- eller filtreringspolicyer.

I grund och botten finns det två visioner. IETF, konsortiet som utvecklar många internetstandarder, står bakom DoT , medan Google och Mozilla Foundation starkt har förespråkat DoH. Dessa är inte motstridiga teknologier, men de representerar olika sätt att förstå integritet, nätverkssynlighet och mellanhänders roll. Valet mellan det ena och det andra beror på vad som behöver skyddas och vem som behöver hantera nätverket.

DoH vs. ett VPN: Det skyddar frågan, inte hela resan

DoH och ett VPN dyker ofta upp i samma diskussioner om integritet, men de gör inte samma sak. DoH skyddar namnfrågan; ett VPN skyddar vägen dina data tar . Det enklaste sättet att förstå detta är att tänka sig DoH som lägger en känslig fråga i ett förseglat kuvert, medan ett VPN gör att hela resan går genom en privat tunnel innan den återvänder till allmän väg. Båda kan förbättra integriteten, men bara en är utformad för att heltäckande täcka trafiken från telefoner, surfplattor och datorer.

Vad gör DNS innan en webbplats laddas?

Innan din webbläsare kan ladda en webbplats måste din enhet veta dess plats. DNS fungerar som en telefonbok och översätter ett webbplatsnamn till en IP-adress . Detta händer konstant: när du öppnar en sida, startar en app, uppdaterar din e-post eller spelar upp en video. För det mesta sker det tyst, och du märker det inte, vilket är bra för bekvämligheten, men det gör det också lätt att förbise som ett integritetsproblem. Traditionella DNS-frågor är inte krypterade, så din internetleverantör, din arbetsgivare, din skola, ett kafés Wi-Fi eller ett hotellnätverk kan se vilka domäner din enhet försöker nå. De ser inte hela innehållet på en HTTPS-sida, men de får en ganska avslöjande översikt över din aktivitet.

En DNS-fråga avslöjar inte varje sida du har tittat på eller allt du skriver in i ett formulär, men en lista med domäner kan avslöja vanor, intressen, arbetsverktyg, hälsoforskning eller finansiella tjänster . Det är därför krypterad DNS har blivit en användbar integritetsfunktion. Den avslöjar inte allt, men den avslöjar mer än många inser.

Vad döljer DoH och vad avslöjar det?

DoH skickar DNS-frågor via HTTPS, samma krypterade protokoll som används av säkra webbplatser. Begäran lämnar din enhet krypterad och anländer till en resolver som stöder standarden . På offentliga Wi-Fi-nätverk kan detta göra det svårt för nätverksoperatören att oavsiktligt läsa dina frågor. Om din internetleverantör hanterar DNS kan byte till en DoH-resolver förhindra att de ser dessa frågor på vanligt sätt. Dessutom, om ett nätverk manipulerar namnmatchningsresultat, kan krypterad DNS minska vissa former av manipulation.

Nu döljer DoH frågan, inte hela konversationen. Det kan hindra vissa observatörer från att tydligt se domänsökningen, men det förvandlar inte hela din internetanslutning till en krypterad tunnel . När enheten väl känner till IP-adressen följer resten av anslutningen sin normala väg, såvida inte ett annat integritetsverktyg ändrar den rutten. DoH döljer inte din riktiga IP-adress från webbplatser, appar eller tjänster du ansluter till, och det får dig inte heller att se ut som om du befinner dig i en annan stad eller ett annat land. Om du loggar in på ett konto vet tjänsten att det är du. Om webbläsaren har cookies, sparade sessioner, annonsidentifierare eller ett igenkännbart fingeravtryck raderar DoH inte dessa signaler.

Det skyddar inte heller alla applikationer om de inte är konfigurerade på systemnivå och applikationen respekterar den inställningen. En webbläsare kan använda säker DNS medan en annan applikation på samma enhet använder en annan DNS-sökväg. Vissa appar hanterar sitt eget nätverk och är inte alltid i linje med system- eller webbläsarinställningarna. Därför kan DoH skapa en falsk känsla av fullständigt skydd: det förbättrar sekretessen för DNS-frågor, men det skyddar inte filöverföringar, meddelandetrafik, videosamtal, spelanslutningar, bakgrundssynkronisering eller streamingapplikationer på samma sätt som ett VPN skulle göra.

Vad skyddar ett VPN och vad kan det inte dölja?

Ett VPN skyddar en annan del av din resa. Det skapar en krypterad tunnel mellan din enhet och en VPN-server och dirigerar din internettrafik genom den servern . Din internetleverantör eller ditt lokala Wi-Fi-nätverk ser en krypterad anslutning till VPN-servern, inte en tydlig vy över varje webbplats och tjänst du ansluter till. Dessutom ändrar VPN:et den offentliga IP-adress som webbplatser och appar ser: istället för din hem- eller mobiloperatörs IP-adress ser destinationen VPN-serverns IP-adress. Detta kan minska platsbaserad spårning, hjälpa dig att kringgå vissa internetleverantörsprofiler och göra det säkrare att använda offentligt Wi-Fi.

Ett heltäckande VPN kan skydda webbläsare, streamingappar, e-postklienter, verktyg för molnsäkerhetskopiering, meddelandeappar, spel och bakgrundstjänster. Det kan också dirigera DNS-förfrågningar genom den krypterade tunneln när det är korrekt konfigurerat , vilket är anledningen till att det är en bra idé att köra ett DNS-läcktest. Med det sagt är ett VPN inte magiskt. Om du loggar in på ett socialt nätverk, e-postkonto, streamingtjänst eller webbutik vet den tjänsten fortfarande vem du är. Den kan dölja din ursprungliga IP-adress, men den anonymiserar inte din inloggning. Detsamma gäller allt du skickar direkt: ditt namn, din e-postadress, betalningsuppgifter, leveransadress, foton eller meddelanden.

Cookies och webbläsarfingeravtryck spelar fortfarande roll. Appar kan skapa liknande problem genom reklamidentifierare, behörigheter, platsåtkomst, Bluetooth-skanning, närliggande Wi-Fi-namn och skanningsverktyg. Skadlig programvara är ett annat svårt hinder eftersom den kan samla in data innan den ens når VPN-tunneln . Kort sagt, ett VPN döljer och krypterar mycket aktivitet, men det döljer inte varje digitalt fingeravtryck.

DoH och ett VPN kan användas samtidigt

Ja, de kan kombineras, men den ideala konfigurationen beror på hur enheten, webbläsaren och VPN-appen hanterar DNS. I många fall är den enklaste lösningen att låta VPN:et hantera DNS . En bra app bör skicka DNS-frågor genom den krypterade tunneln så att din internetleverantör inte tar emot dem direkt. På så sätt får du DNS-sekretess som en del av VPN-anslutningen utan att behöva justera dina webbläsarinställningar separat.

Problemet uppstår när webbläsaren använder sin egen domänauktoritetskonfiguration (DoH) medan VPN:et försöker hantera DNS på systemnivå. Ingenting kan gå sönder, men förvirring uppstår : du kanske tror att alla frågor går via VPN:et, men i verkligheten skickar webbläsaren några på egen hand till en annan resolver. Det är här ett DNS-läcktest kommer väl till pass. Om du, efter att ha anslutit till VPN:et, ser din internetleverantörs DNS-servrar, fungerar något inte som förväntat; om du ser servrar som är associerade med VPN:et, är det mer troligt att konfigurationen fungerar korrekt.

När är DoH tillräckligt och när är ett VPN lämpligt?

DoH kan vara tillräckligt när din primära oro är den grundläggande integriteten för DNS-frågor i din webbläsare. I ett betrott hemnätverk minskar aktivering av säker DNS exponeringen för klartext utan att du behöver ändra din plats eller säkra alla dina applikationer . Det är också användbart i nätverk där DNS-filtrering eller manipulation är ett problem, eftersom det är svårare att enkelt inspektera eller modifiera att resa över HTTPS. Detta betyder inte att det kringgår alla begränsningar eller är censursäkert, men det är en betydande förbättring jämfört med okrypterad DNS. Dessutom är det lätt: du behöver inte välja en VPN-server eller ändra din routing avsevärt, och du kommer vanligtvis inte att märka någon betydande inverkan på hastigheten.

Ett VPN är mest användbart när du vill ha enhetsomfattande skydd, inte bara DNS-sökningar. Detta inkluderar flygplatser, hotell, skolor, coworking-utrymmen, kaféer och hyresbostäder . I delade nätverk vet du inte vem som kontrollerar routern, vilka andra som är anslutna eller om någon försöker fånga upp trafik. Ett VPN hjälper också när du inte vill att din internetleverantör ska skapa en profil av dina surfmönster: även om HTTPS skyddar sidinnehåll kan nätverksmetadata fortfarande avslöja användbara mönster. Att resa är ett annat tydligt exempel: ett VPN kan göra din anslutning mer konsekvent, skydda dig i okända nätverk och få webbplatser att se VPN-serverns plats istället för din tillfälliga lokala anslutning.

Tekniska detaljer om Googles offentliga DNS DoH API:er

Google Public DNS erbjuder två distinkta DoH API:er. Det ena är utformat för RFC 8484 och accepterar GET- och POST-förfrågningar på https://dns.google/dns-query; det andra är ett JSON API som endast stöder GET-förfrågningar på https://dns.google/resolve . Det finns också ett webbgränssnitt på https://dns.google/ som visar JSON-resultat i webbläsaren, men det implementerar inte ett fullständigt API. Detta gränssnitt bör inte förväxlas med API-URL:erna eller med https://dns.google/query. Tjänsten stöder inte osäkra HTTP-URL:er, och DoH stöds också av Googles offentliga DNS64-tjänst, även om i så fall endast IPv6 stöds. Googles dokumentation för säker transport innehåller exempel på curl och detaljer om TLS, DoT och DoH.

Tillgängliga HTTP-metoder

GET-metoden kan minska latensen eftersom den cachar mer effektivt. RFC 8484 GET-förfrågningar måste innehålla en `?dns=`-parameter med ett Base64Url-kodat DNS-meddelande , och det är den enda metoden som stöds av JSON API. POST-metoden är också endast tillgänglig i RFC 8484 och använder ett binärt DNS-meddelande med `application/dns-message` i både begäran och svarstexten. HEAD-metoden stöds för närvarande inte och returnerar ett 400 Bad Request-fel. Andra metoder returnerar 501 Not Implemented-fel.

Statuskoder och fel

API:et returnerar flera HTTP-koder som är värda att känna till. Ett 200 OK indikerar att HTTP-parsningen och kommunikationen med DNS-resolvern lyckades ; svarstexten kan vara ett binärt DNS-svar eller JSON beroende på slutpunkten, Accept-headern och GET-parametrarna. Obs: ett HTTP-fel kan också vara ett DNS-fel, så det är lämpligt att kontrollera DNS-svarskoden, till exempel "Status"-fältet i JSON, för fel som SERVFAIL, FORMERR, REFUSED eller NOTIMP.

• 301 Flyttad permanent: Klienten måste försöka igen med begäran på den URL som anges i Plats. Om den ursprungliga begäran var POST, bör den bara försöka igen med GET om den nya URL:en anger en DNS-parameter; annars måste den upprepas med POST. Statuskoder 302, 307 och 308 kan också visas, och DoH-klienter måste hantera alla fyra. Permanenta statuskoder 301 och 308 kan cachas på obestämd tid. POST-förfrågningar som får statuskoden 307 eller 308 måste alltid försökas igen med POST.
• 400 dålig begäran: Problem med att analysera GET-parametrar eller ett ogiltigt DNS-förfrågningsmeddelande. De flesta ogiltiga DNS-meddelanden får 200 OK med FORMERR, men HTTP-fel uppstår för oläsliga meddelanden utan ett frågeavsnitt, med en QR-kod som indikerar ett svar eller med meningslösa kodkombinationer.
• 413 Nyttolasten är för stor: Meddelandestorleken i en POST RFC 8484-begäran överskrider den maximala meddelandestorleken på 512 byte.
• 414 URI för lång: GET-frågehuvudet var för stort eller så överskred dns-parametern 512 byte.
• 415 Medietyp som inte stöds: POST-texten saknade innehållstypen header application/dns-message.
• 429 För många förfrågningar: För många förfrågningar har skickats under en given period. Klienten måste vänta tills den tid som anges i rubriken Retry-After.
• 500 internt serverfel: Interna fel i DoH-tjänsten.
• 501 Inte implementerad: Endast GET och POST är implementerade; resten returnerar detta fel.
• 502 Dålig gateway: DoH-tjänsten kunde inte kommunicera med Googles offentliga DNS-resolvers. Att prova en annan adress kan fungera, men en mer effektiv reservplan är att prova en annan DoH-tjänst eller byta till traditionell DNS med UDP eller TCP på 8.8.8.8.

Bästa praxis för integritet och prestanda

DoH-applikationsutvecklare bör begränsa HTTP-headers. Headers som Cookie, User-Agent och Accept-Language kan avslöja information om klientimplementeringen och bidra till avanonymisering . Det rekommenderas att endast skicka de headers som är nödvändiga för DoH: Host, Content-Type (för POST-förfrågningar) och, om det behövs, Accept. User-Agent-headern bör inkluderas i utvecklings- eller testversioner. Det är också lämpligt att använda EDNS-utfyllnadsalternativ för att förkorta frågor till vanliga längder och försvåra trafikanalys. HTTP/2-utfyllnad är möjlig, men till skillnad från EDNS-utfyllnad genererar den inte utfyllnad i DoH-serversvar.

POST-metoden i RFC 8484 bör endast användas i integritetskänsliga applikationer eller webbläsarlägen. Att använda POST minskar cachekapaciteten och kan öka latensen, så det rekommenderas generellt inte . Att minska cachestorleken kan dock vara lämpligt för applikationer som vill förhindra synkroniseringsattacker för webbappar som syftar till att upptäcka vilka domäner användaren nyligen har besökt. HTTPS-metoden har också praktiska fördelar: HTTPS-API:er är allmänt tillgängliga och stöds, vilket förenklar implementeringen; en HTTPS-tjänst ger webbappar åtkomst till alla typer av DNS-poster, vilket undviker begränsningarna hos webbläsar- eller operativsystem-API:er som vanligtvis är begränsade till host-to-adress-sökningar; och klienter som implementerar HTTPS över UDP med QUIC kan undvika problem som linjehuvudblockering som uppstår med TCP. Om du stöter på ett fel eller vill begära en ny funktion bör du rapportera det DoH-relaterade problemet via de vanliga kanalerna.

Vanliga frågor om DoH och VPN

En av de vanligaste frågorna är om det är vettigt att använda DoH när man redan använder ett VPN. Det är möjligt, men det mest praktiska tillvägagångssättet är oftast att låta VPN:et hantera DNS och verifiera med ett läckagetest att frågorna går igenom rätt kanaler. Om webbläsaren skickar sina egna frågor åt ett håll och VPN:et åt ett annat håll kan du få en obehaglig överraskning.

En annan vanlig fråga är om DoH hindrar din internetleverantör från att se vilka webbplatser du besöker. DoH döljer DNS-frågor från många observatörer, men det tar inte bort all metadata eller döljer din IP-adress : din internetleverantör kan fortfarande se vilka IP-adresser du ansluter till och annan nätverksinformation. För ett bredare skydd behöver du ett VPN eller en kombination av flera integritetslager.

Det är också värt att fråga sig om DomainHost (DoH) är tillräckligt på offentliga Wi-Fi-nätverk. Det kan hjälpa till att förhindra att nätverksoperatören enkelt läser dina DNS-frågor, men det skyddar inte hela anslutningen eller trafiken för alla applikationer. På flygplatser, hotell och kaféer är det vanligtvis mer omfattande att använda ett VPN, särskilt om du inte vet vem som kontrollerar routern eller om andra personer är anslutna.

Domännamnssystem (DoH) och VPN är inte direkta konkurrenter, utan snarare verktyg med olika funktioner. DoH krypterar domänsökning och minskar exponeringen för den delen av processen; ett VPN krypterar vägen mellan din enhet och en server och ändrar IP-adressen som visas av destinationer . Ingetdera gör dig osynlig: konton, cookies, webbläsarfingeravtryck, appbehörigheter, skadlig programvara och all data du delar direkt kan fortfarande identifiera dig. Men det gör dem inte värdelösa. Det betyder helt enkelt att var och en har sin roll. DoH skyddar adresssökningen; ett VPN skyddar mycket mer av den väg dina data tar.