No se edellyttää suurempaa hölmöyttä, eli kytkee sen suoraan internetiin ilman palomuuria, vähintään vaihtamatta sshd-autentikointimenetelmäksi sertifikaattia salasanan tilalle ja tutkimatta muita avoimia portteja
Niin joo tietysti, en huomioinu tuota ollenkaan.
Minulla on mm tämmöiset käytössä:
https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
https://raw.githubusercontent.com/harriko/suomimainostajat/master/hosts
Kannattaa varmistaa ettei clientin omat DNS-asetukset ohita sun PiHolea.
Itse käyttäisin jonkun julkisen DNS-palvelun (Cloudflare, NextDNS, OpenDNS) pornon estoja, yksittäisen listan sijasta. Lipsumisia voi tapahtua kenelle vain, joten DNS:n kanssa päivittäin painivat ylläpitäjät ovat ainakin teoriassa astetta varmempia kuin yksittäinen ylläpitäjä. Esim. NextDNS:lla voi oikeastaan korvata koko PiHolen, ellei sen ylläpitäminen kuulu lempiharrastuksiin.
Varmaan NextDNS-ketjussa (DNS-palvelut) olisi parempi kysyä. Ilmeisesti NDNS:ään pitää tehdä jonkinlainen käyttäjätunnus ja piholeen sitten konffata ainoaksi DNS-palvelimeksi NextDNS
Tee tunnus, linkitä profiili julkisella ipllä, ajasta esim. piholen kone cronilla ajaamaan wget "profiilin url" > /dev/null. Sitten pysyy kohdallaan, vaikka julkinen ip vaihtuu.
Joo, ajattelin sen liittyvän vain enemmän piholeen ja sen säätöihin kun itse dns ketjuun.
Tuo ei luullakseni ihan ollut sitä mitä hain, mutta kiitos silti.
Henkilökohtaisesti en näe tuossa yhdistelmässä minkälaista hyötyä. Miksi siis käyttää kahta päällekkäistä DNS-suodatinta, jossa molemmat nojaavat aika pitkälti samoihin sääntöihin?
Niin kyllähän se noinkin tietysti on. Ja enemmän vain selvitettäviä paikkoja kun ongelmia tulee vastaan= on lisää työtä.
On niitä muitakin (Cloudflare, OpenDNS, DNSFilter jne) joissa voi säätää sääntöjä. NextDNS:n säätömahdollisuudet ovat ehdottomasti parhaimmistoa. Cloudflaressa ei voi esim estää mainoksia.
Hyvä video! Täytyy kokeilla tuota palvelua
Tein about noin, Piholeen lisäksi NextDNS käyttäen stubbyä, jossa DNS-over-TLS ja DNSSEC, IPv4v6.
Minäpä koitan kanssa uudemman kerran tässä lähipäivinä jos saisin sen DoT toimimaan kanssa ! Houkuttaa sen verran nuo muutamat ominaisuudet tuolla nextdns palvelussa.
Omat /etc/stubby/stubby.yml muutokset, kun stubby on lokaalisti piholessa:
# Stubby 0.3.0
< round_robin_upstreams: 1
<
<-listen_addresses:
< - 127.0.0.1
< - 0::1
---
> round_robin_upstreams: 0
>
>-listen_addresses:
> - 127.0.0.1@153
> - 0::1@153
>
> dnssec: GETDNS_EXTENSION_TRUE
>
> appdata_dir: "/var/cache/stubby"
>
upstream_recursive_servers:
> # NextDMS Stubby guide:
> - address_data: 45.90.28.0
> tls_auth_name: "123456.dns1.nextdns.io"
> - address_data: 2a07:a8c0::0
> tls_auth_name: "123456.dns1.nextdns.io"
> - address_data: 45.90.30.0
> tls_auth_name: "123456.dns2.nextdns.io"
> - address_data: 2a07:a8c1::0
> tls_auth_name: "123456.dns2.nextdns.io"
>
> # comment out rest of resolversTaidan tänään kokeilla uudemman kerran tätä. Ihan loistava ! Jos saa toimimaan niin vois maksaakkin tuon 20e nextdns palvelusta ettei se jossain vaiheessa sitten muutu vahingossakaan tai yllätyksenä "non blocking classic" palveluksi...
@mikajh
Tuo on vielä helppo juttu ongelmaksi, koska stubby ei ollut tyytyväinen konffitiedostoon eikä käyttänyt sitä ollenkaan.
dnssec: GETDNS_EXTENSION_TRUEKyllä, tottakai ja tarkistin # merkit on niissä missä pitää ja toisinpäin.
Tuo voi johtua siitä, että stubby käynnistyy oletusasetuksilla ja varaa portin 53.
Yksi mahdollinen vikapaikka on tässä
listen_addresses:
- 127.0.0.1@153
- 0::1@153En kopioinu mitään suoraan ja nyt taisin löytää vian. Nyt olen siis tilanteessa jossa lisänny rivin kerrallaan ja aina kokeillu tuota komentoa "stubby -i". Alussa ei tule mitään erroria ja jos oikein ymmärrän niin ei lopussakaan kun se ainoa mitä sanoo lopuksi on tämä :
Itsellä kun tein virheen kokeiluissa, niin tuo -i lipun tarkistus ei valittanut mitään. Vasta käynnistys failasi niihin virheilmoituksiin (ilman rivinumeroita). Siksi kannattaa kokeilla lisäksi, että käynnistys onnistuu (eikä tule enää dumppia konffista) ja myös että resolvaus toimii. Sen voi testata millä tavalla tahansa, kunhan pystyy speksaamaan portin.
En hirveästi ymmärtäny mutta kokeillaan menemään
Editoin vielä tuota aiempaa viestiä, siinä oli kysymys vielä en tiedä kerkesitkö nähdä ?Siinäpä taisi olla kaikki. Katso vielä $ sudo systemctl status stubby
Aukasin tuon my.nextdns sivun ja heti ilmoitti vihreä pallo All good ! This device is using NextDNS with this configuration.
tls_connection_retries: 5
tls_backoff_time: 300Huomasin että alkoi piholessa näkyä tätä SERVFAIL ja mietin että mistä sekin tulee. Välillä näyy Bogusta punaisella, mutta ei ole haitannut vielä mitään. Täytyy vähä tutkiskella jossain vaiheessa enemmän. Toistaiseksi ainakin kaikki on menny NextDNS logien mukaan 100% DoT:ina.
En usko, että olisi. Oletuskonffin mukaan retries default = 2 ja backoff_time = 3600. Noilla on se huono vaikutus, varsinkin jos olisi vain yksi forward-osoite, että jos serveri ei vastaa, stubby laittaa kyselyt seis tunniksi, mikä on aika pitkä aika odotella, että netti alkaa taas toimia
Jumahtaako useinkin siellä ? Oisko siinä jokin pieni ristiriita sen sinun dnscryptin kanssa ? Täällä on nyt asennuksesta saakka toiminu tuon nextdns kanssa ihan mutkattomasti. Noh, kerran boottasin laitteet kyllä kun jotain pientä hämminkiä oli.
Laitoin erityisen testin pyörimään viiden minuutin välien, mutta se ei tuota suoraan mitään statistiikkaa. Väittäisin että karkeasti vähintään kerran päivässä se jumahtaa, siihen asti että restarttaan.
[09:11:31.088725] STUBBY: 2a07:a8c0::xx:xxxx : Upstream : TLS - Resps= 427, Timeouts = 8, Best_auth =Success
[09:11:31.088759] STUBBY: 2a07:a8c0::xx:xxxx : Upstream : TLS - Conns= 62, Conn_fails= 0, Conn_shuts= 0, Backoffs = 0
[09:11:31.088860] STUBBY: 2a07:a8c0:xx:xxxx : Upstream : TLS - Resps= 486, Timeouts = 0, Best_auth =Success
[09:11:31.088872] STUBBY: 2a07:a8c0::xx:xxxx : Upstream : TLS - Conns= 62, Conn_fails= 0, Conn_shuts= 0, Backoffs = 0
[09:13:50.600902] STUBBY: 2a07:a8c0::xx:xxxx : Upstream : TLS - Resps= 427, Timeouts = 8, Best_auth =SuccessTäällä tulee tuo SERVFAIL ja BOGUS tuosta duckduckgo osoitteesta ja johtuu varmaan siitä että on päällä se nextdns safesearch päällä. Olettaisin että tuo duckduckgo hakusivu ei tue tuota safesearch ominaisuutta kun blokkaa sivun kokonaan tuo nextdnspalvelu. Helppohan tuo olis kokeilla napauttaa se vain pois päältä ja katsoa mitä tapahtuu.
# EDNS0 option for keepalive idle timeout in milliseconds as specified in
# https://tools.ietf.org/html/rfc7828
# This keeps idle TLS connections open to avoid the overhead of opening a new
# connection for every query. Note that if a given server doesn't implement
# EDNS0 keepalive and uses an idle timeout shorter than this stubby will backoff
# from using that server because the server is always closing the connection.
# This can degrade performance for certain configurations so reducing the
# idle_timeout to below that of that lowest server value is recommended.
#idle_timeout: 10000
#idle_timeout: 9000
idle_timeout: 8500Ymmärsin tästä että toiminta meni parempaan suuntaan, mukava kuulla että toimii paremmin.
Mihin paikkaan se tallentaa näitä logeja vai tulostaako suoraan komentoriville ? Pitäis vähän seuraavan bootin yhteydessä toisella verkolla seurata mitä tapahtuu, kun tässä toisessa verkossa tuli kans pientä ongelmaa. Stubby käynnistyy bootin jälkeen jumitilaan, mutta sitten täytyy vain vähän restarttailla stubbyä ja odotella niin se lähtee käyntiin kyllä mutta jotain pientä hämminkiä siinä startissa on.
Vähän kehnot optiot noihin liittyen stubbyssä. Kun haluat käynnistää stubby servicenä ja ihmetellä, miksei se toimi, niin tiedosto stubby.service
Jos stubby on ainoa upstream DNS serveri, niin query logissa alkaa tietysti heti näkyä virheet, ja kun sivustojen viimeiset vastaukset (Time To Live) menee ohi, niin "netti lakkaa toimimasta"
https://block.energized.pro/unified/formats/hosts ei taidettu vielä mainita. Itsellä käytössä lisäksi https://hosts.oisd.nl/
