DNS over HTTPS -asennus: 12 vaihetta, 45 min [2026]

Jokainen verkko-osoite, jonka kirjoitat selaimeen, kulkee ensin DNS-kyselynä operaattorisi tai reitittimesi kautta. Oletusarvoisesti tämä kysely lähtee liikkeelle selväkielisenä, jolloin kuka tahansa samassa verkossa tai operaattorin infrassa näkee, mitä sivustoja käyt katsomassa. DNS over HTTPS (DoH) korjaa tämän aukon salaamalla kyselyt HTTPS-yhteyden sisään. Tässä oppaassa käymme läpi koko käyttöönoton 12 vaiheessa: selaimet, Android, Linux-järjestelmätaso ja koko kotiverkon laaja Pi-hole + cloudflared -ratkaisu. Lopussa on myös 8 yleisintä vianmääritystapausta ja vinkkejä tuotantokäyttöön.

Opas on kirjoitettu niin, että voit edetä alusta loppuun yhdellä istumalla, tai poimia vain oman tilanteesi kannalta oleelliset vaiheet. Jos ajat kotitoimiston verkkoa, jossa on useita laitteita ja vieraita, koko kotiverkon laaja osuus on todennäköisesti hyödyllisin. Jos taas käytät vain yhtä kannettavaa julkisissa WiFi-verkoissa matkoilla, riittää usein pelkkä selaimen ja käyttöjärjestelmän tason konfigurointi.

Mitä DNS over HTTPS tarkoittaa ja miksi se kannattaa ottaa käyttöön

Perinteinen DNS lähettää kyselyt UDP-porttiin 53 ilman salausta. Kuka tahansa reitin varrella, operaattorista julkiseen WiFi-verkkoon, voi lukea ja jopa muokata näitä paketteja. DNS over HTTPS pakkaa saman kyselyn tavallisen HTTPS-liikenteen sisään, yleensä porttiin 443, jolloin se näyttää ulkopuolelta identtiseltä muulta selauslta. Mozilla Supportin elokuussa 2026 päivitetyn ohjeen mukaan DoH lähettää kirjoitetun verkkotunnuksen DoH-yhteensopivalle palvelimelle salatun HTTPS-yhteyden kautta, mikä eroaa perinteisestä selväkielisestä kyselystä.

Suomalaiselle ja pohjoismaiselle lukijalle tämä on käytännön kysymys, ei teoriaa. Operaattorit voivat kerätä DNS-lokeja markkinointiin, ja avoimissa WiFi-verkoissa selväkielinen DNS paljastaa selaushistorian kenelle tahansa paketteja kuuntelevalle. DNS over HTTPS ei tee sinusta anonyymiä, mutta se sulkee yhden näkyvimmistä tietovuodoista arjen selauksessa. Yhdistettynä HTTPS-salaukseen ja järkeviin selainasetuksiin se on yksi helpoimmista tavoista parantaa yksityisyyttä ilman, että mikään palvelu hidastuu merkittävästi.

Tekninen kehitys on ajanut tähän suuntaan jo vuosia. Suurin osa verkkosivuista lataa nykyään sisältönsä HTTPS-yhteyden yli, joten itse sivun sisältö on jo salattu. DNS-kysely oli pitkään ainoa selvästi näkyvä jäännös siitä, mitä käyttäjä selaa, koska se lähti liikkeelle ennen kuin varsinainen HTTPS-yhteys edes muodostui. Selainvalmistajat tunnistivat tämän aukon, ja siksi DoH tuli oletusarvoiseksi vaihtoehdoksi ensin Firefoxissa ja myöhemmin myös Chromessa, Edgessä ja muissa Chromium-pohjaisissa selaimissa.

Suomalaisista teleoperaattoreista mikään ei tällä hetkellä estä DoH:n käyttöä, joten käyttöönotto ei vaadi mitään erityisiä kiertoteitä riippumatta siitä, käytätkö Telian, DNA:n vai Elisan liittymää. Tämä eroaa joistain maista, joissa operaattorit tai verkonvalvojat ovat pyrkineet rajoittamaan salattua DNS:ää nimenomaan siksi, että se vaikeuttaa sisältösuodatusta ja liikenteen seurantaa. Pohjoismainen verkkoympäristö on tässä mielessä poikkeuksellisen avoin salatun DNS:n käyttöönotolle.

Tässä oppaassa rakennamme kerroksittaisen suojan: ensin selaimet (Firefox, Chrome-pohjaiset), sitten Android-puhelin, sitten Linux-työasema järjestelmätasolla, ja lopuksi koko kotiverkko Pi-holen ja cloudflared-proxyn avulla. Jokainen kerros toimii itsenäisesti, mutta yhdessä ne muodostavat kattavan salatun DNS-ketjun jokaiselle laitteelle kotiverkossa.

On myös hyvä ymmärtää, mitä DoH ei tee. Se ei piilota IP-osoitettasi vastaanottavalta palvelimelta, eikä se estä sivustoja itseään keräämästä evästeitä tai sormenjälkitietoja selaimestasi. DNS-kysely on vain yksi osa verkkoyhteyden muodostamista: sen jälkeen selain silti ottaa TLS-yhteyden kohdepalvelimeen, ja tämä yhteys paljastaa edelleen kohdepalvelimen IP-osoitteen operaattorillesi, vaikka itse verkkotunnuksen kysely olisikin salattu. Siksi DoH kannattaa nähdä yhtenä kerroksena laajemmassa yksityisyysstrategiassa, ei yksinään riittävänä ratkaisuna. Käymme oppaan lopussa läpi myös Encrypted Client Hello -tekniikan, joka täydentää tätä aukkoa.

Esitiedot: mitä tarvitset ennen aloitusta

Ennen kuin aloitat, varmista että käytössäsi on seuraavat asiat. Osa vaiheista on valinnaisia riippuen siitä, haluatko suojata vain selaimen vai koko kotiverkon.

• Firefox 143 tai uudempi (työpöytä) tai Firefox for Android 143+ mobiilissa, Mozilla Supportin DoH-ohjeen mukainen valikkorakenne
• Chrome, Edge, Brave tai Opera, mikä tahansa Chromium-pohjainen selain vuodelta 2024 tai uudempi (Secure DNS -asetus on kaikissa samassa paikassa)
• Android 9 tai uudempi Private DNS -asetusta varten (asetus löytyy kohdasta Asetukset → Verkko ja internet)
• Linux-jakelu, jossa on systemd 245 tai uudempi (Ubuntu 20.04+, Fedora 33+, Debian 11+ kelpaavat)
• Raspberry Pi tai muu aina päällä oleva Linux-laite, jos rakennat koko kotiverkon kattavan Pi-hole-ratkaisun
• Pi-hole asennettuna (uusin vakaa versio) ja root- tai sudo-oikeudet asennuslaitteella
• Peruskäsitys komentorivin käytöstä (kopioi-liitä riittää suurimpaan osaan vaiheista)
• Noin 45 minuuttia aikaa, jos teet kaikki kerrokset yhdellä istumalla
• Kiinteä IP-osoite tai DHCP-varaus Pi-hole-laitteelle, jotta reititin voi luottaa siihen jatkuvasti samassa osoitteessa

Alla on yhteenveto kaikista 12 vaiheesta, jotta näet etukäteen, mihin osiin kannattaa varata eniten aikaa.

Vaihe	Kerros	Arvioitu aika	Vaikeustaso
1-2	Firefox	3 min	Helppo
3-4	Chrome / Chromium	2 min	Helppo
5	Android Private DNS	2 min	Helppo
6	systemd-resolved	5 min	Keskitaso
7-9	Pi-hole + cloudflared	20 min	Vaativa
10-12	Testaus ja automatisointi	13 min	Keskitaso

Jos haluat vain nopean suojan selaimeen, voit hypätä suoraan vaiheisiin 1-4 ja ohittaa Pi-hole-osion. Koko kotiverkon laaja ratkaisu vaatii hieman enemmän aikaa, mutta suojaa myös laitteet, joihin et voi asentaa selainlaajennuksia, kuten älyTV:t ja pelikonsolit.

Kannattaa myös varata muutama minuutti reitittimen hallintapaneelin selvittämiseen etukäteen. Tarvitset pääsyn reitittimen DHCP-asetuksiin, jos aiot ohjata koko kotiverkon liikenteen Pi-holen kautta, sillä muuten yksittäiset laitteet jatkavat operaattorin oman DNS-palvelimen käyttöä huomaamattasi. Useimmilla kuluttajareitittimillä tämä löytyy kohdasta LAN-asetukset tai DHCP-palvelin, ja operaattorikohtaiset ohjeet löytyvät yleensä laitevalmistajan tukisivuilta.

Vaihe 1-2: DNS over HTTPS käyttöön Firefoxissa

Vaihe 1. Avaa Firefox ja siirry osoitteeseen about:preferences#privacy tai kulje valikkopolkua Asetukset → Tietosuoja ja turvallisuus. Mozilla Supportin kesä-elokuussa 2026 päivitetyn ohjeen mukaan DoH-asetus löytyy sivun alaosasta kohdasta DNS over HTTPS. Valitse suojaustasoksi Max Protection, jolloin Firefox käyttää salattua DNS:ää aina kun mahdollista eikä palaa hiljaa selväkieliseen kyselyyn ilman varoitusta.

Vaihe 2. Valitse palveluntarjoaja pudotusvalikosta. Firefox tarjoaa oletuksena Cloudflaren, NextDNS:n ja mahdollisuuden syöttää mukautetun DoH-URL:n. Jos käytät myöhemmin tässä oppaassa rakennettavaa Pi-hole + cloudflared -ratkaisua koko verkolle, kannattaa jättää selaimen DoH pois päältä tai osoittaa se samaan paikalliseen resolveriin, jotta et aja kahta päällekkäistä salattua DNS-polkua turhaan.

# Tarkista Firefoxin nykyinen DoH-tila komentoriviltä (Linux/macOS)
firefox --version
# Avaa suoraan DoH-asetussivu
firefox about:preferences#privacy

Huomaa, että Firefox 147.0.3 korjasi helmikuussa 2026 bugin, jossa DoH-palveluntarjoajan asetusruutu saattoi näkyä tyhjänä. Jos et näe nykyistä valintaa, päivitä selain ennen kuin jatkat. Android-käyttäjille sama toiminto tuli Firefox 143 -versiossa syyskuussa 2025: valikosta Increased Protection ottaa DoH:n käyttöön mobiilissa samalla logiikalla kuin työpöydällä.

Firefoxin suojaustasoissa on kolme vaihtoehtoa, ja niiden ero kannattaa ymmärtää ennen valintaa. Off palauttaa käyttöjärjestelmän oman selväkielisen DNS:n. Increased Protection käyttää DoH:ta silloin kun se on saatavilla, mutta palaa hiljaisesti järjestelmän DNS:ään jos yhteys DoH-palvelimeen epäonnistuu. Max Protection puolestaan estää sivun lataamisen kokonaan, jos DoH-yhteyttä ei saada muodostettua, mikä on turvallisin mutta samalla vaativin vaihtoehto: yritysverkoissa tai vanhoilla julkisilla WiFi-yhteyksillä tämä voi näkyä satunnaisina virheilmoituksina. Kotikäytössä Max Protection on kuitenkin suositeltava lähtökohta, koska se paljastaa heti, jos joku yrittää estää salatun DNS:n käytön.

Kannattaa myös huomata, että Firefoxin DoH-asetus on selainkohtainen, ei laitekohtainen. Jos käytät samalla koneella useampaa selainta, esimerkiksi Firefoxia ja Chromea rinnakkain, molemmat pitää konfiguroida erikseen. Tämä on yleinen sudenkuoppa: käyttäjä ottaa DoH:n käyttöön Firefoxissa ja olettaa virheellisesti, että se suojaa myös muun koneella tapahtuvan selauksen.

Vaihe 3-4: Secure DNS käyttöön Chromessa ja muissa Chromium-selaimissa

Vaihe 3. Chromessa, Edgessä, Bravessa ja Operassa asetus on samassa paikassa, koska ne kaikki perustuvat Chromium-moottoriin. Siirry osoitteeseen chrome://settings/security ja vieritä kohtaan Käytä suojattua DNS:ää (Use secure DNS). Kytke asetus päälle.

Vaihe 4. Valitse joko Nykyisen palveluntarjoajan kanssa, jolloin selain päivittää operaattorisi DNS:n DoH:ksi automaattisesti jos se tukee sitä, tai valitse listalta Cloudflare, Google, NextDNS, Quad9 tai CleanBrowsing. Voit myös syöttää mukautetun DoH-osoitteen, mikä on hyödyllistä jos ajat omaa NextDNS-tiliä tai yrityksen DoH-yhdyskäytävää.

# Chromium-pohjaisissa selaimissa polku on sama joka selaimessa:
chrome://settings/security
edge://settings/privacy
brave://settings/security

# Mukautetun DoH-osoitteen muoto (esimerkki NextDNS):
https://dns.nextdns.io/XXXXXX

Yritys- tai kotiverkkoympäristöissä custom-DoH-URL on käytännöllinen, koska sen avulla koko selain ohjautuu tiettyyn suodatuspolitiikkaan ilman erillistä laajennusta. NextDNS luo jokaiselle tilille oman uniikin DoH-endpointin, joten kahden eri käyttäjän tai laitteen politiikat pysyvät erillään vaikka molemmat käyttäisivät samaa palvelua.

Kun asetus on tallennettu, Chrome näyttää lyhyen vahvistuksen valitun palveluntarjoajan nimen vieressä. Jos vaihdat myöhemmin palveluntarjoajaa, aiemmin selaimen välimuistiin tallennetut DNS-vastaukset eivät automaattisesti tyhjene, joten jos haluat varman puhtaan alun testaukseen, tyhjennä selaimen DNS-välimuisti osoitteesta chrome://net-internals/#dns ennen kuin siirryt testausosion vaiheisiin.

Chromessa on hyvä tietää yksi käytännön ero Firefoxiin verrattuna: jos valitset vaihtoehdon “nykyisen palveluntarjoajan kanssa” eikä operaattorisi tue DoH:ta, selain ei anna mitään virheilmoitusta vaan hiljaa jatkaa selväkielisellä DNS:llä. Tämän takia on syytä aina tarkistaa toiminta manuaalisesti oppaan testausosiossa kuvatulla tavalla sen sijaan, että luottaisit pelkkään asetusruudun tilaan. Sama koskee Edgeä ja Bravea, koska molemmat perivät saman Chromium-pohjaisen DNS-toteutuksen.

Yrityskäytössä kannattaa myös huomioida, että osa IT-osastoista hallinnoi selainasetuksia keskitetysti ryhmäkäytännöillä (policy). Jos työkoneesi Secure DNS -asetus on harmaana eikä sitä voi muuttaa, kyse on todennäköisesti tarkoituksellisesta hallinnasta eikä viasta. Tähän palataan tarkemmin vianmääritysosiossa.

Brave-selaimessa on lisäksi oma Tor-ikkunansa (New Private Window with Tor), joka ei liity suoraan DoH-asetukseen mutta kannattaa mainita, koska käyttäjät sekoittavat sen usein samaan yksityisyyskeskusteluun. Tor-ikkuna reitittää koko liikenteen Tor-verkon kautta ja käyttää omaa DNS-ratkaisuaan, kun taas tavallinen selausikkuna käyttää tässä oppaassa asetettua DoH-yhteyttä. Näitä kahta ei kannata sekoittaa keskenään: DoH sopii arkiseen selaukseen, Tor taas tilanteisiin joissa tarvitset vahvempaa anonymiteettiä hitaamman yhteyden kustannuksella.

Vaihe 5: Salattu DNS Androidilla Private DNS -asetuksella

Android ei tue selaintason DoH:ta järjestelmätasolla, vaan käyttää DNS over TLS -protokollaa (DoT). Tekninen ero on siinä, että DoT käyttää omaa porttia 853 HTTPS-portin 443 sijaan, mutta salaustaso on käytännössä sama: kukaan verkon välissä ei näe kyselyjen sisältöä.

Vaihe 5. Avaa Asetukset → Verkko ja internet → Yksityisyys → Private DNS (polku vaihtelee hieman valmistajan mukaan Samsungilla ja Xiaomilla). Valitse Private DNS -palveluntarjoajan nimi ja kirjoita esimerkiksi 1dot1dot1dot1.cloudflare-dns.com Cloudflarea varten tai oma NextDNS-isäntänimesi. Tallenna, ja puhelin näyttää vihreän lukon merkiksi siitä, että yhteys onnistui.

# Yleisimmät Private DNS -isäntänimet Androidille
1dot1dot1dot1.cloudflare-dns.com   # Cloudflare
dns.google                          # Google Public DNS
dns.quad9.net                       # Quad9
your-id.dns.nextdns.io              # NextDNS (korvaa your-id)

Yhdistettynä Firefox for Androidin DoH-asetukseen saat kaksinkertaisen suojan: käyttöjärjestelmä salaa kaikkien sovellusten DNS-kyselyt DoT:lla, ja selain lisää vielä oman DoH-kerroksen selaustason kyselyihin, mukaan lukien salattu asiakkaan hint (ECH) tuetuissa sivustoissa.

iPhonen ja iPadin osalta tilanne on toisenlainen: iOS ei tarjoa samanlaista järjestelmätason valikkoa kuin Android, vaan salatun DNS:n käyttöönotto vaatii joko profiilin asentamisen palveluntarjoajan sovelluksesta (esimerkiksi Cloudflaren 1.1.1.1-sovellus tai NextDNS-sovellus) tai selainkohtaisen asetuksen Safarissa. Tämä kannattaa pitää mielessä, jos taloudessasi on sekä Android- että iOS-laitteita: koko kotiverkon laaja Pi-hole-ratkaisu on tässä tilanteessa usein yksinkertaisin tapa varmistaa yhtenäinen suoja laitealustasta riippumatta, koska se toimii reitittimen tasolla eikä vaadi erillistä profiilia jokaiseen laitteeseen.

Vaihe 6: systemd-resolved koko Linux-järjestelmälle

Työpöytäkäytössä kannattaa salata myös käyttöjärjestelmätason DNS, joka kattaa kaikki sovellukset, ei vain selaimen. Tässä on hyvä olla tarkka termeistä: systemd-resolved ei natiivisti tue DoH:ta, vaan DNS over TLS -protokollaa. Käytännön yksityisyyshyöty on sama, joten monissa 2026-oppaissa tämä lasketaan osaksi samaa salatun DNS -kokonaisuutta.

Tämä kerros on tärkeä erityisesti komentorivityökaluille ja taustapalveluille, jotka eivät koskaan kulje selaimen kautta. Esimerkiksi paketinhallinnan päivitykset, sähköpostiohjelmat ja monet työkalut tekevät omat DNS-kyselynsä suoraan käyttöjärjestelmän resolverin kautta, ja ilman tätä vaihetta ne jäisivät edelleen selväkielisen DNS:n varaan vaikka selain olisi jo suojattu. Tämä on syy, miksi järjestelmätason suojaus kannattaa tehdä, vaikka selaimen DoH olisi jo käytössä.

Vaihe 6. Muokkaa tiedostoa /etc/systemd/resolved.conf ja lisää seuraavat rivit Resolve-osioon. Käynnistä sitten palvelu uudelleen ja tarkista tila komennolla resolvectl status.

[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
FallbackDNS=9.9.9.9#dns.quad9.net
DNSOverTLS=yes
DNSSEC=yes

# Tallenna, sitten:
sudo systemctl restart systemd-resolved
resolvectl status

Onnistuneen ajon jälkeen resolvectl status näyttää rivin DNSOverTLS setting: yes jokaisen verkkoliitännän kohdalla. Jos haluat aidon DoH-yhteyden järjestelmätasolle DoT:n sijaan, tarvitset erillisen paikallisen proxyn, kuten seuraavassa osiossa asennettavan cloudflaredin, joka ohjaa liikenteen porttiin 5053 ja jonka systemd-resolved tai koko verkko voi osoittaa upstreamiksi.

Jos haluat, että myös työasemasi käyttää samaa cloudflared-proxya kuin kotiverkon Pi-hole, voit osoittaa systemd-resolvedin upstreamiksi paikallisen proxyn osoitteen sen sijaan, että käyttäisit ulkoisia palvelimia suoraan. Tällöin resolved.conf-tiedoston DNS-rivi muutetaan muotoon DNS=127.0.0.1:5053, ja DNSOverTLS-asetus voidaan jättää pois, koska salaus tapahtuu jo cloudflaredin ja ulkoisen resolverin välillä. Tämä yksinkertaistaa ylläpitoa, koska sinun tarvitsee hallita palveluntarjoajan valintaa vain yhdessä paikassa koko kotiverkon laajuisesti.

Huomaa myös, että NetworkManager saattaa joillain jakeluilla ylikirjoittaa resolved.conf-asetukset yhteyskohtaisesti. Jos muutokset eivät näy komennolla resolvectl status uudelleenkäynnistyksen jälkeen, tarkista onko käytössä NetworkManagerin oma DNS-hallinta komennolla nmcli general status ja tarvittaessa aseta NetworkManager käyttämään systemd-resolved-taustapalvelua DNS-hallintaan.

Vaiheet 7-9: Pi-hole ja cloudflared koko kotiverkon DoH-ratkaisuksi

Tämä on oppaan vaativin mutta myös hyödyllisin osuus, koska se suojaa jokaisen kotiverkon laitteen, mukaan lukien älyTV:t, pelikonsolit ja IoT-laitteet, joihin ei voi asentaa mitään. Pi-hole itsessään ei tue DoH:ta natiivisti, koska se on suodatinpalvelin, joka lähettää kyselyt eteenpäin. Ratkaisu on ajaa Pi-holen rinnalla paikallista cloudflared-prosessia, joka toimii DoH-proxyna.

Miksi vaivautua tähän, kun jokainen laite voisi periaatteessa hoitaa oman DoH-asetuksensa? Käytännössä moni laite ei tarjoa mitään asetusta ollenkaan: älyTV:t, tulostimet, pelikonsolit ja suurin osa IoT-laitteista käyttävät sitä DNS-palvelinta, jonka reititin niille jakaa, eikä niissä ole valikkoa DoH:n tai edes DoT:n valitsemiseen. Reunalla toimiva Pi-hole + cloudflared -yhdistelmä ratkaisee tämän kokonaan verkkotasolla: jokainen laite saa automaattisesti salatun DNS:n tietämättä siitä mitään, koska reititin ohjaa kaikki kyselyt Pi-holen kautta DHCP:n avulla.

Cloudflaredin asennus ja systemd-palvelu

Vaihe 7. Asenna cloudflared-binääri Pi-hole-laitteelle (yleensä Raspberry Pi). Lataa uusin paketti Cloudflaren viralliselta julkaisusivulta arkkitehtuurisi mukaan ja asenna se pakettienhallinnalla tai suoraan binäärinä /usr/local/bin-hakemistoon. Raspberry Pi 3, 4 ja 5 käyttävät kaikki ARM64-arkkitehtuuria, joten valitse lataussivulta oikea paketti sen mukaan, onko käytössäsi 32- vai 64-bittinen käyttöjärjestelmä.

Vaihtoehtona cloudflaredille voit käyttää myös dnscrypt-proxya, joka tukee laajempaa joukkoa palveluntarjoajia mukaan lukien Quad9 ja NextDNS suoraan ilman Cloudflare-sidonnaisuutta. Toimintaperiaate on identtinen: paikallinen proxy kuuntelee tiettyä porttia ja Pi-hole ohjaa kyselynsä sinne. Tässä oppaassa käytämme cloudflaredia, koska sen asennus on yksinkertaisin ja dokumentaatio kattavin, mutta valinta ei ole lukittu.

Vaihe 8. Luo systemd-palveluyksikkö, joka käynnistää cloudflaredin DNS-proxy-tilassa ja kuuntelee paikallista porttia 5053, jottei se törmää Pi-holen omaan porttiin 53.

# /etc/systemd/system/cloudflared.service
[Unit]
Description=cloudflared DNS over HTTPS proxy
After=network.target

[Service]
ExecStart=/usr/local/bin/cloudflared proxy-dns \
  --address 127.0.0.1 --port 5053 \
  --upstream https://1.1.1.1/dns-query \
  --upstream https://1.0.0.1/dns-query
Restart=on-failure
User=cloudflared

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now cloudflared
sudo systemctl status cloudflared

Pi-holen konfigurointi käyttämään cloudflared-proxya

Vaihe 9. Avaa Pi-holen hallintapaneeli, siirry kohtaan Settings → DNS ja poista kaikki valmiiksi valitut upstream-palvelimet käytöstä. Valitse sen sijaan Custom DNS (IPv4) ja kirjoita arvoksi 127.0.0.1#5053. Tämä ohjaa kaikki Pi-holen läpi kulkevat kyselyt paikalliseen cloudflared-prosessiin, joka puolestaan lähettää ne eteenpäin salattuna HTTPS-yhteyden yli. Muista myös poistaa valinta kohdasta “Use Conditional Forwarding”, ellet erikseen tarvitse paikallisten laitenimien selvitystä reitittimeltäsi, koska se voi ohittaa cloudflared-proxyn tietyissä tilanteissa.

Kun reitittimesi DHCP-asetuksissa osoitat kaikkien laitteiden DNS-palvelimeksi Pi-holen IP-osoitteen, koko kotiverkko käyttää salattua DNS:ää automaattisesti ilman, että yksittäisiä laitteita tarvitsee konfiguroida erikseen. Tämä on erityisen hyödyllinen ratkaisu älykodin laitteille ja vierailijaverkolle.

Onnistuneen konfiguroinnin jälkeen Pi-holen hallintapaneelin etusivulla näkyy reaaliaikainen kyselymäärä ja yläkulmassa vihreä tilamerkintä “Active” upstream-yhteyden kohdalla. Kyselylokissa (Query Log) jokaisen rivin lopussa näkyy nyt upstream-palvelimena 127.0.0.1#5053 aiemman ulkoisen IP-osoitteen sijaan, mikä on nopein tapa tarkistaa silmämääräisesti että reititys toimii halutulla tavalla ilman erillisiä komentorivityökaluja.

Vaiheet 10-12: Testaus, varmistus ja automatisointi

Vaihe 10. Varmista ensin, että cloudflared vastaa paikallisesti odotetulla tavalla ennen kuin luotat koko verkon liikenteen sen varaan. Tämä vaihe kannattaa tehdä aina ennen kuin muutat reitittimen DHCP-asetuksia, koska virheellisesti konfiguroitu proxy katkaisisi muuten koko kotiverkon internetyhteyden yhdellä kertaa.

dig @127.0.0.1 -p 5053 shattered.io

# Odotettu tuloste sisältää muun muassa:
;; ANSWER SECTION:
shattered.io.        267   IN   A    104.21.xx.xx
;; Query time: 12 msec
;; SERVER: 127.0.0.1#5053(127.0.0.1)

Vaihe 11. Kun paikallinen proxy vastaa oikein, testaa selaimesta tai puhelimesta, että DNS-kyselyt eivät enää vuoda selväkielisenä. Cloudflaren oma diagnostiikkasivu kertoo suoraan, käytätkö DoH:ta juuri nyt. Kannattaa myös testata pakettikaappauksella, jos haluat varman todisteen: työkalu kuten Wireshark ei enää näytä lainkaan selväkielisiä DNS-kyselyitä porttiin 53, koska liikenne kulkee nyt tunnetun HTTPS-portin kautta samalla tavalla kuin muukin verkkosivujen lataus.

curl -s https://1.1.1.1/cdn-cgi/trace | grep warp

# Odotettu rivi, kun DoH on aktiivinen ja liikenne kulkee Cloudflaren kautta:
warp=off
loc=FI

Vaihe 12. Automatisoi valvonta, jottei ratkaisu hajoa huomaamatta. Lisää cloudflared-palvelulle systemd-watchdog ja tarkkaile Pi-holen lokia säännöllisesti. Käytännössä tämä tarkoittaa sitä, että systemd käynnistää palvelun automaattisesti uudelleen, jos se kaatuu, ja että sinulla on yksi komento, jolla näet nopeasti onko jokin osa ketjusta lakannut vastaamasta ennen kuin kukaan taloudessa ehtii edes huomata internetin toimivan huonommin.

# Seuraa cloudflaredin lokia reaaliajassa
journalctl -u cloudflared -f

# Tarkista Pi-holen kyselytilastot komentoriviltä
pihole -c -e

Kun kaikki 12 vaihetta on tehty, sinulla on kolme itsenäistä mutta toisiaan täydentävää suojakerrosta: selaimen DoH, laitteen järjestelmätason salattu DNS ja koko kotiverkon laaja Pi-hole + cloudflared -ratkaisu. Jokainen kerros toimii, vaikka muut olisivat pois päältä, mikä tekee kokonaisuudesta vikasietoisen.

Käytännön esimerkki havainnollistaa kokonaisuutta: kannettava tietokone käynnistyy kotiverkossa, jossa reititin jakaa Pi-holen osoitteen DNS-palvelimeksi DHCP:llä. Kaikki koneen sovellukset, myös ne jotka eivät osaa itse DoH:ta, saavat automaattisesti salatun DNS:n Pi-holen ja cloudflaredin kautta. Kun sama kannettava viedään kahvilaan tai lentokentälle, Firefoxin ja Chromen omat DoH-asetukset ottavat vastuun, koska Pi-hole ei enää ole reitin varrella. Lopputuloksena DNS-kyselyt kulkevat salattuna riippumatta siitä, missä verkossa laite kulloinkin on.

Vaihtoehto Raspberry Pille: DoH suoraan reitittimessä

Jos reitittimessäsi pyörii OpenWrt tai vastaava avoimen lähdekoodin laiteohjelmisto, et välttämättä tarvitse erillistä Raspberry Piitä ollenkaan. Sama cloudflared-binääri tai kevyempi vaihtoehto, kuten https-dns-proxy-paketti OpenWrtin omasta pakettivarastosta, voidaan asentaa suoraan reitittimeen. Tällöin koko kotiverkon DNS kulkee salattuna yhdellä laitteella ilman erillistä Pi-holea, tosin menetät samalla Pi-holen mainos- ja seurantasuodatuksen, ellet asenna sitäkin rinnalle.

Kaupallisissa kuluttajareitittimissä, kuten uusimmissa ASUS- ja TP-Link-malleissa, DoH-tuki on usein sisäänrakennettu valmiiksi hallintapaneeliin nimellä “DNS over HTTPS” tai “Encrypted DNS”. Tällöin riittää valita palveluntarjoaja pudotusvalikosta ilman komentorivin käyttöä ollenkaan. Tämä on selvästi helpoin reitti niille, jotka eivät halua ylläpitää erillistä Raspberry Pi -laitetta, mutta se antaa vähemmän kontrollia ja läpinäkyvyyttä siihen, mitä kyselyjä verkosta todella lähtee, koska reitittimen valmistaja hallinnoi toteutusta.

Kolmas vaihtoehto on ajaa koko ratkaisu virtuaalikoneessa tai kontissa NAS-laitteella, jos sellainen on jo käytössä kotiverkossa. Docker-kontti, jossa on sekä Pi-hole että cloudflared, voidaan pystyttää muutamassa minuutissa valmiilla compose-tiedostolla, ja tämä säästää erillisen fyysisen laitteen hankinnalta jos NAS on joka tapauksessa aina päällä.

Kaikissa kolmessa vaihtoehdossa, Raspberry Pi, reititin tai NAS, periaate pysyy samana: tarvitset yhden aina päällä olevan laitteen, joka toimii koko verkon DNS-yhdyskäytävänä. Valinta riippuu lähinnä siitä, mitä laitteistoa sinulla on jo valmiina, ja kuinka paljon haluat käyttää aikaa ylläpitoon. Raspberry Pi -ratkaisu on joustavin ja parhaiten dokumentoitu, minkä takia se on tämän oppaan pääpolku, mutta yksikään näistä vaihtoehdoista ei ole väärä valinta.

DoH-palveluntarjoajien vertailu 2026

Palveluntarjoajan valinta vaikuttaa siihen, kuka näkee DNS-kyselysi lopulta, vaikka ne kulkisivatkin salattuna matkalla. Alla neljä yleisintä vaihtoehtoa, joita 2026-oppaat ja palveluntarjoajien oma dokumentaatio suosittelevat.

Palveluntarjoaja	DoH-osoite	Tuetut protokollat	Erikoisominaisuus
Cloudflare 1.1.1.1	https://1.1.1.1/dns-query	DoH, DoT	Nopeus, ei lokitietojen myyntiä kolmansille
NextDNS	https://dns.nextdns.io/<id>	DoH, DoT, DoQ, DNSCrypt	Uniikki endpoint per tili, laitekohtaiset säännöt
Quad9	https://dns.quad9.net/dns-query	DoH, DoT	Automaattinen haittaohjelma- ja tietojenkalastelusuodatus
Google Public DNS	https://dns.google/dns-query	DoH, DoT	Laaja globaali infrastruktuuri, hyvä saatavuus

Quad9 sopii, jos haluat automaattisen suojan tunnettuja haittaohjelmadomaineja vastaan ilman erillistä konfigurointia. NextDNS taas on paras valinta, jos haluat laitekohtaisia sääntöjä ja tarkkaa näkyvyyttä siihen, mitä kyselyjä verkostasi lähtee. Cloudflare on useimmille käyttäjille yksinkertaisin ja nopein oletusvalinta.

Kannattaa myös huomioida lokipolitiikka valintaa tehdessä. Cloudflare on julkisesti sitoutunut siihen, ettei se myy DNS-kyselytietoja mainostajille, ja ulkopuolinen tilintarkastaja on toistuvasti tarkastanut tämän käytännön. Google Public DNS sen sijaan yhdistetään useammin muuhun Googlen dataekosysteemiin, mikä kannattaa huomioida jos DoH:n käyttöönoton tavoite on nimenomaan vähentää yhden yrityksen näkyvyyttä selaustottumuksiisi. NextDNS antaa tähän eniten kontrollia, koska voit itse päättää, kuinka pitkään ja missä muodossa kyselylokit säilytetään tai poistetaanko ne kokonaan reaaliajassa.

Hintakin kannattaa ottaa huomioon, vaikka kaikki neljä esiteltyä palveluntarjoajaa tarjoavat ilmaisen perustason. Cloudflare, Quad9 ja Google Public DNS ovat kokonaan maksuttomia yksityiskäytössä ilman rajoituksia. NextDNS puolestaan rajoittaa ilmaistilin kyselymäärää kuukausitasolla, minkä jälkeen tarvitaan maksullinen tilaus, mikä kannattaa huomioida jos taloudessasi on paljon laitteita jotka kaikki lähettävät kyselyjä saman tilin kautta.

DNS over HTTPS vs DNS over TLS vs perinteinen DNS

DoH ja DoT sekoittuvat usein keskenään, koska molemmat salaavat kyselyt, mutta niissä on käytännön eroja, jotka vaikuttavat siihen, kuinka helppo niitä on estää verkkotasolla.

Ominaisuus	Perinteinen DNS	DNS over TLS (DoT)	DNS over HTTPS (DoH)
Portti	UDP/TCP 53	TCP 853	TCP 443
Salaus	Ei ole	TLS	TLS HTTPS-kerroksen sisällä
Erottuu muusta liikenteestä	Kyllä, helppo tunnistaa	Kyllä, oma portti	Ei, näyttää tavalliselta HTTPS:ltä
Verkkotason esto	Helppo	Kohtalaisen helppo (portti 853)	Vaikea ilman koko HTTPS-liikenteen estoa
Yleisin käyttökohde	Vanhat järjestelmät	Android, systemd-resolved	Selaimet, Pi-hole + cloudflared

Juuri se, että DoH kulkee samassa portissa kuin muu HTTPS-liikenne, tekee siitä vaikean estää operaattori- tai palomuuritasolla ilman koko sivuston tai palvelun estämistä. Tämä on samalla sekä etu yksityisyydelle että syy, miksi jotkin yritysverkot vaativat erikseen luvan DoH:n käyttöön.

Käytännössä tämä tarkoittaa myös, että DoH ja DoT täydentävät toisiaan eri tasoilla verkkopinoa. DoT sopii hyvin tilanteisiin, joissa haluat, että verkonvalvoja näkee edelleen, että DNS-liikennettä kulkee, muttei sen sisältöä (tämä helpottaa esimerkiksi yritysverkkojen kapasiteettisuunnittelua). DoH taas sopii tilanteisiin, joissa haluat maksimaalisen huomaamattomuuden, koska liikenne sulautuu muuhun selailuun. Kotikäyttäjälle tämä ero on harvoin ratkaiseva, mutta se selittää miksi Android valitsi DoT:n järjestelmätasolle ja selainvalmistajat valitsivat DoH:n omaan kerrokseensa.

Vertailutaulukko kannattaa lukea rinnakkain edellisen palveluntarjoajataulukon kanssa: portin ja näkyvyyden erot vaikuttavat siihen, minkä protokollan valitset kullekin laitteelle, kun taas palveluntarjoajan valinta vaikuttaa siihen, kuka näkee kyselyt salauksen toisessa päässä. Molemmat päätökset yhdessä muodostavat kokonaiskuvan siitä, kuinka yksityinen DNS-liikenteesi lopulta on.

Yleisimmät sudenkuopat DNS over HTTPS -käyttöönotossa

Useimmat käyttöönoton ongelmat eivät johdu itse DoH-tekniikasta vaan siitä, että eri kerrokset (selain, käyttöjärjestelmä, reititin, Pi-hole) jäävät osittain vanhoihin asetuksiinsa, kun uutta kerrosta lisätään päälle. Tässä kuusi tilannetta, jotka toistuvat käyttäjien kokemuksissa toistuvasti. Kannattaa myös pitää mielessä, että moni näistä ongelmista ratkeaa yksinkertaisesti palauttamalla yksi kerros kerrallaan oletusasetuksiin ja lisäämällä muutokset takaisin vaihe kerrallaan, kunnes löydät kohdan joka rikkoo toiminnan.

1. Kaksi päällekkäistä DoH-kerrosta kilpailevat. Jos selaimen DoH ja Pi-hole + cloudflared molemmat on aktivoitu ilman koordinointia, kyselyt saattavat kiertää tarpeettoman monta kertaa ja hidastaa sivujen latautumista. Käytännössä tämä ei riko toimintaa, mutta lisää tarpeetonta viivettä jokaiseen uuteen verkkotunnukseen. Ratkaisu on joko jättää selaimen DoH pois päältä kotiverkossa tai osoittaa se samaan paikalliseen resolveriin kuin Pi-hole käyttää.
2. Reitittimen DHCP jää osoittamaan vanhaa DNS-palvelinta. Pi-holen käyttöönotto ei auta koko verkolle, jos reititin jakaa yhä operaattorin oman DNS-osoitteen laitteille. Tämä on yleisin syy siihen, että käyttäjä on tehnyt kaiken oikein Pi-holessa, mutta laitteet eivät silti käytä sitä. Tarkista reitittimen DHCP-asetuksista, että jaettava DNS-osoite osoittaa Pi-holen kiinteään IP-osoitteeseen.
3. Cloudflaredin porttikonflikti Pi-holen kanssa. Jos molemmat kuuntelevat porttia 53, palvelu ei käynnisty. Muista käyttää eri porttia, esimerkiksi 5053, cloudflaredille, ja varmista ettei mikään muu palvelu, kuten systemd-resolved, ole jo varannut samaa porttia laitteella.
4. Firewall estää lähtevän portin 443 cloudflaredilta. Ilman avointa lähtevää yhteyttä DoH-proxy ei pääse ollenkaan ulos, ja koko kotiverkon DNS lakkaa toimimasta. Tämä on erityisen yleistä yritysverkoissa, joissa lähtevä liikenne on rajattu sallittuihin osoitteisiin.
5. Unohdetaan päivittää systemd-palvelun käyttäjäoikeudet. Jos cloudflared-palvelu ajetaan roottina ilman syytä, se on tarpeeton tietoturvariski paikallisessa verkossa. Luo palvelulle oma rajoitettu käyttäjätunnus systemd-yksikön User-riville sen sijaan, että jättäisit oletusarvon.
6. DNSSEC jätetään pois, vaikka DNSOverTLS on päällä. Salaus ilman validointia ei estä väärennettyjä vastauksia, joten molemmat kannattaa ottaa käyttöön yhdessä systemd-resolvedissa. Pelkkä salaus suojaa kuuntelulta, mutta ei suojaa siltä, että joku aktiivinen välikäsi väärentäisi vastauksen.

Vianmääritys: 8 yleisintä ongelmaa ja ratkaisua

Kun jokin osa ketjusta ei toimi odotetusti, kannattaa edetä systemaattisesti alimmalta tasolta ylöspäin: ensin paikallinen proxy, sitten Pi-hole, sitten reititin, ja vasta lopuksi yksittäiset laitteet. Tässä kahdeksan tilannetta, joihin törmää useimmin.

1. Sivut eivät lataudu käyttöönoton jälkeen. Tarkista, että valittu DoH-palvelin on oikeasti käytössä ja saatavilla. Testaa komennolla curl -s https://1.1.1.1/dns-query, että palvelin palauttaa vastauksen eikä aikakatkaisua.
2. Firefox näyttää tyhjän DoH-asetusruudun. Kyseessä on ennen versiota 147.0.3 esiintynyt tunnettu bugi. Päivitä selain uusimpaan versioon, jolloin asetusruutu palautuu näkyviin normaalisti.
3. Chrome ei anna valita Secure DNS -asetusta. Yrityksen hallinnoima laite tai ryhmäkäytäntö (policy) voi lukita asetuksen. Tarkista osoitteesta chrome://policy, onko DnsOverHttpsMode-käytäntö asetettu pakotetusti.
4. Android-puhelin näyttää “Ei voi muodostaa yhteyttä” Private DNS -kohdassa. Isäntänimessä on kirjoitusvirhe, tai operaattorin verkko estää portin 853. Kokeile eri WiFi-verkkoa varmistaaksesi, onko syy laitteessa vai verkossa.
5. cloudflared.service ei käynnisty. Aja journalctl -u cloudflared -e ja tarkista porttikonflikti tai puuttuva binääri polusta /usr/local/bin/cloudflared. Usein syynä on myös puuttuva suoritusoikeus, jonka korjaa chmod +x.
6. Pi-hole näyttää kaikki kyselyt epäonnistuneina. Custom DNS -kenttä on todennäköisesti väärin kirjoitettu. Oikea muoto on 127.0.0.1#5053, ei 127.0.0.1:5053, koska Pi-hole käyttää risuaitaa portin erottimena kaksoispisteen sijaan.
7. resolvectl status ei näytä DNSOverTLS: yes. Tiedosto /etc/systemd/resolved.conf ei ehkä latautunut. Varmista, ettei rinnakkainen resolved.conf.d/-hakemisto ylikirjoita asetusta jollain toisella arvolla.
8. Nopeus hidastuu selvästi DoH:n käyttöönoton jälkeen. Vaihda maantieteellisesti lähempään palveluntarjoajaan tai testaa eri resolveria. Quad9 ja Cloudflare toimivat usein nopeammin Pohjoismaissa kuin kauempana sijaitsevat palvelimet, koska niillä on paikallisia solmuja Suomessa ja naapurimaissa.

DNS-lokit ja tietosuoja: mitä operaattorit näkevät Suomessa

Suomalaiset ja pohjoismaiset operaattorit käsittelevät DNS-lokeja henkilötietoina, kun ne voidaan yhdistää yksittäiseen liittymään tai IP-osoitteeseen, ja tämä käsittely kuuluu GDPR:n piiriin siinä missä muukin asiakastiedon käsittely. Käytännössä tämä ei estä lokien keräämistä, mutta se asettaa operaattorille velvoitteita säilytysajoista ja käyttötarkoituksista. Salaamalla DNS-kyselyt DoH:lla siirrät päätösvallan siitä, kuka näkee selaustottumuksesi, itsellesi: valitset palveluntarjoajan, jonka lokipolitiikkaan luotat, sen sijaan että oletusarvoisesti luottaisit operaattoriisi.

Tämä on erityisen ajankohtaista, koska valvontaviranomaiset ovat kiristäneet otettaan tietosuojan noudattamisesta myös julkishallinnossa 2026 aikana, mikä näkyy suoraan sakkojen kasvuna. Yksityishenkilön kannalta relevanttia on se, että vaikka oma operaattorisi noudattaisi lakia tarkasti, DNS-lokit ovat silti arvokasta dataa, joka voi päätyä osaksi laajempaa markkinointiprofiilia tai kolmannen osapuolen pyyntöä. DoH ei muuta tätä oikeudellista tilannetta, mutta se vähentää käytännössä sitä, kuinka moni taho ylipäätään pääsee käsiksi raakadataan.

Kannattaa myös muistaa, että valitsemasi DoH-palveluntarjoaja astuu tavallaan operaattorisi tilalle tässä ketjussa. Jos vaihdat DNS-kyselyt Cloudflaren tai NextDNS:n käsiteltäväksi, olet edelleen riippuvainen siitä, että kyseinen yritys noudattaa omaa tietosuojaselostettaan. Tästä syystä palveluntarjoajan valinta ei ole pelkkä tekninen päätös, vaan myös luottamuskysymys: kannattaa lukea palveluntarjoajan julkinen lokipolitiikka ja mahdollinen ulkopuolinen tarkastusraportti ennen sitoutumista.

Edistyneet vinkit: DNS over HTTPS tuotantoympäristössä

Kun perusasennus toimii, kannattaa miettiä muutamaa lisäkerrosta, jotka tekevät ratkaisusta kestävämmän arkikäytössä. Useamman upstream-palvelimen käyttö cloudflaredin konfiguraatiossa antaa varmistuksen, jos yksi resolveri katkeaa hetkellisesti. Jos ylläpidät reititintä yritys- tai vuokra-asuntoverkossa, harkitse Cloudflaren dokumentoimaa yritystason Gateway-ratkaisua, joka antaa jokaiselle työntekijälle tai laitteelle oman DoH-alitunnuksen keskitetyn hallinnan alla.

Toiseksi kannattaa harkita erillistä vierailijaverkkoa, jolle asetetaan sama DoH-suodatus kuin pääverkolle. Näin vieraat saavat automaattisesti perussuojan, etkä joudu antamaan heille pääsyä muuhun kotiverkkoosi.

Kolmanneksi kannattaa erottaa lokitus ja seuranta selkeästi. Pi-holen kyselytilastot kertovat vain, mitä domaineja kysyttiin, ei sitä mihin IP-osoitteeseen yhteys lopulta muodostui, joten se ei korvaa täydellistä liikenteen valvontaa. Jos tarvitset syvempää näkyvyyttä, yhdistä Pi-holen loki erilliseen valvontaratkaisuun tai vähintään ajastettuun varmuuskopiointiin, jotta konfiguraatio ei katoa laitteen vikaantuessa.

Muista myös Encrypted Client Hello (ECH). DoH salaa DNS-kyselyn, mutta ilman ECH-tukea itse TLS-kättely paljastaa edelleen kohdesivuston nimen SNI-kentässä. Nykyiset Firefox- ja Chrome-versiot tukevat ECH:tä yhä useammalla sivustolla, ja se kannattaa pitää päällä about:config-asetuksesta Firefoxissa, jotta koko yhteyden muodostus, ei vain DNS-kysely, pysyy salassa ulkopuolisilta.

Jos rakennat ratkaisua useammalle kotitaloudelle tai pienyritykselle, harkitse kahta rinnakkaista Pi-hole-instanssia kuormantasauksella. Yhden laitteen varassa oleva DNS on aina yksittäinen vikapiste, ja toinen Raspberry Pi maksaa murto-osan siitä, mitä käyttökatko aiheuttaisi arjessa.

Viimeisenä vinkkinä kannattaa dokumentoida oma konfiguraatio heti käyttöönoton yhteydessä, ei vasta kun jotain menee rikki. Yksinkertainen tekstitiedosto, johon kirjaat valitun palveluntarjoajan, käytetyn portin, cloudflaredin komentorivin parametrit ja Pi-holen asetukset, säästää helposti tunteja seuraavalla kerralla kun laite vaihtuu tai konfiguraatio pitää palauttaa varmuuskopiosta. Pi-holen oma Teleporter-vientitoiminto hoitaa suodatuslistat ja asetukset yhdellä komennolla, mutta cloudflaredin systemd-yksikkö ja avaimet kannattaa varmuuskopioida erikseen.

Kun kaikki kerrokset on rakennettu ja testattu, koko järjestelmä vaatii yllättävän vähän ylläpitoa jatkossa. Cloudflared ja Pi-hole päivittyvät useimmiten automaattisesti, ja ainoa säännöllinen tehtävä on tarkistaa muutaman kuukauden välein, että kaikki palvelut ovat yhä käynnissä ja että valitun palveluntarjoajan DoH-osoite ei ole muuttunut. Tämän oppaan avulla rakennettu kokonaisuus, selain, käyttöjärjestelmä ja koko kotiverkko yhdessä, kattaa käytännössä kaikki tavat joilla laitteesi tekevät DNS-kyselyitä arjessa.

Usein kysytyt kysymykset DNS over HTTPS -käyttöönotosta

Hidastaako DNS over HTTPS internetyhteyttä?
Käytännössä ero on mitätön nykyaikaisilla resolvereilla. Cloudflaren ja Quad9:n palvelimet vastaavat tyypillisesti alle 15 millisekunnissa Pohjoismaista käsin, mikä ei näy arkikäytössä. Ensimmäinen kysely uuteen domainiin voi olla hieman hitaampi TLS-kättelyn takia, mutta selaimet ja käyttöjärjestelmät välimuistittavat vastaukset heti, joten toistuvat käynnit samalle sivustolle eivät kärsi.

Tekeekö DoH minusta anonyymin verkossa?
Ei. DoH salaa vain DNS-kyselyt, ei IP-osoitettasi tai sivustojen sisältöä. Anonymiteettiin tarvitaan lisäksi VPN tai Tor-verkko.

Voiko DNS over HTTPS ja DNS over TLS olla käytössä yhtä aikaa?
Kyllä, ja usein juuri niin kannattaa tehdä: Android käyttää DoT:tä järjestelmätasolla, ja selain voi lisäksi käyttää omaa DoH-yhteyttään.

Miksi Pi-hole ei tue DoH:ta suoraan?
Pi-hole on suunniteltu kevyeksi suodatinpalvelimeksi eikä sisällä omaa DoH-asiakasta, joten se tarvitsee rinnalleen erillisen proxyn, kuten cloudflaredin tai dnscrypt-proxyn. Tämä pitää Pi-holen itsensä yksinkertaisena ja keskittyneenä yhteen tehtävään, suodatukseen, kun taas salauksesta vastaa erikoistunut työkalu.

Estääkö yritysverkko tai koulun WiFi DoH:n käytön?
Osa hallinnoiduista verkoista lukitsee selainasetukset ryhmäkäytännöillä nimenomaan siksi, ettei DoH:ta voi ohittaa sisältösuodatusta. Tarkista organisaatiosi käytäntö ennen käyttöönottoa työlaitteella.

Kannattaako valita Cloudflare, Quad9 vai NextDNS?
Cloudflare on nopein oletusvalinta useimmille, Quad9 tarjoaa automaattisen haittaohjelmasuodatuksen, ja NextDNS sopii, jos haluat tarkkoja laitekohtaisia sääntöjä ja omaa endpointia.

Miten tarkistan, että DoH todella on käytössä eikä vain asetuksissa?
Käytä curl -s https://1.1.1.1/cdn-cgi/trace -komentoa tai selaimen sisäistä DNS-diagnostiikkasivua, jotka näyttävät suoraan aktiivisen resolverin.

Toimiiko tämä opas myös reitittimessä, jossa on oma laiteohjelmisto kuten OpenWrt?
Kyllä periaatteessa samalla logiikalla: asennat cloudflaredin tai dnscrypt-proxyn reitittimeen itseensä sen sijaan että käyttäisit erillistä Raspberry Piitä, jolloin koko verkon DNS kulkee salattuna suoraan reitittimen kautta.

Mitä teen, jos operaattorini estää DoH-liikenteen kokonaan?
Tämä on harvinaista Suomessa, mutta jos näin käy, kokeile vaihtaa DoH-palveluntarjoajaa tai käyttää mukautettua porttia. Koska DoH kulkee tavallisessa HTTPS-portissa 443, sen täydellinen estäminen ilman muun HTTPS-liikenteen katkaisemista on operaattoreille käytännössä vaikeaa.

Tämän oppaan vaiheet eivät vaadi mitään yksittäistä maksullista palvelua, ja jokainen esitelty palveluntarjoaja tarjoaa toimivan ilmaistason yksityiskäyttöön. Suurin osa ajasta kuluu Pi-hole- ja cloudflared-osuuteen, mutta juuri se osuus tuo suurimman hyödyn, koska se suojaa koko kotiverkon kerralla ilman että jokaista laitetta pitää konfiguroida erikseen. Jos et ehdi tehdä kaikkea kerralla, aloita selaimista ja Androidista, ja palaa Pi-hole-osuuteen myöhemmin kun ehdit varata sille rauhassa ajan. Pienikin osittainen käyttöönotto, esimerkiksi pelkkä selaimen DoH, on jo selvä parannus verrattuna tilanteeseen jossa kaikki DNS-kyselyt kulkevat yhä selväkielisenä.

Aiheeseen liittyvää

• Firefoxin yksityisyysasetukset: 14 vaihetta selaimen kovennukseen
• Salattu sähköposti 12 vaiheessa: Outlook, Gmail ja PGP
• WireGuard VPN Linuxille: oma palvelin 12 vaiheessa
• pfSense vs OPNsense: mitä valita kotiverkon reunalle
• NordVPN vs ProtonVPN vs Mullvad: vertailu
• Lisää yksityisyysoppaita ja -uutisia

Lähteet ja lisälukemista: Mozilla Support: DNS over HTTPS, Cloudflare 1.1.1.1 -käyttöönotto, Pi-hole: cloudflared-opas, NextDNS, Quad9-palveluosoitteet, systemd-resolved.conf-dokumentaatio ja Android Private DNS -tuki.