Cloudflare veti maton Pi-holen alta helmikuussa 2026: yhtiö poisti cloudflared-työkalusta DNS over HTTPS -tuen, jota tuhannet kotikäyttäjät ja pienyritykset olivat käyttäneet vuosia salatakseen DNS-liikenteensä reitittimen takana. Vanhat oppaat, jotka neuvoivat asentamaan pelkän cloudflared-daemonin ja osoittamaan Pi-holen siihen, eivät enää toimi uusissa asennuksissa. Jos etsit tuoretta, toimivaa tapaa salata koko kotiverkkosi DNS-kyselyt yhdellä Raspberry Pi:llä tai Docker-kontilla, tämä opas käy läpi nykyisen, syyskuussa 2026 toimivan ratkaisun: Pi-hole 6.x yhdistettynä dnscrypt-proxyyn tai Unboundiin.

Erona moneen selain- tai käyttöjärjestelmätason DoH-oppaaseen tämä artikkeli keskittyy verkkotason ratkaisuun: kun DNS salataan Pi-holessa, suoja kattaa jokaisen laitteen kotiverkossa, älytelevisiosta ja pelikonsolista kannettaviin ja puhelimiin, ilman että jokaiseen laitteeseen pitää erikseen asentaa mitään. Käymme läpi asennuksen Raspberry Pi 5:llä ja Docker-kontissa, vertailemme dnscrypt-proxyta ja Unboundia, ja näytämme miten testaat, että salaus todella toimii.

Miksi Pi-hole ja DNS over HTTPS kannattaa yhdistää vuonna 2026

Pi-hole on suosituin itse ylläpidetty mainos- ja seurantasuodatin, mutta se ei koskaan ole salannut DNS-liikennettä itsessään. Pi-hole toimii DNS-välityspalvelimena (forwarding resolver): se ottaa vastaan laitteiden DNS-kyselyt, suodattaa mainosdomainit pois ja välittää loput eteenpäin ylävirran nimipalvelimelle. Jos tuo ylävirran yhteys kulkee tavallisena UDP-porttina 53, kaikki DNS-kyselysi näkyvät selväkielisenä jokaiselle, joka pääsee käsiksi verkkoliikenteeseesi: internetpalveluntarjoajalle, avoimen WLAN-verkon muille käyttäjille tai kenelle tahansa reitin varrella.

Tämä ero on olennainen ymmärtää: Pi-hole itsessään ei tue DNS over HTTPS- tai DNS over TLS -protokollaa, vaan se pitää yhdistää erilliseen ratkaisuun, joka hoitaa salatun yhteyden ylävirtaan. Ennen helmikuuta 2026 yleisin tapa oli asentaa Cloudflaren cloudflared-daemoni rinnalle ja osoittaa Pi-holen mukautettu DNS-osoite paikalliseen 127.0.0.1#5053-porttiin. Cloudflare kuitenkin poisti tämän DoH-proxy-toiminnon cloudflared-julkaisuista, mikä pakotti yhteisön siirtymään vaihtoehtoihin. Käytännössä kaksi työkalua on noussut standardiksi: dnscrypt-proxy, joka tukee sekä DNSCrypt- että DoH-protokollaa ja on helppo pystyttää Dockerissa, sekä Unbound, joka toimii paikallisena rekursiivisena resolverina ja voidaan asettaa käyttämään DNS over TLS -yhteyttä ylävirran palvelimiin.

Suomalaiselle ja pohjoismaiselle lukijalle tämä on ajankohtaista kahdesta syystä. Ensinnäkin moni kotitalous ja pienyritys käyttää yhä oletusarvoista, salaamatonta DNS-yhteyttä operaattorin nimipalvelimiin, vaikka selainkohtainen DoH on jo yleistynyt. Toiseksi verkkotason salaus suojaa myös laitteita, joissa ei ole omaa selainta tai käyttöjärjestelmätason DoH-tukea, kuten älykodin sensoreita, suoratoistolaatikoita ja muita IoT-laitteita. Näissä laitteissa DNS-kyselyt kulkevat usein täysin suojaamattomina, ellei verkkotason ratkaisua ole käytössä.

Mitä DNS-kysely paljastaa ilman salausta

Kun laite avaa verkkosivun tai sovelluksen, ensimmäinen asia joka tapahtuu on DNS-kysely: laite kysyy nimipalvelimelta, mihin IP-osoitteeseen esimerkiksi pankki.fi tai jokin muu palvelu osoittaa. Salaamattomassa UDP 53 -liikenteessä tämä kysely lähtee selväkielisenä pakettina verkkoon. Kuka tahansa, joka näkee liikenteen reitin varrella, näkee myös minkä sivuston tai palvelun käyttäjä avaa, vaikka itse sivulataus tapahtuisikin HTTPS-salattuna. DNS-kysely on siis metatieto, joka paljastaa selaustottumukset, vaikka sisältö pysyisi salattuna. Tämä on juuri se aukko, jonka DoH ja DoT tukkivat: kysely pakataan TLS-yhteyden sisään, jolloin ulkopuolinen näkee vain, että laite kommunikoi tietyn DoH-palvelimen kanssa, ei mitä domaineja se kysyy.

Mitä muuttui helmikuussa 2026

Cloudflaren cloudflared-työkalu oli vuosia kätevin tapa lisätä DoH-tuki Pi-holen rinnalle, koska se tarjosi valmiin, kevyen DoH-proxyn ilman erillistä konfigurointia. Kun Cloudflare päätti keskittää DoH-toiminnallisuutensa muualle ja poisti sen cloudflared-julkaisuista, moni vanha, muuten hyvin toimiva ohje muuttui käyttökelvottomaksi yhdessä yössä. Pi-holen oma dokumentaatio kuvaa yhä cloudflared-pohjaista reittiä, mutta sen soveltaminen uusimpiin cloudflared-versioihin ei enää tuota toimivaa DoH-yhteyttä. Käytännön seuraus on se, että kotikäyttäjien on pitänyt opetella uusi työkalu, ja tässä oppaassa käytetty dnscrypt-proxy on noussut yhteisön suosituimmaksi korvaajaksi, koska sen konfigurointi muistuttaa läheisesti vanhaa cloudflared-mallia.

Esitiedot ja tarvittavat versiot

Ennen kuin aloitat, varmista että sinulla on seuraavat asiat kunnossa. Tämä opas on testattu ja kirjoitettu ajankohtana, jolloin uusimmat vakaat versiot ovat Pi-hole 6.x, Docker Engine 27.x ja dnscrypt-proxy 2.1.x -sarja.

  • Raspberry Pi 4 tai Pi 5 (vähintään 2 Gt RAM-muistia), tai mikä tahansa Linux-palvelin/kotipalvelin, jossa Docker toimii
  • Raspberry Pi OS Lite (64-bit) tai Debian/Ubuntu-pohjainen käyttöjärjestelmä
  • Docker Engine, uusin vakaa versio, sekä Docker Compose -laajennus
  • Pi-hole, ajetaan Docker-kontissa pihole/pihole-image-versiosta, joka tukee Pi-hole 6.x -sarjaa
  • dnscrypt-proxy, versio 2.1.x, tai vaihtoehtoisesti Unbound, uusin pakettivarastossa oleva versio
  • Kiinteä, staattinen IP-osoite kotiverkossasi Pi-holen isäntäkoneelle
  • Pääsy reitittimen hallintapaneeliin DHCP-asetusten muokkaamista varten
  • Peruskäyttötaidot komentorivillä ja tekstieditorilla (nano tai vim)
  • Noin 90 minuuttia aikaa koko asennukseen ja testaukseen

Jos sinulla ei ole Raspberry Pi:tä, tämä toimii yhtä hyvin virtuaalikoneessa, Hetzner- tai muulla VPS-palvelimella kotiverkon sisällä, tai vaikka NAS-laitteessa, joka tukee Dockeria. Tärkeintä on, että laite on aina päällä, koska se toimii koko kotiverkon nimipalvelimena.

Docker vai natiiviasennus: kumpi kannattaa valita

Osa vanhemmista Pi-hole-oppaista asentaa Pi-holen suoraan käyttöjärjestelmään yhdellä asennusskriptillä, ilman Dockeria. Tämä toimii yhä, mutta tässä oppaassa suositellaan Docker-pohjaista reittiä kolmesta syystä. Ensinnäkin, kun sekä Pi-hole että dnscrypt-proxy (tai Unbound) ajetaan omissa konteissaan, kumpaakin voi päivittää, käynnistää uudelleen tai poistaa vaikuttamatta toiseen palveluun. Natiiviasennuksessa nämä kaksi osaa nivoutuvat samaan käyttöjärjestelmään, jolloin virheenjäljitys on hankalampaa, koska muutokset toiseen palveluun voivat vaikuttaa toiseen odottamattomilla tavoilla.

Toiseksi, Docker Compose -tiedosto toimii samalla dokumentaationa koko asennuksesta. Kun kaikki asetukset, portit ja verkkomääritykset ovat yhdessä tekstitiedostossa, koko ympäristön voi siirtää toiselle koneelle tai palauttaa varmuuskopiosta kopioimalla muutaman tiedoston, ilman että tarvitsee muistaa, mitä asennusskriptejä ajettiin missäkin järjestyksessä alun perin. Kolmanneksi, Docker eristää palvelut toisistaan ja isäntäjärjestelmästä, mikä pienentää hyökkäyspintaa: jos jokin kontti altistuu haavoittuvuudelle, vahinko rajoittuu pääsääntöisesti kyseiseen konttiin eikä leviä suoraan isäntäkoneen käyttöjärjestelmään. Tämän vuoksi loppuosa oppaasta nojaa kokonaan Docker Compose -malliin natiiviasennuksen sijaan.

Vaihe 1: Valmistele isäntäkone ja asenna Docker

Aloita päivittämällä käyttöjärjestelmä ja asentamalla Docker, jos sitä ei vielä ole. Docker-pohjainen asennus on suositeltavin tapa vuonna 2026, koska se pitää Pi-holen, dnscrypt-proxyn ja mahdollisen Unboundin siististi erillään isäntäjärjestelmästä ja helpottaa päivityksiä.

sudo apt update && sudo apt full-upgrade -y
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER
newgrp docker
docker --version
docker compose version

Varmista, että molemmat komennot palauttavat versionumeron ilman virheitä. Jos docker --version epäonnistuu, kirjaudu ulos ja takaisin sisään, jotta ryhmäjäsenyys astuu voimaan. Luo tämän jälkeen hakemisto, johon projektin tiedostot tallennetaan.

mkdir -p ~/pihole-doh/{pihole/etc-pihole,pihole/etc-dnsmasq.d,dnscrypt-proxy}
cd ~/pihole-doh

Vaihe 2: Valitse dnscrypt-proxy vai Unbound, kumpi sopii sinulle

Ennen kuin kirjoitat yhtään konfiguraatiotiedostoa, kannattaa päättää, kumpaa reittiä lähdet. Molemmat ratkaisevat saman ongelman eri tavalla, ja valinta vaikuttaa siihen, mitä loppuosassa opasta seuraat.

Ominaisuusdnscrypt-proxyUnbound
SalausprotokollaDoH ja DNSCrypt, valittavissa julkisten palveluntarjoajien listaltaDoT (DNS over TLS) ylävirran palvelimiin, tai täysin rekursiivinen ilman kolmatta osapuolta
Riippuvuus ulkoisesta palvelustaKyllä, käyttää valitsemaasi julkista DoH-resolveria (esim. Cloudflare, Quad9)Ei välttämättä, voi kysyä suoraan juuripalvelimilta ilman kolmatta osapuolta
Asennuksen monimutkaisuusMatala, valmis Docker-image ja toml-konfiguraatioKeskitasoinen, vaatii root-vyöhyketiedoston ja enemmän asetuksia
LatenssiYleensä pieni, riippuu valitusta ylävirran palvelimestaVoi olla suurempi täysin rekursiivisessa tilassa, koska kyselyt kulkevat useamman palvelimen kautta
Sopii parhaitenKäyttäjille, jotka luottavat tiettyyn DoH-palveluntarjoajaan (Cloudflare, Quad9, Mullvad)Käyttäjille, jotka haluavat minimoida riippuvuuden kolmansista osapuolista

Tässä oppaassa käytetään pääasiallisena reittinä dnscrypt-proxyta, koska se on nopeampi pystyttää ja tukee suoraan DoH-protokollaa HTTP/3-kiihdytyksellä. Vaihe 9 näyttää lyhyesti myös Unbound-vaihtoehdon niille, jotka haluavat välttää kolmannen osapuolen DoH-palvelun kokonaan.

Vaihe 3: Kirjoita dnscrypt-proxyn konfiguraatiotiedosto

Lataa ensin valmis pohjakonfiguraatio ja muokkaa sitä. dnscrypt-proxy tukee HTTP/3-pohjaista DoH-yhteyttä, mikä nopeuttaa kyselyitä verrattuna perinteiseen HTTP/2-DoH:iin.

cd ~/pihole-doh/dnscrypt-proxy
wget -O dnscrypt-proxy.toml \
  https://raw.githubusercontent.com/DNSCrypt/dnscrypt-proxy/master/dnscrypt-proxy/example-dnscrypt-proxy.toml

Avaa tiedosto editorilla ja muokkaa seuraavat rivit vastaamaan alla olevaa. Näillä asetuksilla dnscrypt-proxy käyttää vain DoH-yhteensopivia palvelimia, priorisoi HTTP/3:n ja kuuntelee porttia 5053, jotta se ei riitele Pi-holen kanssa samassa kontissa.

listen_addresses = ['0.0.0.0:5053']
server_names = ['cloudflare', 'quad9-dnscrypt-ip4-filter-pri']
doh_servers = true
dnscrypt_servers = true
require_dnssec = true
require_nolog = true
require_nofilter = false
http3 = true
force_tcp = false
cache = true
cache_size = 4096

Rivi require_nolog = true rajaa palveluntarjoajalistan vain niihin, jotka on julkisesti dokumentoitu lokittomiksi. Voit vaihtaa server_names-listan haluamaasi resolveriin, esimerkiksi Mullvadin tai muun DNSCrypt-yhteisön ylläpitämään listaan. Täysi lista löytyy dnscrypt-proxyn julkisesta lähdekoodivarastosta.

Vaihe 4: Luo Docker Compose -tiedosto Pi-holelle ja dnscrypt-proxylle

Seuraavaksi luodaan yksi compose.yaml-tiedosto, joka käynnistää molemmat kontit samassa Docker-verkossa. Tämä on ratkaiseva vaihe: Pi-hole 6.x käyttää ympäristömuuttujaa FTLCONF_dns_upstreams määrittämään, mihin se lähettää suodattamansa kyselyt eteenpäin.

cd ~/pihole-doh
cat > compose.yaml <<'EOF'
services:
  dnscrypt-proxy:
    image: klutchell/dnscrypt-proxy:latest
    container_name: dnscrypt-proxy
    restart: unless-stopped
    volumes:
      - ./dnscrypt-proxy/dnscrypt-proxy.toml:/config/dnscrypt-proxy.toml
    networks:
      pihole_net:
        ipv4_address: 172.30.0.2

  pihole:
    image: pihole/pihole:latest
    container_name: pihole
    hostname: pihole
    restart: unless-stopped
    depends_on:
      - dnscrypt-proxy
    environment:
      TZ: 'Europe/Helsinki'
      FTLCONF_dns_upstreams: '172.30.0.2#5053'
      FTLCONF_webserver_api_password: 'VAIHDA_TAMA_SALASANA'
    volumes:
      - ./pihole/etc-pihole:/etc/pihole
      - ./pihole/etc-dnsmasq.d:/etc/dnsmasq.d
    ports:
      - '53:53/tcp'
      - '53:53/udp'
      - '80:80/tcp'
    networks:
      pihole_net:
        ipv4_address: 172.30.0.3

networks:
  pihole_net:
    ipam:
      config:
        - subnet: 172.30.0.0/24
EOF

Vaihda FTLCONF_webserver_api_password-arvo vahvaan, uniikkiin salasanaan ennen käynnistystä. Jos sinulla on jo muita palveluita, jotka käyttävät porttia 80, poista tuo porttikartoitus ja hallitse Pi-holea myöhemmin sisäisen Docker-verkon kautta tai vaihtoportilla, esimerkiksi 8080:80.

Kiinteät IPv4-osoitteet (172.30.0.2 ja 172.30.0.3) määritetään tarkoituksella sen sijaan, että annettaisiin Dockerin jakaa ne satunnaisesti. Tämä varmistaa, että FTLCONF_dns_upstreams-arvo pysyy oikeana myös kontin uudelleenkäynnistyksen jälkeen, sillä satunnaisesti jaettu sisäinen IP saattaisi vaihtua ja katkaista yhteyden Pi-holen ja dnscrypt-proxyn väliltä ilman selvää virheilmoitusta. Jos ajat useampaa Docker-verkkoa samalla koneella, valitse subnet-arvo, joka ei ole käytössä missään muussa verkossasi, jotta reititys ei mene sekaisin.

Vaihe 5: Käynnistä kontit ja tarkista lokit

docker compose up -d
docker compose logs -f dnscrypt-proxy

Odota, kunnes lokissa näkyy rivi, joka kertoo yhteyden muodostuneen valittuun palvelimeen, esimerkiksi teksti tyyliin “Server with the lowest initial latency” ja valitun palvelimen nimi. Paina Ctrl+C poistuaksesi lokien seurannasta, kontit jäävät silti käyntiin taustalle.

Tarkista seuraavaksi, että Pi-hole on käynnistynyt ja saa yhteyden dnscrypt-proxyyn:

docker compose logs pihole | tail -30
docker exec -it pihole dig @172.30.0.2 -p 5053 example.com

Jos dig-komento palauttaa vastauksen IP-osoitteineen, dnscrypt-proxy toimii ja vastaa kyselyihin. Jos komento aikakatkaisee, siirry oppaan vianetsintäosioon.

Vaihe 6: Määritä Pi-holen ylävirran DNS web-käyttöliittymässä

Vaikka ympäristömuuttuja asettaa oletuksen, kannattaa varmistaa asetus myös hallintapaneelista. Avaa selaimella http://<isäntäkoneen-IP>/admin ja kirjaudu sisään asettamallasi salasanalla.

  1. Siirry kohtaan Settings > DNS.
  2. Poista kaikki valmiiksi valitut ylävirran palvelimet (Google, Cloudflare oletuslistalta) valinnasta.
  3. Lisää mukautettu IPv4-osoite kenttään: 172.30.0.2#5053.
  4. Vieritä alas ja poista valinta kohdasta “Use DNSSEC”, jos dnscrypt-proxy hoitaa DNSSEC-tarkistuksen jo itse (kuten yllä olevassa toml-konfiguraatiossa asetimme).
  5. Tallenna asetukset painamalla Save.

Tämä kaksinkertainen varmistus (ympäristömuuttuja plus web-käyttöliittymän asetus) on hyödyllinen, koska Pi-hole 6.x saattaa joskus ylikirjoittaa ympäristömuuttujan asetuksen web-käyttöliittymän kautta tehdyllä muutoksella tai päinvastoin. Molempien pitäisi osoittaa samaan paikkaan.

Vaihe 7: Ohjaa kotiverkon laitteet käyttämään Pi-holea

Nyt kun Pi-hole ja dnscrypt-proxy toimivat isäntäkoneella, seuraava vaihe on ohjata koko kotiverkon liikenne käyttämään Pi-holea nimipalvelimena. Tämä tehdään helpoiten reitittimen DHCP-asetuksista, jolloin jokainen verkkoon liittyvä laite saa Pi-holen osoitteen automaattisesti.

  1. Kirjaudu reitittimen hallintapaneeliin (yleensä osoitteessa 192.168.1.1 tai 192.168.0.1).
  2. Etsi DHCP- tai LAN-asetukset -valikko.
  3. Aseta ensisijaiseksi DNS-palvelimeksi Pi-holen isäntäkoneen staattinen IP-osoite.
  4. Poista toissijainen DNS-palvelin tyhjäksi tai osoita se myös samaan Pi-holeen. Älä jätä operaattorin DNS:ää varapalvelimeksi, sillä laitteet saattavat käyttää sitä ohittaen Pi-holen.
  5. Tallenna asetukset ja käynnistä reititin uudelleen, jotta muutos leviää kaikille laitteille DHCP-vuokrauksen uusiutuessa.

Jos et halua tai voi muuttaa koko verkon asetuksia (esimerkiksi vuokra-asunnossa, jossa reititin on operaattorin hallinnassa), voit asettaa DNS-osoitteen laitekohtaisesti Windowsin, macOSin, Androidin tai iOS:n verkkoasetuksista. Tämä toimii, muttei suojaa laitteita, joihin ei pääse käsiksi asetuksiin, kuten älytelevisioita.

Vaihe 8: Testaa, että DNS-kyselyt todella kulkevat salattuna

Pelkkä konfiguraatio ei riitä, se pitää myös todistaa. Yksinkertaisin testi on Cloudflaren oma diagnostiikkasivu, joka kertoo suoraan, näkeekö se selaimesi DNS-kyselyiden tulevan salattuna.

  1. Varmista, että laitteesi verkkoasetukset osoittavat Pi-holen IP-osoitteeseen (ei suoraan operaattorin DNS:ään).
  2. Avaa selaimessa osoite https://one.one.one.one/help.
  3. Etsi rivi “Using DNS over HTTPS (DoH)”. Sen pitäisi näyttää “Yes”, jos kysely kulki dnscrypt-proxyn kautta salattuna.
  4. Tarkista myös Pi-holen hallintapaneelista kohta Query Log ja varmista, että kyselyt näkyvät siellä normaalisti. Tämä todistaa, että suodatus toimii samalla kun salaus on päällä.

Toinen tapa varmistaa asia on ajaa pakettikaappaus isäntäkoneen ulospäin suuntautuvaan verkkorajapintaan ja tarkistaa, ettei perinteistä porttia 53 käytetä ylävirran suuntaan lainkaan, vaan liikenne kulkee portissa 443 (HTTPS) dnscrypt-proxyn kautta.

sudo tcpdump -i eth0 port 53 -n
# Ei pitäisi näkyä liikennettä ulospäin, koska ylävirran yhteys kulkee 443:ssa

Vaihe 9: Vaihtoehtoinen reitti, Unbound ilman kolmatta osapuolta

Jos et halua luottaa mihinkään yksittäiseen DoH-palveluntarjoajaan, Unbound tarjoaa vaihtoehdon: se voi hakea vastaukset suoraan juuripalvelimilta rekursiivisesti, jolloin mikään yksittäinen taho ei näe koko DNS-historiaasi kerralla. Tämä ei ole yhtä nopea kuin cache-optimoitu julkinen DoH-resolveri, mutta poistaa yhden luottamuspisteen ketjusta.

docker run -d --name unbound \
  --restart unless-stopped \
  -p 5335:53/tcp -p 5335:53/udp \
  -v ~/pihole-doh/unbound:/opt/unbound/etc/unbound \
  mvance/unbound:latest

Kun kontti on käynnissä, vaihda Pi-holen mukautettu ylävirran osoite kohtaan 127.0.0.1#5335 (tai kontin sisäinen IP, jos ajat Docker-verkossa). Unbound päivittää juuripalvelinten vyöhyketiedoston automaattisesti käynnistyksen yhteydessä, joten erillistä DoH-palveluntarjoajaa ei tarvita lainkaan tässä mallissa.

Vaihe 10: DNSSEC ja lisäsuojaukset

DNS over HTTPS salaa liikenteen matkalla, mutta ei yksin todista, ettei vastausta ole väärennetty lähteellä. DNSSEC (DNS Security Extensions) täydentää tätä varmistamalla kryptografisesti, että vastaus todella tulee alkuperäiseltä, valtuutetulta nimipalvelimelta. Molemmissa yllä esitetyissä ratkaisuissa DNSSEC kannattaa pitää päällä: dnscrypt-proxyssa require_dnssec = true ja Unboundissa se on oletuksena käytössä uusimmissa image-versioissa.

Voit tarkistaa DNSSEC-validoinnin toimivuuden komennolla, joka testaa tunnetusti rikkinäistä allekirjoitusta vastaan:

dig @<pihole-IP> dnssec-failed.org
# Pitäisi palauttaa SERVFAIL, jos DNSSEC-validointi toimii oikein

Vaihe 11: Lokien hallinta ja tietosuoja-asetukset

Pi-holen oma kyselyloki tallentaa oletuksena kaikki DNS-kyselyt paikallisesti tietokantaan. Tämä on hyödyllistä vianetsinnässä, mutta jos tavoitteena on maksimoida yksityisyys, kannattaa säätää lokitusta Settings > Privacy -välilehdeltä. Vaihtoehdot vaihtelevat täydestä lokituksesta anonymisoituun tilaan, jossa domainit tallennetaan mutta pyytävää laitetta ei yksilöidä, aina täyteen lokituksen kytkemiseen pois päältä.

Kotikäyttäjälle sopiva tasapaino on yleensä anonymisoitu tila: näet edelleen, mitä domaineja verkossasi kysytään ja voit tunnistaa epäilyttävän liikenteen (esimerkiksi IoT-laite, joka yrittää yhdistää tuntemattomaan palvelimeen), mutta yksittäisiä laitteita ei liitetä lokiin pysyvästi.

Vaihe 12: Varmuuskopiointi ja päivitysrutiini

Docker-pohjainen asennus tekee varmuuskopioinnista suoraviivaista, koska kaikki pysyvä tila on volyymeissa. Ota tapa varmuuskopioida asetukset säännöllisesti, erityisesti ennen isompia päivityksiä.

tar -czvf pihole-backup-$(date +%F).tar.gz \
  ~/pihole-doh/pihole/etc-pihole \
  ~/pihole-doh/pihole/etc-dnsmasq.d \
  ~/pihole-doh/dnscrypt-proxy/dnscrypt-proxy.toml
docker compose pull
docker compose up -d

Aja docker compose pull && docker compose up -d säännöllisesti, esimerkiksi kerran kuukaudessa cronjobina, jotta sekä Pi-hole että dnscrypt-proxy pysyvät ajan tasalla tietoturvapäivitysten osalta. Docker-image-versiot voi lukita tarvittaessa tiettyyn tagiin, jos haluat välttää yllättäviä muutoksia automaattisen päivityksen yhteydessä.

Yleisimmät sudenkuopat asennuksessa

Seuraavat virheet toistuvat useimmin, kun kotikäyttäjät pystyttävät Pi-holen ja salatun DNS:n ensimmäistä kertaa. Suurin osa niistä liittyy joko porttiristiriitoihin isäntäkoneella tai unohdettuun asetuksen tuplavarmistukseen web-käyttöliittymän ja ympäristömuuttujien välillä, joten kannattaa käydä lista läpi ennen kuin aloitat oman vianetsinnän tyhjästä.

  • Portti 53 on jo varattu. Monissa Ubuntu- ja Raspberry Pi OS -asennuksissa systemd-resolved kuuntelee jo porttia 53. Poista tai poista käytöstä systemd-resolved ennen Pi-holen käynnistystä, muuten kontti ei saa porttia auki.
  • Vanha cloudflared-ohje kopioitu suoraan. Jos seuraat vanhaa, ennen helmikuuta 2026 kirjoitettua opasta, cloudflared ei enää tarjoa DoH-proxya samalla tavalla. Käytä tämän oppaan dnscrypt-proxy- tai Unbound-reittiä sen sijaan.
  • DHCP-varapalvelin osoittaa yhä operaattorille. Jos reitittimessä on toissijainen DNS-kenttä täytettynä operaattorin osoitteella, osa laitteista ohittaa Pi-holen automaattisesti, kun ensisijainen palvelin hetkellisesti hidastelee.
  • Docker-verkon staattinen IP törmää olemassa olevaan aliverkkoon. Jos kotiverkkosi käyttää jo 172.30.0.0/24-aluetta jollekin muulle laitteelle, vaihda compose.yaml-tiedoston subnet-arvo, esimerkiksi 172.31.0.0/24:ksi.
  • DNSSEC-validointi hylkää kaiken. Jos kaikki kyselyt alkavat epäonnistua DNSSEC:in käyttöönoton jälkeen, kellon virheellinen aika isäntäkoneella on yleinen syy, koska DNSSEC-allekirjoitusten aikaleimavalidointi epäonnistuu, jos järjestelmäkello on väärässä.
  • Unohdettu salasanan vaihto. Oletussalasana tai testivaiheessa käytetty heikko salasana jää tuotantoon, jos FTLCONF_webserver_api_password-muuttujaa ei vaihdeta ennen ensimmäistä käynnistystä.
  • IPv6-liikenne ohittaa Pi-holen kokonaan. Jos reitittimessä on IPv6 käytössä eikä sen DNS-asetuksia ole muutettu, laitteet voivat tehdä DNS-kyselyt IPv6-osoitteiden kautta ohittaen koko Pi-hole-määrityksen. Tarkista myös reitittimen IPv6 DNS -asetukset.

Vianetsintä: yleisimmät ongelmat ja ratkaisut

Alla on kerätty tyypillisimmät virhetilanteet asennuksen jälkeen ja niiden ratkaisut. Käy taulukko läpi ylhäältä alas ennen kuin avaat lisää lokitiedostoja, sillä valtaosa ongelmista selittyy jollain näistä kahdeksasta syystä.

OngelmaTodennäköisin syyRatkaisu
Pi-hole-kontti ei käynnisty, portti 53 varattusystemd-resolved kuuntelee jo porttia 53 isäntäkoneellaAja sudo systemctl disable --now systemd-resolved ja käynnistä Docker-kontit uudelleen
dig-testi palauttaa aikakatkaisundnscrypt-proxy ei löydä toimivaa palvelinta valitulta listaltaTarkista internetyhteys isäntäkoneella ja kokeile eri server_names-arvoa toml-tiedostossa
one.one.one.one/help näyttää “No” DoH-kohdassaLaite käyttää yhä operaattorin DNS:ää Pi-holen sijaanTarkista laitteen verkkoasetukset ja DHCP-vuokraus, uusi vuokraus tarvittaessa
Kaikki verkkosivut palauttavat SERVFAILDNSSEC-validointi epäonnistuu väärän järjestelmäkellon vuoksiSynkronoi isäntäkoneen kello NTP:llä: sudo timedatectl set-ntp true
Pi-holen hallintapaneeli ei aukeaPortti 80 on jo käytössä toisella palvelulla isäntäkoneellaVaihda compose.yaml-tiedostossa porttikartoitus esimerkiksi arvoon 8080:80
Kysely toimii isäntäkoneella mutta ei muilla laitteillaPalomuuri estää portin 53 liikenteen isäntäkoneen ulkopuoleltaAvaa portit 53/tcp ja 53/udp isäntäkoneen palomuurista lähiverkon suuntaan
dnscrypt-proxy-kontti kaatuilee toistuvastiVirheellinen syntaksi toml-konfiguraatiotiedostossaAja docker compose logs dnscrypt-proxy ja tarkista rivinumero, jolla jäsennysvirhe ilmoitetaan
Latenssi kasvanut huomattavasti aiempaan verrattunaValittu DoH-palvelin sijaitsee maantieteellisesti kaukanaVaihda server_names-listassa lähempänä sijaitsevaan Pohjoismaissa hyvin toimivaan resolveriin

Pi-hole vai AdGuard Home salatun DNS:n näkökulmasta

Pi-holen rinnalla kannattaa mainita AdGuard Home, koska ero näiden kahden välillä on juuri tämän oppaan aiheen ytimessä. AdGuard Home tukee DoH:ta ja DoT:ta sisäänrakennetusti, ilman että käyttäjän tarvitsee pystyttää erillistä proxya tai kontteja sen rinnalle. Pi-hole puolestaan on aina nojannut siihen, että salaus hoidetaan erillisellä työkalulla, mikä on juuri se lisätyö, jonka tämä opas kävi läpi. Vuoden 2026 vertailuartikkelien mukaan tämä ero on tullut entistä näkyvämmäksi juuri cloudflared-muutoksen jälkeen, koska AdGuard Home -käyttäjät eivät joutuneet tekemään mitään, kun taas Pi-hole-käyttäjien piti etsiä uusi ratkaisu.

Tästä huolimatta moni valitsee yhä Pi-holen, koska sen suodatuslistojen hallinta, ryhmäkohtaiset säännöt ja pitkä yhteisöhistoria ovat kypsempiä. Kun Pi-hole yhdistetään dnscrypt-proxyyn tai Unboundiin tämän oppaan mukaisesti, lopputulos on käytännössä yhtä turvallinen kuin AdGuard Homen sisäänrakennettu ratkaisu, mutta vaatii kaksi konttia yhden sijaan. Jos arvostat yksinkertaisuutta etkä halua ylläpitää kahta palvelua, AdGuard Home on validi vaihtoehto. Jos taas haluat tarkan hallinnan siitä, mitä ylävirran resolveria käytetään ja millä ehdoilla, Pi-hole plus dnscrypt-proxy antaa enemmän säätövaraa.

DNS-metatiedon yksityisyys ja sääntely-ympäristö Suomessa

DNS-kyselyt ovat metatietoa, ja metatiedon käsittelyyn sovelletaan Suomessa ja EU:ssa samoja periaatteita kuin muuhunkin henkilötietojen käsittelyyn, kun kyselyt voidaan yhdistää tunnistettavissa olevaan käyttäjään. Operaattoreiden ja julkisten DNS-palveluiden ylläpitäjien on noudatettava sähköisen viestinnän palveluista annettua lakia sekä yleistä tietosuoja-asetusta, kun ne käsittelevät liikennetietoja. Kotikäyttäjän kannalta olennaisin käytännön seuraus on se, että salaamaton DNS-kysely altistaa selaustottumukset kolmansille osapuolille, joiden tietosuojakäytännöistä käyttäjä ei aina tiedä mitään, kuten julkisen WLAN-verkon ylläpitäjälle tai reitin varrella oleville verkko-operaattoreille.

Tässä oppaassa esitetty ratkaisu ei poista tarvetta valita luotettava DoH-palveluntarjoaja huolellisesti, koska DNS-kyselyt siirtyvät vain reitin salaukselta suojatuksi, eivät katoa mihinkään. Valitsemasi DoH-resolveri (Cloudflare, Quad9 tai muu) näkee edelleen kyselyt, joten kannattaa valita palveluntarjoaja, jonka tietosuojaselosteessa mainitaan lokien minimointi tai lokittomuus. Tämä on syy, miksi dnscrypt-proxyn konfiguraatiossa käytettiin require_nolog = true -asetusta: se rajaa käytettävät palvelimet listalle, jotka on julkisesti dokumentoitu vähän tai ei lainkaan lokittaviksi.

Yritys- ja yhteisökäytössä kannattaa lisäksi huomata, että Pi-holen oma kyselyloki muuttuu itsessään henkilötietoja sisältäväksi rekisteriksi heti, kun yksittäiset laitteet ja niiden käyttäjät voidaan yhdistää toisiinsa esimerkiksi kiinteiden IP-varausten kautta. Jos asennat tämän kaltaisen ratkaisun työpaikalle tai yhteiskäyttöiseen tilaan, mieti etukäteen kuka pääsee lukemaan Pi-holen hallintapaneelia ja kuinka pitkään kyselylokia säilytetään, jotta käsittely pysyy oikeasuhtaisena suhteessa siihen, mihin tietoa oikeasti tarvitaan.

IoT-laitteiden ja älykodin suojaaminen verkkotason salauksella

Suomalaisissa kotitalouksissa on nykyään kymmeniä verkkoon kytkettyjä laitteita: älytelevisioita, robotti-imureita, lämmitysjärjestelmien ohjaimia, valvontakameroita ja pelikonsoleita. Suurimmassa osassa näistä ei ole minkäänlaista käyttöliittymää DNS-asetusten muuttamiseen, eikä valmistaja tarjoa mahdollisuutta ottaa DoH:ta käyttöön laitekohtaisesti. Näiden laitteiden DNS-kyselyt kulkevat siis aina sellaisina kuin verkko ne sallii, mikä tekee reitittimen tason ratkaisusta ainoan käytännöllisen tavan suojata niitä.

Kun Pi-hole on asetettu koko verkon oletukseksi DHCP:n kautta, jokainen näistä laitteista alkaa automaattisesti käyttää salattua DNS-reittiä ilman että laitteeseen koskee. Tämä on erityisen tärkeää laitteille, jotka lähettävät säännöllisesti tietoa valmistajan palvelimille, koska pelkkä DNS-kyselyjen kohdedomainien lista voi paljastaa yllättävän paljon laitteen käyttötottumuksista, esimerkiksi milloin kotona ollaan tai milloin tiettyä laitetta käytetään. Pi-holen kyselyloki toimii samalla myös eräänlaisena valvontatyökaluna: jos jokin laite yhtäkkiä alkaa kysellä tuntematonta domainia epätavallisen usein, se voi olla merkki laiteohjelmiston muutoksesta tai jopa haittaohjelmasta.

VPN ja Pi-hole yhdessä: miten vältät ristiriidat

Moni Nordic-lukija käyttää jo kaupallista VPN-palvelua kannettavalla tai puhelimella, ja tässä kohtaa syntyy usein sekaannus: toimivatko Pi-hole ja VPN yhdessä, vai kumoaako toinen toisensa hyödyn? Vastaus riippuu siitä, missä VPN-yhteys puretaan. Jos VPN-sovellus asettaa oman DNS-palvelimensa laitteelle heti yhteyden muodostamisen jälkeen, laite lakkaa käyttämästä Pi-holea ja alkaa käyttää VPN-palveluntarjoajan omaa nimipalvelinta. Tämä ei ole huono asia sinänsä, koska hyvämaineiset VPN-palvelut ajavat yleensä omaa salattua DNS:ää, mutta se tarkoittaa, että Pi-holen mainossuodatus ei enää toimi VPN-yhteyden aikana.

Jos haluat pitää Pi-holen suodatuksen aktiivisena myös VPN-yhteyden yli, kaksi käytännön vaihtoehtoa toimii. Ensimmäinen on ajaa Pi-hole itse VPN-palvelimella tai reitittimellä, johon VPN-tunneli päättyy, jolloin kaikki tunnelin läpi kulkeva liikenne, DNS mukaan lukien, kiertää Pi-holen kautta ennen ulosmenoa. Toinen vaihtoehto on määrittää VPN-asiakasohjelmiston asetuksista mukautettu DNS-palvelin, joka osoittaa Pi-holen sisäiseen tai julkiseen osoitteeseen, mikäli VPN-sovellus sallii tämän. Molemmissa tapauksissa kannattaa testata lopputulos DNS-vuototestillä VPN-yhteyden ollessa päällä, jotta näkee todella, mikä palvelin vastaa kyselyihin.

Esimerkkitulosteet: miltä onnistunut asennus näyttää

Kun kaikki vaiheet on tehty oikein, muutama komento riittää vahvistamaan tilanteen nopeasti. Alla on esimerkki siitä, minkälaisen rakenteen dig-komennon vastaus noudattaa, kun dnscrypt-proxy vastaa kyselyyn onnistuneesti porin 5053 kautta.

$ docker exec -it pihole dig @172.30.0.2 -p 5053 example.com

; <<>> DiG 9.18 <<>> @172.30.0.2 -p 5053 example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4821
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.        86400   IN      A       93.184.216.34

;; Query time: 24 msec
;; SERVER: 172.30.0.2#5053(172.30.0.2)

Status-rivin arvo NOERROR ja ANSWER SECTION -osion IP-osoite kertovat, että kysely eteni onnistuneesti dnscrypt-proxyn kautta. Jos näet sen sijaan tekstin connection timed out tai SERVFAIL, siirry vianetsintätaulukkoon. Vastaavasti Pi-holen hallintapaneelin Query Log -näkymässä onnistunut, salattu kysely näkyy normaalina rivinä domainin, ajan ja vastauksen kanssa, ja rivin yksityiskohdista näkee, että kysely reititettiin mukautetulle ylävirran palvelimelle oletuspalvelinten sijaan.

Suorituskyvyn ja latenssin mittaaminen käytännössä

Ennen kuin julistat asennuksen valmiiksi, kannattaa mitata, miten paljon salaus todellisuudessa vaikuttaa vasteaikoihin omassa verkossasi. Tämä on syytä tehdä itse, koska tulos riippuu isäntäkoneen suorituskyvystä, valitusta DoH-palvelimesta ja kotisi internetyhteyden reitityksestä eikä yleispätevää lukua voi antaa etukäteen. Yksinkertaisin tapa on ajaa dig-komento toistuvasti ja verrata Query time -riviä ennen ja jälkeen dnscrypt-proxyn käyttöönoton.

# Mittaa vasteaika suoraan operaattorin DNS:ään (ennen)
dig @<operaattorin-dns> example.com | grep "Query time"

# Mittaa vasteaika Pi-holen ja dnscrypt-proxyn kautta (jälkeen)
dig @<pihole-IP> example.com | grep "Query time"

# Toista 10 kertaa ja laske keskiarvo kummallekin reitille
for i in {1..10}; do dig @<pihole-IP> example.com | grep "Query time"; done

Ensimmäinen kysely on lähes aina hitaampi, koska vastausta ei vielä ole välimuistissa. Toistetut kyselyt samaan domainiin sen sijaan palautuvat Pi-holen omasta välimuistista lähes välittömästi, riippumatta siitä käytetäänkö salattua vai salaamatonta ylävirran yhteyttä, koska välimuistiosuma ei koskaan tarvitse ylävirran kyselyä lainkaan. Jos huomaat, että jokainen kysely, myös toistetut, on hidas, todennäköisin syy on välimuistin poiskytkeytyminen tai liian pieni cache_size-arvo dnscrypt-proxyn konfiguraatiossa. Kasvata tällöin arvoa asteittain ja mittaa uudelleen, kunnes löydät tasapainon muistinkäytön ja vasteajan välillä omalle laitteistollesi sopivaksi.

Edistyneet vinkit: nopeuden ja luotettavuuden hienosäätö

Kun perusasennus toimii, muutama lisäasetus parantaa käyttökokemusta merkittävästi. Ensinnäkin kannattaa ottaa käyttöön kahden Pi-hole-instanssin klusteri, jos laitteita on paljon ja käytettävyys on tärkeää: yksi Pi-hole toimii ensisijaisena ja toinen, eri fyysisellä laitteella ajettava instanssi, varapalvelimena. Molemmat voidaan pitää synkronoituna Gravity Sync -tyyppisellä työkalulla tai yksinkertaisesti ajastetulla varmuuskopiotiedoston kopioinnilla.

Toiseksi, jos verkossasi on paljon suoratoistolaitteita, harkitse cache-koon kasvattamista dnscrypt-proxyn toml-tiedostossa (cache_size-arvo) sekä Pi-holen omaa DNS-välimuistia, mikä vähentää toistuvien kyselyiden latenssia huomattavasti. Kolmanneksi, jos haluat estää DNS-vuodot VPN-yhteyden kanssa, varmista, että VPN-asiakasohjelmisto ei ohita Pi-holea omilla DNS-asetuksillaan. Tämä on yleinen sudenkuoppa, joka mitätöi koko asennuksen hyödyn silloin kun VPN on päällä.

Neljänneksi, mieti oletuslistojen lisäksi mukautettuja estolistoja: Pi-holen Group Management -osiosta voi lisätä lisää suodatuslistoja, esimerkiksi seurantadomaineihin tai haittaohjelmiin keskittyviä listoja, jotka täydentävät perus mainossuodatusta. Viidenneksi, jos ajat useita Docker-palveluita samalla isäntäkoneella, harkitse Traefikin tai muun käänteisproxyn käyttöä Pi-holen hallintapaneelin edessä, jotta pääsyä voi rajata TLS-sertifikaatilla myös lähiverkon sisällä.

Kuudenneksi, jos kotiverkossasi on useampi kuin yksi reititin tai aliverkko, esimerkiksi erillinen vierasverkko tai VLAN älykodin laitteille, varmista että jokaisen aliverkon DHCP-asetukset osoittavat samaan Pi-holeen. Tämä on helppo unohtaa, ja lopputulos on se, että osa laitteista jää salaamattoman DNS:n varaan, vaikka pääverkko olisi kunnossa. Seitsemänneksi, seuraa Pi-holen kojelaudan Top Blocked Domains -näkymää ajoittain: se paljastaa nopeasti, jos jokin uusi laite alkaa lähettää epätavallisen paljon kyselyitä tuntemattomille domaineille, mikä on usein ensimmäinen merkki laiteohjelmiston päivityksestä tai vikaantumisesta.

Valmis projekti: koko compose-ympäristö yhdessä paketissa

Alla on koko toimiva projekti koottuna yhteen, valmiina kopioitavaksi. Tallenna tämä ~/pihole-doh/compose.yaml-tiedostoksi, muokkaa salasana ja käynnistä docker compose up -d.

services:
  dnscrypt-proxy:
    image: klutchell/dnscrypt-proxy:latest
    container_name: dnscrypt-proxy
    restart: unless-stopped
    volumes:
      - ./dnscrypt-proxy/dnscrypt-proxy.toml:/config/dnscrypt-proxy.toml
    networks:
      pihole_net:
        ipv4_address: 172.30.0.2

  pihole:
    image: pihole/pihole:latest
    container_name: pihole
    hostname: pihole
    restart: unless-stopped
    depends_on:
      - dnscrypt-proxy
    environment:
      TZ: 'Europe/Helsinki'
      FTLCONF_dns_upstreams: '172.30.0.2#5053'
      FTLCONF_webserver_api_password: 'VAIHDA_TAMA_SALASANA'
    volumes:
      - ./pihole/etc-pihole:/etc/pihole
      - ./pihole/etc-dnsmasq.d:/etc/dnsmasq.d
    ports:
      - '53:53/tcp'
      - '53:53/udp'
      - '80:80/tcp'
    networks:
      pihole_net:
        ipv4_address: 172.30.0.3

networks:
  pihole_net:
    ipam:
      config:
        - subnet: 172.30.0.0/24

Kun molemmat kontit ovat käynnissä ja one.one.one.one/help vahvistaa DoH-yhteyden, koko kotiverkkosi DNS-liikenne kulkee salattuna ilman että yhtäkään laitetta on tarvinnut erikseen konfiguroida. Tämä on koko verkkotason lähestymistavan etu selain- tai käyttöjärjestelmäkohtaisiin ratkaisuihin verrattuna.

Miten tämä eroaa selaintason DNS over HTTPS -asetuksista

Moni on jo ottanut DoH:n käyttöön Firefoxissa tai Chromessa selaimen omista asetuksista. Tämä suojaa selaimen tekemät kyselyt, mutta ei kata muita samassa verkossa olevia laitteita eikä sovelluksia, jotka tekevät DNS-kyselyitä käyttöjärjestelmätasolla selaimen ohi. Verkkotason Pi-hole-ratkaisu toimii toisin päin: se kattaa jokaisen laitteen, mutta yksittäinen laite voi silti ohittaa sen, jos sovellus on koodattu käyttämään omaa, kovakoodattua DNS-palvelinta (nk. DNS over HTTPS “bypass”, jota esimerkiksi jotkin selaimet tekevät oletuksena, ellei sitä erikseen poisteta käytöstä).

Paras suoja saavutetaan yhdistämällä molemmat: verkkotason Pi-hole + dnscrypt-proxy runkona, ja tarvittaessa selainkohtaisten DoH-ohitusten poistaminen käytöstä (esimerkiksi Firefoxin network.trr.mode-asetuksesta), jotta selain ei yritä ottaa yhteyttä omaan, ulkoiseen DoH-resolveriinsa Pi-holen ohi.

Milloin itse ylläpito kannattaa ja milloin ei

Tämä opas vaatii noin 90 minuuttia aikaa ja jatkuvan, pienimuotoisen ylläpitovastuun: Docker-imageja pitää päivittää, kello pitää olla oikeassa DNSSEC:iä varten, ja joku laitteista voi ajoittain menettää yhteyden Pi-holeen, jos isäntäkone on pois päältä. Tämä on täysin kohtuullinen hinta, jos nautit siitä, että voit itse valita ylävirran resolverin, hallita suodatuslistoja tarkasti ja pitää kaiken infran omissa käsissäsi ilman kolmannen osapuolen sovellusta jokaisella laitteella.

Jos taas tavoite on yksinkertaisesti saada DNS-liikenne salattua mahdollisimman pienellä vaivalla, ilman mainossuodatusta tai ylläpitovastuuta, monet reitittimet tukevat nykyään DoT- tai DoH-asetusta suoraan laiteohjelmistostaan, ja osa operaattoreista tarjoaa oman salatun DNS-palvelunsa oletuksena. Näissä tapauksissa et saa Pi-holen suodatustoimintoja etkä yhtä tarkkaa hallintaa siitä, mitä resolveria käytetään, mutta säästät ylläpitoajan ja vältät riskin, että koko kotiverkon internetyhteys näyttää katkenneelta, jos itse ylläpidetty palvelin kaatuu. Valinta on lopulta sama kuin minkä tahansa itse ylläpidetyn palvelun kohdalla: kontrolli ja säädettävyys yhdellä puolella vaakakuppia, valmiiksi hoidettu yksinkertaisuus toisella.

Yhteenveto: mitä koko kotiverkkosi sai tästä asennuksesta

Kahdentoista vaiheen jälkeen kotiverkkosi DNS-kyselyt eivät enää kulje selväkielisenä ulos verkosta. Pi-hole suodattaa yhä mainokset ja seurantadomainit kuten ennenkin, mutta nyt jokainen sen tekemä ylävirran kysely kulkee dnscrypt-proxyn kautta salattuna TLS- tai HTTP/3-yhteytenä valitsemallesi resolverille. Tämä kattaa automaattisesti jokaisen laitteen, joka saa IP-osoitteensa kotiverkkosi DHCP:ltä, ilman erillistä asetusta kussakin laitteessa erikseen.

Muista kolme asiaa jatkossa: pidä Docker-imaget ajan tasalla kuukausittaisella docker compose pull -komennolla, varmista säännöllisesti DoH-yhteyden toimivuus one.one.one.one/help-sivulla, ja ota varmuuskopio asetuksista ennen isompia muutoksia. Jos vaihdat myöhemmin reitittimen tai isäntäkoneen, koko ympäristön palauttaminen vie muutaman minuutin, kun compose.yaml-tiedosto ja varmuuskopioidut kansiot ovat tallessa.

Yleisiä virhekäsityksiä DNS-salauksesta

Aiheen ympärillä liikkuu muutama harhaluulo, jotka kannattaa oikaista ennen kuin siirryt tuotantokäyttöön. Ensimmäinen on ajatus, että DoH tekisi käyttäjästä jäljittämättömän. Näin ei ole: valitsemasi DoH-palveluntarjoaja näkee edelleen kaikki kyselysi, ja mikäli sama laite tunnistetaan IP-osoitteesta tai muista tunnisteista, kyselyt voidaan periaatteessa yhdistää käyttäjään siinä palvelussa. DoH suojaa vain kuljetusreitin, ei itse resolveria vastaan.

Toinen yleinen väärinkäsitys on, että Pi-hole ja mainosten esto olisivat sama asia kuin yksityisyyden suoja. Mainossuodatus estää tunnettuja seurantadomaineja lataamasta sisältöä, mutta se ei salaa mitään eikä estä esimerkiksi ensimmäisen osapuolen seurantaa, joka tapahtuu suoraan sivuston omalta domainilta. Kolmas väärinkäsitys koskee nopeutta: moni olettaa DoH:n olevan aina hitaampi kuin salaamaton DNS, mutta käytännössä ero jää usein huomaamattomaksi, koska sekä Pi-holen että dnscrypt-proxyn välimuistit vastaavat toistuviin kyselyihin lähes välittömästi ilman, että kysely edes lähtee ulos verkosta.

Neljäs harhaluulo on, että salattu DNS korvaisi VPN:n tai Tor-verkon kokonaan. DNS-salaus suojaa vain nimenselvityksen, ei itse yhteyden sisältöä tai IP-osoitettasi, joka näkyy edelleen kohdepalvelimelle ja reitin varrella oleville tahoille. Salattu DNS on yksi kerros muiden joukossa, ei yksinään riittävä ratkaisu kattavaan yksityisyyteen verkossa.

Usein kysytyt kysymykset

Toimiiko Pi-hole yhä ilman salattua DNS:ää, jos en halua tehdä tätä asennusta?
Kyllä. Pi-hole toimii mainossuodattimena myös ilman salattua ylävirran yhteyttä, mutta silloin DNS-kyselysi kulkevat selväkielisenä ylävirran nimipalvelimelle asti, mikä ei suojaa liikennettä salakuuntelulta reitin varrella.

Miksi vanha cloudflared-ohje ei enää toimi?
Cloudflare poisti DoH-proxy-toiminnon cloudflared-työkalusta myöhään vuonna 2025 ja uusista julkaisuista helmikuussa 2026, joten uudet asennukset eivät voi enää käyttää samaa mallia kuin aiemmin. Pi-holen virallinen dokumentaatio kuvaa yhä vanhaa tapaa arkistoituna viitteenä, mutta se ei toimi uusimmilla cloudflared-versioilla.

Kumpi on parempi valinta, dnscrypt-proxy vai Unbound?
dnscrypt-proxy on nopeampi pystyttää ja tukee useita valmiiksi listattuja DoH-palveluntarjoajia. Unbound sopii paremmin, jos haluat minimoida riippuvuuden yksittäiseen kolmanteen osapuoleen, koska se voi toimia täysin rekursiivisena resolverina.

Vaikuttaako tämä asennus internetyhteyden nopeuteen?
DNS-kyselyiden ratkaisu voi olla hieman hitaampi ensimmäisellä kyselyllä salauksen ja mahdollisen kauempana sijaitsevan palvelimen vuoksi, mutta Pi-holen välimuisti tekee toistuvista kyselyistä nopeita. Itse verkkoyhteyden nopeuteen (latausnopeus, striimaus) tällä ei ole merkittävää vaikutusta, koska DNS-kysely tapahtuu vain kerran yhteyden alussa, ei jatkuvasti tiedonsiirron aikana.

Voiko tämän asentaa ilman Raspberry Pi:tä?
Kyllä. Mikä tahansa aina päällä oleva Linux-laite, jossa Docker toimii (NAS, kotipalvelin tai virtuaalikone), sopii isäntäkoneeksi. Ainoa vaatimus on, että laite on kytkettynä verkkoon ja käynnissä jatkuvasti, jotta se voi toimia koko kotiverkon nimipalvelimena.

Suojaako tämä myös mobiililaitteita kodin ulkopuolella?
Ei suoraan. Kun puhelin siirtyy pois kotiverkosta mobiilidataan tai toiseen WLAN-verkkoon, se ei enää käytä Pi-holea DNS-palvelimenaan, ellei laitteeseen ole erikseen asennettu VPN- tai DNS-profiilia, joka ohjaa liikenteen takaisin kotiverkon Pi-holeen.

Mitä tapahtuu, jos Pi-hole-laite kaatuu tai menettää virran?
Jos ainoa DNS-palvelin verkossasi on Pi-hole eikä varapalvelinta ole määritetty, internetyhteys näyttää katkenneelta kaikilta laitteilta, kunnes Pi-hole käynnistyy uudelleen. Tämän vuoksi kahden instanssin klusteri tai automaattinen uudelleenkäynnistys (restart: unless-stopped, kuten yllä olevassa compose-tiedostossa) on suositeltavaa.

Onko dnscrypt-proxyn käyttö laillista Suomessa?
Kyllä. DNS-liikenteen salaaminen on tavallinen, laillinen tietoturvakäytäntö, eikä siihen liity erityisrajoituksia Suomessa tai muissa Pohjoismaissa. Tilanne poikkeaa esimerkiksi maista, joissa DoH-palveluita on estetty verkkotasolla.