Erillinen nimipalvelin (DNS) kotiverkossa ratkaisi nettiongelman - AdGuard Home

borg

administi
Ylläpitäjä
Rakentelin alkuvuonna Proxmox-virtualisointialustan vanhasta kannettavasta. Siihen piti tietysti kehittää virtuaalikoneita suorittamaan erilaisia tehtäviä. Osalle oli oikeaa käyttöä, joitakin tein ihan uteliaisuudesta.

Yksi asentamani virtuaalikone hoiti kotiverkon nimipalvelua AdGuard Home - ohjelmistolla. Tämä on ilmainen softa. Minulla se pyörii Debian-virtuaalikoneessa. Sen voi kyllä asentaa ihan fyysiseenkin koneeseen, jos sattuu olemaan jokin vanha kone joutilaana.

AdGuard Home:a vastaavia ohjelmia on muitakin. Yksi tunnetuimmista lienee Raspberry Pi:lle tehty Pi-Hole.

Tyypillisesti näitä käytetään hävittämään mainokset nettisivuilta. Kun millä tahansa verkon koneella tai mobiililaitteella selataan nettiä, niin kaikki liikenne käy ensin nimipalvelimessa, joka selvittää maailmalta, mitä ip-osoitetta kyselty verkkotunnus vastaa. Tämä tieto palautetaan selaimelle, joka sitten lataa sisällön selvitetystä ip-osoitteesta. Kikkana tässä on se, että nimipalvelimella on musta lista domaineista, jotka tarjoilevat vain mainoksia ja muuta stöndaa. Niinpä se jättää tyystin selvittämättä nämä osoitteet ja nettisivu latautuu vain niiltä osin kuin sisältö on hyödyllistä. Mainokset eivät lataudu, joten nettisivut siistiytyvät.

Minullakin tuo erillinen nimipalvelin hoiti vain tällaista tehtävää, mutta nyt se (oikeilla asetuksilla) korjasi :kaluja: inhottavan vian, joka oli vähitellen alkanut sotkemaan netin käyttöä. Olen nyt todella tyytyväinen ja siispä ajattelin vinkata tästä. Vastaavia ongelmia saattaa olla jollakulla muullakin.

Vian syntyhetki on vähän hämärä. Saattaa olla, että sitä on esiintynyt jo pidemmän aikaa, mutta se ei ole mainittavasti haitannut. Kuitenkin nyt aivan viime viikkoina se alkoi pahenemaan ja muutamana viime päivänä se oli jo todella paha. En keksi muuta syytä tälle pahenemiselle kuin vuodenajan, jolloin mahla alkaa nousta puihin.

Meidän nettiyhteytemme on maantieteellisesti aika haasteellinen. Kunnollinen tukiasema löytyy yli kuuden kilometrin päästä ja olen tätä samaa käyttänyt jo monia vuosia. Pääsääntöisesti operaattorina on ollut Elisa, joka on pelannut varsin hyvin. Varayhteytenä on ollut Telia, joka sekin on ollut ihan okei silloin kun sitä on tarvinnut käyttää. Cellmapperin kartasta tiedän kuitenkin, että Telian antennien suuntaus mastossa on vähemmän suotuisa ja signaali huonompi. Elisalla yksi keila osoittaa juuri meille päin ja siksi signaali on parempi.

Hintasyistä otin Telian myös nettiyhteydeksi, koska arvelin silläkin pärjääväni. Näin olikin, kunnes ongelmat viime aikoina alkoivat. Ja syyksi arvelen, että tässä välissä olevassa metsäpuskassa on nyt enemmän vettä kuin aiemmin ja se huonontaa signaalia. Tämä on otaksuma, koska en tiedä asiaa, arvelen vain.

Tein pari päivää vianhakua. Syy ei ollut mesh-verkossa. Se ei ollut kaapeleissa, ei kytkimissä. Ei reitittimessä A eikä reitittimessä B. Viimein se paikallistui nimipalvelun toimintaan. Olin tilapäisesti poistanut AdGuard Home:n käytöstä, koska yhdessä vaiheessa arvelin sitä mahdolliseksi ongelman aiheuttajaksi. Se ei ollut sitä, mutta senhetkisillä asetuksilla se toimi aivan yhtä huonosti kuin reitittimen DNS.

Vika ilmeni niin, että tyypillisesti selain ilmoitti, ettei nettisivua voida ladata, koska palvelinta ei löydy. Nimikysely oli siis epäonnistunut. Tätä ilmeni lopulta muutaman minuutin välein ja tyypillisesti mm. Iltalehti, Ilta-Sanomat ja HS olivat niitä verkosta kadonneita. Parin minuutin päästä ne taas löytyivät. Välillä Googlekin oli hukassa ja kaikenlaista kummaa ilmeni aina välillä.

Teetin ChatGPT:llä skriptejä, joilla testattiin nettiyhteyttä, mikä toimii ja mikä ei. Myös nämä alkoivat viitata nimipalveluongelmiin.

Viimein löytyi selitys. Tavallisesti DNS-kyselyt tehdään UDP-protokollalla. Harvoissa reitittimissä voi edes valita muun protokollan kuin UDP. Tarkemmin valikoimalla sellaisenkin löytää, mutta kummassakaan omassa reitittimessä ei vakiona ollut mahdollisuutta käyttää kuin UDP:tä.

UDP on kevyt protokolla. Se on nopea ja helppo, mutta siinä on puutteita. Se vain huhuilee nettiin kyselynsä ja odottaa, että joku vastaa. Ellei vastausta tule, niin se tuumaa whatever ja siirtyy seuraavaan hommaan. Se ei pyri varmistamaan mitenkään, että kysely meni perille. Yleensä tämä toimii, mutta jos yhteydessä on laadullisia puutteita ja paketteja katoilee, niin UDP ei oikein toimi.

DNS-kyselyjä voi tehdä muitakin protokollia käyttäen (jos oman verkon nimipalvelin osaa tämän) Niistä löytyy sitkeyttä kysellä niin monta kertaa uudelleen, että kunnon vastaus tulee.

Tässä paljon selittävä kuvakaappaus. Testauksen lokitiedosto on käynyt ChatGPT:n analysoitavana:

testiraportti.webp


Tämä UDP-protokollan toimimattomuusongelma korjaantui ottamalla verkon nimipalvelimeksi taas AdGuard Home ja tekemällä siihen asetus, ettei UDP:tä käytetä DNS-kyselyyn. Nyt käytössä itselläni on CloudFlaren nimipalvelu 1.1.1.1 ja siltä kysytään TLS-protokollaa käyttäen. Kuvan esimerkkilistassa näkyy paljon muitakin vaihtoehtoja.

Näyttökuva 2026-05-01 kello 13.50.07.webp


Tämä korjaus pelaa nyt kuin buikki. Kaikki katkeilu on poistunut, koska DNS-kyselyt menevät perille ja niihin tulee aina vastaus.

On toki mahdollista, että tämän UDP-ongelman taustalla on jotain muuta kuin mahla puissa. Mutta en pohdi sitä sen kummemmin, pääasia että korjaus löytyi ja se toimii erinomaisesti.
 
Tässä vielä ChatGPT:n tekemä reportaasi asian tiimoilta:




Kun selain valittaa “palvelinta ei löydy” – vika voikin olla DNS:n UDP-liikenteessä​


Moni nettiongelma näyttää käyttäjälle tältä:


Palvelinta ei löydy
Server not found
DNS_PROBE_FINISHED_NXDOMAIN
DNS_PROBE_STARTED
DNS-palvelin ei vastaa


Usein ensimmäinen epäily kohdistuu verkkosivuun, selaimeen, reitittimeen tai operaattoriin. Joskus vika onkin niissä. Mutta yksi melko huonosti tunnettu mahdollisuus on se, että itse internet-yhteys toimii muuten kohtuullisesti, mutta **DNS-kyselyt pätkivät**.

Erityisesti mobiililaajakaistassa tämä voi tulla vastaan. Yhteys voi olla riittävän hyvä esimerkiksi videon katseluun, sähköpostiin ja tavalliseen selailuun, mutta silti nimipalvelukyselyt voivat epäonnistua ajoittain.

Mikä DNS on?​


DNS on internetin nimipalvelu. Kun kirjoitat selaimeen esimerkiksi:

www.example.com

tietokoneen täytyy ensin selvittää, mikä IP-osoite tuon nimen takana on. Tämä kysely tehdään DNS-palvelimelta.

Ilman toimivaa DNS:ää selain ei tiedä, mihin osoitteeseen sen pitäisi yhdistää. Silloin käyttäjälle voi näkyä virhe, vaikka varsinainen internet-yhteys ei olisikaan kokonaan poikki.

DNS käyttää yleensä UDP:tä​


Perinteinen DNS toimii normaalisti UDP-protokollalla portissa 53.

UDP on kevyt ja nopea protokolla. Se sopii hyvin pieniin kyselyihin, koska siinä ei tarvitse avata varsinaista yhteyttä ennen kyselyn lähettämistä. DNS-kysely on usein hyvin pieni: “mikä on tämän nimen IP-osoite?”

Yksinkertaistettuna UDP-DNS toimii näin:


Tietokone lähettää DNS-kyselyn
Tietokone odottaa vastausta
Jos vastausta ei tule nopeasti, kysely epäonnistuu tai sitä yritetään uudelleen


UDP:n heikkous on se, että se ei itsessään varmista pakettien perillemenoa. Jos kysely tai vastaus katoaa matkalla, UDP ei protokollatasolla korjaa tilannetta. DNS-ohjelma voi toki yrittää uudelleen, mutta käyttäjälle tämä voi näkyä viiveenä, pätkimisenä tai virheenä.

TCP kestää häiriöitä paremmin​


TCP on raskaampi mutta luotettavampi protokolla. TCP-yhteydessä lähetetty data kuitataan, ja kadonneita osia voidaan lähettää uudelleen.

Yksinkertaistettuna TCP toimii näin:


Avataan yhteys palvelimeen
Lähetetään dataa
Vastaanottaja kuittaa vastaanotetun datan
Kadonneet osat lähetetään uudelleen
Data toimitetaan oikeassa järjestyksessä


Siksi TCP voi selvitä paremmin tilanteessa, jossa yhteys on vähän epävakaa, ruuhkainen tai radiosignaalin laatu vaihtelee.

DNS:ää voidaan tehdä myös TCP:llä. Lisäksi nykyään on olemassa DNS over TLS ja DNS over HTTPS -ratkaisuja, joissa DNS-kyselyt kulkevat salatun TCP/HTTPS-yhteyden kautta.

Miksi tämä korostuu mobiiliyhteyksissä?​


Mobiiliverkossa yhteyden laatu ei ole pelkkä “montako palkkia näkyy” -asia. Yhteyteen vaikuttavat esimerkiksi:


signaalin voimakkuus
signaalin laatu
häiriöt
tukiaseman ruuhka
antennien suuntaus
taajuusalueet
etäisyys tukiasemaan
operaattorin verkon reititys


Yhteys voi olla sellainen, että TCP-liikenne toimii käyttäjän mielestä “ihan hyvin”, koska TCP paikkaa pieniä häiriöitä. Samalla UDP-pohjaiset DNS-kyselyt voivat kuitenkin epäonnistua ajoittain.

Tämä voi näkyä juuri ärsyttävänä satunnaisena selailuongelmana:


Sivu ei lataudu
Hetken päästä sama sivu latautuu normaalisti
Ongelma koskee välillä vain joitakin sivuja
Netti ei tunnu olevan kokonaan poikki


Tällöin ongelma ei välttämättä ole itse verkkosivussa, vaan siinä, ettei laitteen ensimmäinen DNS-kysely saanut vastausta.

Ratkaisu: oma DNS-palvelin lähiverkkoon​


Yksi hyvä ratkaisu on käyttää omassa lähiverkossa erillistä DNS-palvelinta tai DNS-välittäjää. Tällaisia voivat olla esimerkiksi:

AdGuard Home
Pi-hole
Unbound
dnsmasq
reitittimen oma kehittyneempi DNS-palvelu
OPNsense / pfSense / OpenWrt -ratkaisut


Perusidea on tämä:

Lähiverkon laitteet
→ kysyvät DNS:n omalta paikalliselta DNS-palvelimelta

Paikallinen DNS-palvelin
→ kysyy nimipalvelut internetistä TCP:llä, DNS over TLS:llä tai DNS over HTTPS:llä


Tällöin kodin sisällä laitteet voivat edelleen käyttää tavallista nopeaa DNS:ää. Mutta mobiiliyhteyden yli kulkeva varsinainen ulkoinen DNS-liikenne voidaan siirtää luotettavampaan muotoon.

Esimerkiksi:


Tietokone / puhelin / tabletti
→ DNS-kysely lähiverkon AdGuard Homeen

AdGuard Home
→ DNS over TLS tai DNS over HTTPS ulkoiselle DNS-palvelimelle


Tämä voi vähentää merkittävästi tilanteita, joissa selain valittaa, ettei palvelinta löydy.

Miksi paikallinen DNS auttaa muutenkin?​


Paikallisesta DNS-palvelimesta voi olla useita hyötyjä.

Ensinnäkin se voi käyttää välimuistia. Jos joku verkon laite on juuri kysynyt tietyn sivuston osoitteen, seuraava kysely voidaan vastata suoraan omasta verkosta.

Toiseksi kaikki laitteet saadaan käyttämään samaa nimipalveluratkaisua. Tämä helpottaa vianhakua.

Kolmanneksi esimerkiksi AdGuard Home tai Pi-hole voi samalla suodattaa mainoksia, seurantaa tai haitallisia verkkotunnuksia.

Neljänneksi upstream-DNS:n voi valita itse. Esimerkiksi DNS over TLS- tai DNS over HTTPS -palvelimia voi käyttää sen sijaan, että luotetaan reitittimen tai operaattorin oletus-DNS:ään.

Tärkeä asetus: pelkkä DNS-palvelimen vaihtaminen ei välttämättä riitä​


On tärkeää erottaa kaksi asiaa:


DNS-palvelimen osoite
DNS-kyselyn käyttämä protokolla


Jos vaihdetaan DNS-palvelimeksi esimerkiksi:


1.1.1.1
8.8.8.8
9.9.9.9


se ei vielä tarkoita, että UDP olisi poistunut käytöstä. Hyvin usein tavallinen DNS-kysely näihin osoitteisiin tehdään edelleen UDP:llä portissa 53.

Jos ongelma on juuri UDP/53-liikenteen pätkiminen, pelkkä DNS-palvelimen vaihtaminen ei välttämättä auta. Silloin pitää saada paikallinen DNS-palvelin käyttämään ulospäin esimerkiksi:


DNS over TLS
DNS over HTTPS
DNS over TCP


Käytännössä AdGuard Homessa tämä tarkoittaa, että upstream-palvelimiksi ei laiteta vain pelkkiä IP-osoitteita, vaan käytetään salattuja DNS-osoitteita, esimerkiksi DNS over HTTPS- tai DNS over TLS -muotoisia palvelimia.

Esimerkkikaavio​


Ongelmallinen tilanne voi olla tällainen:


Läppäri / iPad / puhelin
→ UDP-DNS-kysely reitittimelle tai suoraan internetiin
→ mobiiliyhteys
→ DNS-palvelin

Jos UDP-vastaus katoaa:
→ selain ilmoittaa, ettei palvelinta löydy


Parannettu ratkaisu:


Läppäri / iPad / puhelin
→ DNS-kysely lähiverkon AdGuard Homeen

AdGuard Home
→ DNS over TLS / DNS over HTTPS / TCP-DNS
→ mobiiliyhteys
→ ulkoinen DNS-palvelin


Tässä jälkimmäisessä mallissa kodin ja DNS-palvelimen välinen kriittinen osuus ei enää ole tavallinen UDP/53-kysely.

Mistä ongelman voi tunnistaa?​


Tällaista vikaa voi epäillä, jos:

selain antaa satunnaisesti “palvelinta ei löydy” -virheitä
sama sivu toimii hetken päästä uudelleen
ongelma koskee useita eri sivustoja
netti ei tunnu olevan kokonaan poikki
videot tai olemassa olevat yhteydet saattavat jatkua
DNS-palvelimen vaihtaminen ei ratkaise ongelmaa
mobiililaajakaistan signaali tai laatu on rajatapauksessa

Teknisemmin asiaa voi testata vertaamalla UDP- ja TCP-DNS-kyselyitä. Jos UDP-kyselyt epäonnistuvat usein mutta TCP-kyselyt onnistuvat, se viittaa vahvasti siihen, että ongelma liittyy UDP-pohjaiseen DNS-liikenteeseen eikä yksittäiseen DNS-palvelimeen.

Tämä ei korjaa kaikkia nettiongelmia​


On hyvä huomata, että tämä ei ole yleislääke kaikkiin yhteysongelmiin. Jos mobiiliyhteys katkeaa kokonaan, signaali on erittäin huono tai tukiasema on pahasti ruuhkainen, DNS:n muuttaminen ei tee ihmeitä.

Mutta jos ongelma on nimenomaan satunnaista nimipalvelupätkimistä, paikallinen DNS-palvelin ja TCP/DoT/DoH-upstream voi olla yllättävän suuri parannus.

Erityisesti mobiililaajakaistassa tästä voi olla paljon hyötyä, koska yhteys voi olla juuri sen verran epävakaa, että UDP-DNS kärsii, vaikka TCP-pohjainen liikenne vielä toimii kohtuullisesti.

Yhteenveto​


Jos kotiverkossa näkyy satunnaisia “palvelinta ei löydy” -virheitä, syy voi olla DNS-kyselyiden pätkimisessä. Perinteinen DNS käyttää yleensä UDP:tä, joka ei varmista pakettien perillemenoa samalla tavalla kuin TCP.

Yksi käytännöllinen ratkaisu on asentaa oma DNS-palvelin lähiverkkoon, esimerkiksi AdGuard Home tai Pi-hole, ja asettaa se hakemaan ulkoiset nimikyselyt TCP:llä, DNS over TLS:llä tai DNS over HTTPS:llä.

Tällöin lähiverkon laitteet käyttävät keskitettyä paikallista DNS-palvelinta, ja varsinainen mobiiliyhteyden yli kulkeva DNS-liikenne saadaan luotettavampaan muotoon.

Lyhyesti:

Ongelma:
UDP-DNS voi pätkiä heikolla tai vaihtelevalla mobiiliyhteydellä.

Ratkaisu:
oma DNS-palvelin lähiverkkoon

Tärkeä asetus:
upstream-DNS TCP:llä, DoT:lla tai DoH:lla

Mahdollinen hyöty:
vähemmän “palvelinta ei löydy” -virheitä ja tasaisempi selailukokemus
 

Luo tili tai kirjaudu sisään kommentoidaksesi

Sinun täytyy olla jäsen voidaksesi jättää kommentin.

Luo käyttäjätili

Liity Konekansalaiseksi. Se on helppoa ja ilmaista! Rekisteröityneenä et näe mainoksia, voit käyttää hakua, näet alueita, joita nyt ovat piilossa...jne.

Kirjaudu sisään

Oletko jo Konekansan jäsen? Kirjaudu sisään tästä.

Takaisin
Ylös