DNS | PiHole mit DoT+DNSSEC oder DoH

  • Was wollen wir?

    Verschlüsselten DNS Verkehr mit DoT (DNS over TLS) oder DoH (DNS over HTTPS)


    Warum wollen wir das?

    Weil wir Wert auf Privatsphäre legen.


    Und wie geht das genau?

    Mit Stubby, Cloudflared & PiHole


    Vorwort:

    Viele hier haben ja eine PiHole Instanz am laufen, jedoch ist der DNS Verkehr in den meisten Fällen unverschlüsselt.

    Das wollen wir nun ändern! Ich habe mich für DoT entschieden. Ich benutze Quad9, jedoch ist es natürlich möglich, sämtliche andere Resolver die DoT oder DoH unterstützen zu nehmen.

    Ich habe bewusst auf die TLS Authentifizierung mit Schlüsseln verzichtet, da bei Servern mit Let's Encrypt Zertifikat diese regelmäßig aktualisiert werden müssen.

    Die Wahrscheinlichkeit das hier Hijacking vorkommt ist schwindend gering, sollte jemand bedenken haben, kann er ja mit einem Auth-Key arbeiten.

    Außerdem habe ich bewusst auf DoH verzichtet, weil DoH nicht im Trasport Layer sondern im Application Layer integriert ist - für mich ist DoT einfach richtiger "IMHO"

    Trotzdem zeige ich in dem Tutorial auch den einfachen Weg mit DoH.


    Das hier beschriebene Vorgehen bezieht sich auf die Installation auf einen RaspberryPi mit Raspbian Lite.

    Bitte sucht euch die passenden Befehle für das Betriebssystem wo ihr PiHole am laufen habt raus, die Konfiguration ändert sich jedoch nicht!!!!


    Bitte lest euch den ganzen Eintrag einmal durch, entscheidet dann welchen Weg ihr gehen wollt!


    Tutorial | DoT+DNSSEC

    Also los geht's - wir fangen mit DoT und DNSSEC an.


    Erstmal das System auf den neusten Stand bringen:


    sudo apt-get update && sudo apt-get dist-upgrade -y


    Sollte PiHole noch nicht installiert sein:


    curl -sSL https://install.pi-hole.net| bash


    Einfach dem Installationsassistenten folgen und einen Resolver deiner Wahl nehmen, wichtig dabei ist, dass der Pi oder Container hinterher immer die gleiche IP hat.

    Nach der Installation passen wir dnsmasq an:


    sudo nano /etc/dnsmasq.d/99-my-config.conf


    Es muss folgende Zeile eingefügt werden:


    listen-address=::1,127.0.0.1,XXX.XXX.XXX.XXX #(eure IP des PiHole)


    Mit Strg+O, Enter, Strg+X Speichern


    Jetzt installieren wir Stubby um die Voraussetzung für DoT+DNSSEC zu erlangen:


    sudo apt install stubby


    Jetzt stoppen wir Stubby und passen die Konfiguration an:


    sudo systemctl stop stubby

    sudo nano /etc/stubby/stubby.yml


    :exclamation_mark:ACHTUNG: YML-Dateien reagieren extrem sensitiv auf Leertasten u.ä. also kontrolliert eure Config! Außerdem sind das hier nur Auszüge aus der config. Ihr könnt nicht einfach den Code mit Copy&Paste übernehmen. Ihr müsst euch hier step by step durcharbeiten. :exclamation_mark:


    Nun passen wir ein paar Einstellungen an:


    Code
    resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
- GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
round_robin_upstreams: 1


    Bei round_robin_upstreams könnt ihr auch die 0 setzen, solltet Ihr nur einen Resolver benutzen. Wenn Ihr mehrere Resolver nutzt dann setzt die 1 und Stubby fragt immer zufällig an.


    Jetzt können wir uns entscheiden, ob wir ECS aktivieren oder nicht. Bei mir ist es deaktiviert und sämtliches Streaming funktioniert einwandfrei.

    Sollte es bei euch also im Nachgang Probleme mit dem Streaming geben, dann solltet ihr ECS aktivieren.

    Wir deaktivieren es nun erstmal und passen weiter die config an:


    Code
    edns_client_subnet_private : 1
idle_timeout: 10000
listen_addresses:
- 127.0.2.2@10053
dnssec: GETDNS_EXTENSION_TRUE #hiermit aktivieren wir DNSSEC


    Ziemlich weit unten in der config, findet ihr Optional Upstream - ich benutze Quad9.



    Wir wählen unseren Wunsch-Resolver und lassen die anderen aus kommentiert.

    Ihr solltet also die # vor eurem favorisierten Resolver entfernen.


    Jetzt speichern wir die config ab mit Strg+O, Enter, Strg+X


    Als nächstes sorgen wir dafür, dass Stubby automatisch nach einem Absturz neu gestartet wird:


    sudo nano /lib/systemd/system/stubby.service


    Hier passen wir folgendes an:


    Code
    Restart=on-failure
RestartSec=1


    Jetzt speichern wir die config ab mit Strg+O, Enter, Strg+X

    Jetzt führen wir folgende Befehle aus:


    sudo systemctl daemon-reload

    sudo systemctl restart stubby


    Jetzt installieren wir dnsutils:


    sudo apt install dnsutils


    Jetzt testen wir ob DNSSEC funktioniert.


    dig @127.0.2.2 -p 10053 fail01.dnssec.works


    Die Antwort sollte SERVFAIL lauten. Hiermit haben wir validiert, dass DNSSEC funktioniert.



    Jetzt installieren wir knotdnsutils:


    sudo apt install knot-dnsutils


    Nun testen wir ob TLS funktioniert (solltet ihr einen anderen Resolver benutzen, bitte "dns.quad9.net" durch den Resolver eurer Wahl ersetzen):


    kdig @dns.quad9.net ubiquiti-networks-forum.de +tls


    Nun sollte in der obersten Zeile der Antwort etwas von TLS stehen. Hiermit haben wir validiert, dass TLS funktioniert.



    Da wir in der Stubby Config festgelegt haben, dass Anfragen ausschließlich über TLS ohne Fallback gesendet werden sollen, haben wir nun alle Voraussetzungen für DoT erfüllt.


    Nun gehen wir auf die PiHole Weboberfläche

    Unter Settings -> DNS, deaktivieren wir nun alle vorgegebenen Upstream DNS Server

    Jetzt tragen wir bei Custom Upstream folgendes ein:

    127.0.2.2#10053

    Speichern und den Resolver neu starten.


    Wichtig ist, dass der Haken bei DNSSEC nicht gesetzt wird, sonst kommt in den Logs die Meldung Insecure.

    Das hat den Hintergrund, dass PiHole bei Stubby anfragt, und diese Anfrage kein DNSSEC validiert. Erst die Anfrage durch Stubby an den Resolver wird validiert.


    Nun tragen wir bei all unseren LANs und WANs als DNS Adresse den PiHole ein (zuvor konfiguriert)


    Geschafft, PiHole macht jetzt DNS mit DoT und DNSSEC


    Ich für meinen Teil gebe mich mit dem einen Resolver und DoT+DNSSEC zufireden. ich Brauche keinen Mix aus DoH und DoT.




    Tutorial | DoH


    Erstmal das System auf den neusten Stand bringen:


    sudo apt-get update && sudo apt-get dist-upgrade -y


    Sollte PiHole noch nicht installiert sein:


    curl -sSL https://install.Pi-hole.net| bash


    Einfach dem Installationsassistenten folgen und einen Resolver deiner Wahl nehmen, wichtig dabei ist, dass der Pi oder Container hinterher immer die gleiche IP hat.


    Jetzt installieren wir Cloudflared:


    # For Debian/Ubuntu

    Code
    wget https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-amd64.deb
sudo apt-get install ./cloudflared-stable-linux-amd64.deb
cloudflared -v


    # For CentOS/RHEL/Fedora

    Code
    wget https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-amd64.rpm
sudo yum install ./cloudflared-stable-linux-amd64.rpm
cloudflared -v


    #arm64 architecture (64-bit Raspberry Pi)

    Code
    wget -O cloudflared https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-arm64
sudo mv cloudflared /usr/local/bin
sudo chmod +x /usr/local/bin/cloudflared
cloudflared -v


    #armhf architecture (32-bit Raspberry Pi)

    Code
    wget https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-arm.tgz
tar -xvzf cloudflared-stable-linux-arm.tgz
sudo cp ./cloudflared /usr/local/bin
sudo chmod +x /usr/local/bin/cloudflared
cloudflared -v


    Wir legen einen User für Cloudflared an:


    sudo useradd -s /usr/sbin/nologin -r -M cloudflared


    Nun passen wir die config an:


    sudo nano /etc/default/cloudflared


    Tragt hier nun euren gewünschten Resolver ein.


    # Commandline args for cloudflared, using Cloudflare DNS

    CLOUDFLARED_OPTS=--port 11053 --upstream https://9.9.9.9/dns-query


    Mit Strg+O, Enter, Strg+X Speichern


    Jetzt aktualisieren wir die Berechtigung:


    sudo chown cloudflared:cloudflared /etc/default/cloudflared

    sudo chown cloudflared:cloudflared /usr/local/bin/cloudflared


    Da Cloudflared automatisch starten soll passen wir nun den Service an:


    sudo nano /etc/systemd/system/cloudflared.service


    Mit Strg+O, Enter, Strg+X Speichern


    Eure Config sollte so aussehen



    Mit Strg+O, Enter, Strg+X Speichern


    Jetzt starten wir den Service:

    Code
    sudo systemctl enable cloudflared
sudo systemctl start cloudflared
sudo systemctl status cloudflared


    Nun gehen wir auf die PiHole Weboberfläche

    Unter Settings -> DNS, deaktivieren wir nun alle vorgegebenen Upstream DNS Server

    Jetzt tragen wir bei Custom Upstream folgendes ein:

    127.0.0.1#11053

    Speichern und den Resolver neustarten.


    Nun tragen wir bei all unseren LANs und WANs als DNS Adresse den PiHole ein (zuvor konfiguriert)


    Geschafft, PiHole macht jetzt DNS mit DoH




    Schlusswort:


    Wie bereits oben beschrieben ist es möglich, einen Mix aus DoH und DoT zu verwenden.

    Somit könnt Ihr auch beide Resolver in den Upstreams eintragen. Aber wie oben schon gesagt, liegt DoT auf dem Transportlayer. DoH ist Applikationsseitig. Deswegen ist meine Entscheidung: DoT "IMHO"

    Trotz meiner Entscheidung und Meinung ist DoH immer noch besser als kein verschlüsseltes DNS!

    Entscheidet euch für euren Favorit! Informiert euch über das Thema!


    Mir ist außerdem aufgefallen, dass PiHol eigentlich seltensten Falles auf den zweiten Resolver ausweicht, somit macht im PiHole eher nur ein Upstream Sinn.



    Sollte hier etwas missverständlich oder unverständlich beschrieben sein, bitte meldet euch bei mir, damit ich dies direkt richtig stellen bzw. anpassen kann.



    #PiHole #DoT #DoH #Security #Stubby #Cloudflared




    Disclaimer: Alle Anleitungen/Tutorials sind nach bestem Wissen und Gewissen verfasst, gehen immer von den definierten Software/Firmware-Versionen aus und sind auf das englische GUI ausgelegt.

    Es gibt keine Garantien auf Erfolg. Im Falle eines Misserfolges hilft aber sicherlich die Community hier immer weiter.

    Keiner der Autoren oder der Betreiber des Forums ist für die aus der Nutzung resultierenden Probleme/Herausforderungen verantwortlich.

    Jegliche hier beschriebenen Schritte erfolgen ausnahmslos in eigener Verantwortung des Durchführenden. Eltern haften für ihre Kinder.:winking_face_with_tongue:

Kommentare 25

  • @defcon
    Super Anleitung einfach umzusetzen

    Danke für deine Arbeit lg Stone

  • Ich doch noch mal.... Ich musste stubby wieder ausschalten. Die Antwortzeiten sind zwischen 4 und 10 Skeunden für DNS anfragen. Geht gar nicht. Hast du eine Idee was hier falsch läuft? Die Testserver habe ich alle ausgeklammert und Quad9 und Cloudflare angeschaltet.

    • Ich mag nicht mehr... Hatte die doch nicht ausgeklammert und die haben das so langsam gemacht. Mal gucken wie es jetzt läuft...

    • also bei mir sind die Antwortzeiten sehr gut...

      benutze Cloudflare als Resolver und habe Pingzeiten von 10-20ms je nachdem wo es hin geht.


      Aber berichte mal bitte

  • Hab mich an die Anleitung für DOT gehalten, ich kann aber nur Quad9 als Resolver nutzen. Sobald ein andere aktiviert ist, bekomme ich nur connection refused... Jemand ne Idee?

    • Habs... Scheiss YAML ist so empfindlich

    • Ja, yaml ist manchmal doof … aber json ist schlimmer 😂

      Haha 1

  • Hallo,


    sehr gutes Tutorial erstmal :). Ich hätte da noch 2 Fragen:


    1. Im Terminal mit der Abfrage aus dem Tutorial zeigt es mir zwar an, dass ich über TLS verbunden bin aber über etwaige websites wie: https://tenta.com/test oder 1.1.1.1/help , wird mir mitgeteilt, dass ich wohl ohne TLS bzw DOT surfe ? Gibt es dafür einen Grund ?


    2. Wie sieht es denn aus, wenn ich gerne auch IPV6 hätte, wie würde ich da vorgehen ?

    Liebe Grüße

    • Meines Wissens nach klappt der Cloudflare Test nur mit den eigenen Cloudflare Resolvern. Benutzt du Cloudflare als Upstream?


      Diese Testseiten haben alle einen Hinkefuß siehe hier:

      https://www.computerbase.de/fo…-dot-nicht-aktiv.2055609/


      Bei IPv6 bin ich leider raus, denke mal du musst in Stubby die die v6 Upstreams wählen.

  • Hallo komme da an einem Punkt nicht weiter,

    Code
    @PiHole:~# dig @127.0.2.2 -p 10053 fail01.dnssec.works

; <<>> DiG 9.11.5-P4-5.1+deb10u7-Debian <<>> @127.0.2.2 -p 10053 fail01.dnssec.works
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

    hier sollte doch SERVFAIL kommen oder?

    Und wenn ich auf PiHole gehe, da zeigt er mir dies an

    Code
    There was a problem applying your settings.
Debugging information:
PHP error (2): fsockopen(): unable to connect to 127.0.0.1:4711 (Connection refused) in /var/www/html/admin/scripts/pi-hole/php/FTL.php:44

    Irgendwas mache ich wohl falsch, nur was :thinking_face:

    • Ja müsste!

      Hast du dich also für DoT entschieden?


      Stubby ist installiert? Stubby ist als Upstream in PiHole eingetragen mit passendem Port?

      Stubby benutzt einen Server der DNSSEC unterstützt?

    • Alles genau so gemacht wie in der Anleitung. In PiHole ist es auch wie oben geschrieben mit Port usw. eingetragen.

      Habe vorhin noch auf Google gewechselt, aber das selbe Ergebnis.

    • ich hab es, da kommt ein Fehler wegen config

    • Habe noch Screenshots in das Tutorial gestellt, wie das ergebnis bei dig und kdig aussehen müsste.


      Und ja er zeigt dir ja auch an das DNSSEC off ist...und das er keine config hat ...

    • So, habe alles mal gelöscht, neuen Container erstellt und sobald ich die stubby.yml ändere findet er sie nicht mehr :pouting_face:

      Code
      Aug 23 14:26:28 PiHole stubby[13215]: Error parsing config file "/etc/stubby/stubby.yml": Generic error
Aug 23 14:26:28 PiHole stubby[13215]: WARNING: No Stubby config file found... using minimal default config (Opportunistic Usage)

      Nutze nano als Editor, der haut wohl das File kaputt, grr

  • Hallo @defcon,

    Danke für diesen Beitrag :smiling_face:

    Kannst Du mir bitte noch erklären, wie ich nachträglich den "listing socket port 53" ändere?

    Ich hatte zwar den Port 10055 (im pi-hole und in der *.xml datei) angegeben, der wird aber nicht gezogen.

    Da es mein zweiter pi-hole im Netz ist ist mir die Meldung auch klar.

    Leider weiß ich nicht wie ich den Port anderweitig ändern kann damit der pi-hole auch läuft.

    Hast Du ein Tipp für mich?

    Danke.


    Ich bekomme folgende Meldung im pi-hole:

    DNSMASQ_CONFIGFTL failed to start due to failed to create listening socket for port 53: Die Adresse wird bereits verwendet

    • Hi @FBausMS , doofe Frage, hast du die Kiste mal durchgetreten? Hatte bei der Installation die gleiche Meldung soweit ich mich erinnern kann, ein Reboot und die Sache war erledigt.


      Habe auch 2 PiHoles am laufen.

    • Hi defcon,

      Danke für Deine Antwort.

      ja habe ich schon mehrfach.

      Ich vermute, dass der Port noch irgendwo anders hingelegt ist und die Eintragungen im Pi-hole oder anderweitig überschreibt.

      Wo könnte ich noch den Eintrag finden?

    • @defcon

      Hi defcon,

      ich habe nun einen neunen raspi aufgesetzt mit pi-hole- DoH und eigenem Port.

      Das hat sofort funktioniert, auch nach Neustart :smiling_face:

      Danke für diesen Beitrag!

  • bei mir geht alles nur bei kdig versagt die Kunst

    Hat jmd eine Idee??

    (dennoch ein herzliches DANKE an den Verfasser. Sehr schön beschrieben und erklärt)


    kdig ubiquiti-networks-forum.de +tls

    ;; WARNING: can't connect to XXX.XXX.XXX.XXX@853(TCP)

    ;; ERROR: failed to query server XXX.XXX.XXX.XXX@853(TCP)


    XXX = lokale ip der UDMP

    • Hallo @mbe


      tatsächlich mein Fehler... der Befehl muss so lauten:


      kdig @dns.quad9.net ubiquiti-networks-forum.de +tls


      das "dns.quad9.net" mit deinem gewählten Resolver ersetzen.

  • Super Anleitung, Dankeschön. Ergänzend möchte ich noch erwähnen das man externe DNS Anfragen mit Unbound noch weiter reduzieren kann. Unbound reduziert die DNS Anfragen auf ein minimum und fungiert intern als DNS Proxy und unterstützt auch DNSSEC. https://nlnetlabs.nl/documentation/unbound/

    • Hallo @uboot21

      Das mit Unbound ist natürlich vollkommen richtig, jedoch finde ich das es erstmal einige Zeit dauert bis unbound performant läuft. Unbound fragt ja direkt bei den root servern an und cached dann. Für mich ist das oben beschriebene Tutorial der gesunde Mittelweg.

      Gefällt mir 1