Sign in Subscribe

Miks ma vahetasin Pi-hole'i Technitium DNS-i vastu ja kuidas ehitasin päris High Availability DNS-lahenduse

Miks ma vahetasin Pi-hole'i Technitium DNS-i vastu ja kuidas ehitasin päris High Availability DNS-lahenduse
Photo by Albert Stoynov / Unsplash

Viimased paar aastat kasutasin oma kodulaboris Pi-hole'i reklaamide blokeerimiseks ja lokaalse DNS-serverina. Lahendus töötas hästi ning töökindluse suurendamiseks jooksutasin kahte eraldi Pi-hole instantsi, kumbki erineval Proxmoxi node'il.

Mõlemad Pi-hole'id olid seadistatud käsitsi ning kasutasid samu reklaamiblokeerimise nimekirju. Teadsin küll, et Pi-hole'i jaoks on olemas selline lahendus nagu Nebula Sync, mis võimaldab konfiguratsiooni automaatselt sünkroonida, kuid ausalt öeldes ei viitsinud ma seda kunagi kasutusele võtta. Kõik muudatused tegin mõlemas instantsis käsitsi.

Kuigi mul oli justkui olemas High Availability, ei olnud ma seda tegelikult kunagi testinud. Kahe DNS-serveri olemasolu ei tähenda automaatselt, et lahendus päriselt töötab ka rikke korral.

Miks just Technitium DNS?

Viimasel ajal hakkasin järjest rohkem märkama, et paljud homelab'i ja self-hostingu sisuloojad YouTube'is soovitavad Pi-hole'i asemel Technitium DNS-i. Pärast dokumentatsiooni lugemist sai kiiresti selgeks, miks.

Suurim eelis minu jaoks oli see, et Technitium toetab clusteringut juba karbist välja. Eraldi pluginaid või kolmanda osapoole lahendusi pole vaja paigaldada. Kõik klastri funktsioonid on osa ametlikust tootest.

See oligi peamine põhjus, miks otsustasin oma olemasoleva Pi-hole lahenduse välja vahetada.

Minu arhitektuur

Lahendus on üles ehitatud üsna lihtsalt.

                    Kliendid
                        │
                        ▼
          +----------------------------+
          |   Technitium DNS Cluster   |
          +----------------------------+
           │                        │
           ▼                        ▼
     Node 1 (Primary)        Node 2 (Secondary)
 Debian Trixie LXC        Debian Trixie LXC
 Docker Compose           Docker Compose
           │
           ▼
      pfSense (Unbound DNS Resolver)
           │
           ▼
        Mullvad DNS

Mõlemad Technitiumi serverid töötavad Docker Compose'i abil Debian Trixie LXC konteinerites, mis omakorda asuvad erinevatel Proxmoxi node'idel. Selline ülesehitus tähendab, et ühe füüsilise node'i rike ei katkesta kogu DNS-teenust.

Split Horizon DNS

Üks suurimaid põhjuseid, miks mulle Technitium meeldima hakkas, on selle väga paindlik DNS-tsoonide haldus.

Technitium võimaldab luua lokaalseid tsoone praktiliselt ükskõik millise domeeni jaoks. Soovi korral võiks isegi luua lokaalse tsooni näiteks apple.com jaoks ning määrata sellele täiesti oma DNS-kirjed. Kõik Technitiumi kasutavad kliendid saavad seejärel just need kirjed, mitte internetis olevad.

Mina kasutasin seda võimalust hoopis Split Horizon DNS-i ehitamiseks.

Koduses võrgus töötab mul kaks reverse proxyt:

  • Nginx Proxy Manager
  • NetBirdi sisseehitatud reverse proxy

Varem lahendasid minu seadmed domeeninimed interneti kaudu. See tähendas, et isegi koduses võrgus pidi klient kõigepealt küsima avalikust DNS-ist, milline on minu domeeni IP-aadress.

Pärast Technitiumi kasutuselevõttu lõin oma domeenile vajalikud A- ja CNAME-kirjed. Nüüd tagastab Technitium klientidele kohe minu sisevõrgu reverse proxy aadressid.

Sellel on mitu eelist:

  • DNS-päringud ei lähe enam internetti.
  • Teenused avanevad kiiremini.
  • Kõik jätkab töötamist isegi siis, kui internetiühendus katkeb.

Testisin seda üsna lihtsalt.

Lülitasin pfSense'is WAN-liidese välja ning proovisin avada Jellyfini, mis asub reverse proxy taga. Enne Split Horizon DNS-i seadistamist ei olnud see võimalik. Pärast muudatust töötas teenus täiesti probleemivabalt ka ilma internetiühenduseta.

High Availability testimine

Seekord otsustasin oma HA lahenduse ka päriselt läbi testida.

Kasutasin selleks järgmist käsku:

watch -n1 'dig @192.168.1.3 google.com +short; echo "---"; dig @192.168.1.4 google.com +short'

Käsk teeb iga sekundi järel päringu mõlemale DNS-serverile ning kuvab tulemused kõrvuti.

Seejärel peatasin kordamööda nii Primary kui ka Secondary Technitiumi konteineri.

Tulemus oli täpselt selline, nagu ootasin:

  • ühe serveri seiskamisel lõpetas see koheselt vastamise;
  • teine server jätkas DNS-päringute teenindamist ilma katkestuseta;
  • sama toimus ka vastupidises suunas.

See oli esimene kord, kui sain kindlalt öelda, et minu DNS High Availability töötab päriselt, mitte ainult paberil.

Nüüd saan DNS-servereid uuendada või hooldada ilma, et keegi koduses võrgus seda üldse märkaks.

Kuidas Technitiumi klaster töötab?

Technitiumi clustering on üsna sirgjooneline.

Kõik konfiguratsioonimuudatused tehakse ainult Primary serveris.

Secondary server sünkroonib automaatselt kõik tsoonid, DNS-kirjed, blokeerimisnimekirjad ja muu konfiguratsiooni Primary serverist.

Oluline on teada, et kui teha muudatus Secondary serveris, siis neid Primary serverisse tagasi ei sünkroonita. Praktikas tähendab see, et kogu haldus peaks alati toimuma ainult Primary sõlmes.

Reklaamide blokeerimine

Kuigi Technitium on eelkõige täisväärtuslik DNS-server, sisaldab see ka reklaamiblokeerimist.

Sisseehitatud blokeerimisnimekirjadega õnnestus mul saavutada umbes 93% tulemus AdBlock testi järgi, mis on praktiliselt sama hea kui Pi-hole'i puhul.

Lisaks toetab Technitium karbist välja Block Page funktsiooni. Selle abil saab kasutajale kuvada spetsiaalse lehe, kui ta proovib avada domeeni, mis on DNS-i tasemel blokeeritud. Pi-hole'is tuleb sellise lahenduse jaoks kasutada täiendavaid tööriistu või keerukamat seadistust.

DNS arhitektuur

Technitiumi upstream DNS-serveriks on minu võrgus pfSense.

pfSense kasutab DNS Resolverit, mis põhineb Unboundil. Erinevalt tavalisest DNS-forwarderist suudab rekursiivne resolver lahendada DNS-päringuid ise, liikudes vajadusel juurserveritest kuni autoritatiivsete DNS-serveriteni välja. See vähendab sõltuvust välistest DNS-teenustest ning annab suurema kontrolli DNS-liikluse üle.

Technitiumi mõlemas klastri sõlmes on upstream DNS-serveriks määratud pfSense interface'i-aadress. Kuigi sinna võiks määrata otse näiteks Google'i, Cloudflare'i või Quad9 DNS-serverid, eelistan kogu DNS-liikluse suunata läbi tulemüüri.

pfSense kasutab omakorda Mullvad DNS-i, mis toetab DNS over HTTPS (DoH) ja DNS over TLS (DoT). See tähendab, et DNS-päringud on krüpteeritud ning kolmandatel osapooltel on neid oluliselt keerulisem pealt kuulata. Lisaks kasutab Mullvad QNAME minimization tehnoloogiat, mis vähendab DNS-päringutes jagatava info hulka, ning Anycast võrku, mis suunab päringud automaatselt lähimasse töötavasse serverisse.

Pi-hole või Technitium?

Minu arvates sõltub valik sellest, mida täpselt vaja on.

Kui eesmärk on lihtsalt reklaamide blokeerimine, on Pi-hole endiselt suurepärane valik. Seda on lihtne paigaldada, hallata ja kasutada.

Kui aga soovid ehitada keerukamat DNS-lahendust, kasutada lokaalseid tsoone, Split Horizon DNS-i, clusteringut, Block Page funktsiooni ning saada rohkem kontrolli kogu DNS-infrastruktuuri üle, siis on Technitium minu hinnangul märgatavalt võimekam lahendus.

Pärast mitmenädalast kasutamist ei näe ma enam ühtegi põhjust Pi-hole'i juurde tagasi minna. Native clustering, paindlik tsoonide haldus ja võimalus ehitada päris High Availability DNS-lahendus tegid Technitiumist minu kodulabori ühe olulisema infrastruktuurikomponendi.