DNS over TLS Einrichtung



  • Hallo,

    habe nach dieser Anleitung DNS over TLS zu den Cloudflare DNS Servern eingerichtet.

    So, meinem Verständnis nach sollte jetzt doch alles verschlüsselt über den Port 853 laufen oder? Allerdings sehe ich mehrere aufgebaute Verbindungen über den Standard Port 53 (siehe Screenshot). Kann mir jemand erklären woher das kommt? Habe ich etwas falsch gemacht ?

    Bin für jeden Tipp sehr dankbar!



  • Hallo,

    der Link funktioniert leider nicht. Da wurde vor dem URL noch ein "http" gesetzt.

    Hast du vielleicht im General Setup eine der beide Optionen
    DNS Server Override
    Disable DNS Forwarder
    angehakt?



  • Ups, da hat sich ein Fehler eingeschlichen, habs korrigiert. Also ich meinte die offizielle Anleitung von Netgate.

    Ne, keine der beiden Optionen ist angehakt, auch nicht die "DNS Query Forwarding" (im DNS Resolver).

    *edit: Mir ist gerade noch aufgefallen, dass ich bei mir kein Gateway dem jeweiligen DNS-Server zugeordnet habe. Kann es evtl. daran liegen? Damit hätte ich aber ein Problem, weil ich mehrere Gateways habe und somit mit den 2 Servern nicht auskommen würde.



  • Das kann ich mir nicht vorstellen. Die Funktion sollte einfach alle DNS Anfragen an die pfSense an die TLS-Ports der Server weiterleiten. Die genutze Route sollte dabei nicht relevant sein.

    Werden eigentlich alle Anfragen auf Port 53 rausgeschickt, oder auch welche auf 853?



  • Nein, die meisten gehen dann auch tatsächlich auf den Port 853 raus. Nur sehr wenige werden auf den Port 53 rausgeschickt.

    Also, ich habe jetzt mal das Packet Capture bemüht und mir die Ausgabe angeschaut. Das sind aber irgendwie keine "richtigen" DNS Anfragen. Es werden nicht die A-, sondern alles nur PTR-Records abgefragt :o
    Eine Idee worauf das hindeuten könnte?



  • Also was bei dir diese PTR-Auflösungen anfragt, solltest du selbst am besten herausfinden können, ev. mittels Packet Capture am internen Interface untersuchen.
    Typischerweise machen SMTP-Server gerne solche Abfragen, um die DNS-Einträge der IPs anliefernder Server mit den Host-Header gegenüberzustellen.

    Ein Weiterleitung von PTR-Einträgen erfordert wohl eine weitere Konfiguration. Ich habe das in Unbound auch noch nie gemacht, aber vermutlich heißt die Zone, die weiterzuleiten wäre, einfach ".in-addr.arpa.".



  • Also diese PTR-Anfragen können von mir aus verworfen werden, ich brauche sie nicht ;D

    Die Frage ist nur, woher diese kommen. Ich habe mal am internen Interface das Packet Capture laufen gelassen, aber über einen längeren Zeitraum keine PTR-Anfragen gefunden.

    Daraufhin habe ich die pfSense Mail-Benachrichtigungen abgeschaltet, nochmal die States zurückgesetzt und fast eine Stunde auf dem WAN-Interface mitgeschnitten. Seitdem habe ich 2 Dinge festgestellt:
    -es werden keine PTR-Records mehr angefragt,
    -dafür aber mehrere A-Records, ich habe mir diese angeschaut und bin der festen Überzeugung, dass das alles aufgelöste Hosts aus den angelegten Aliassen sind.

    Nun, scheinbar leitet pfSense alle Client-DNS-Anfragen verschlüsselt weiter, ihre eigenen schickt sie aber ganz normal auf den Port 53 raus.
    Nur, um es noch einmal zu bestätigen: der Punkt "Disable DNS Forwarder" im General Setup ist definitiv nicht angehakt, neugestartet wurde die pfSense auch (gestern, nach dem Update auf 2.3.4_1).



  • Das würde heißen, dass die pfSense selbst nicht den Resolver verwendet. Die Weiterleitung durch den Resolver über TLS funktoiniert ja.
    Sobald ich hier bei mir den Resolver aktiviere, verwendet die pfSense diesen auch. Leicht festzustellen mittles einer dig-Abfrage in der Shell.

    Einzige Ursache, die mir dazu noch einfällt, ist, dass im Resolver bei "Network Interfaces" weder "All" noch "localhost" ausgewählt wäre.
    Doch lässt sich das nur so konfigurieren, wenn im General Setup bei "Disable DNS Forwarder" der Haken gesetzt ist, allerdings lässt sich dieser Haken nach getaner Resolver-Konfiguration ohne Reklamation entfernen.



  • Ja, du hast Recht, das habe ich gar nicht bedacht, dass localhost mit angewählt sein muss (ich habe nur bestimmte Interfaces ausgewählt). Danke dafür!

    Allerdings laufen bei mir die Sachen weiterhin auf den Port 53 hinaus. Keine Ahnung, was das Problem ist. Habe auch schon die dig-Abfragen gemacht und konnte sehen, dass diese zunächst direkt an Cloudflare rausgeschickt wurden (unter "Network Interfaces" "localhost" nicht ausgewählt) und nach der Umstellung dann richtigerweise an localhost. Habe zunächst die States und Filter zurückgesetzt, später sogar die pfSense neugestartet: hat alles nicht geholfen.



  • Hi,

    ja hast du der Resolver-Weiterleitung auch schon die Zone ".in-addr.arpa.", oder wie die auch immer heißen soll, hinzugefügt?



  • Nee, mach ich gleich. Ich bin nur halt davon ausgegangen, dass die pfSense ihre eigenen Dienste unter Kontrolle haben sollte… und falls die PTR-Geschichte per default eben nicht funktioniert, dann hätte man das wohl mit in die offizielle Anleitung aufnehmen sollen?

    Wie würde das richtigerweise aussehen? Unter den bereits vorhandenen Zeilen forward-zone: und name: ".", eine weitere name: ".in-addr.arpa." hinzufügen?
    *edit: ok, das klappt schon mal nicht (/var/unbound/test/unbound.conf:105: error: forward name override, there must be one name for one forward-zone), mit einer komplett neuen Zone auch nicht.

    Aber schließlich sind PTR-Anfragen weiterhin nicht die einzigen. Es gibt noch ein paar A-Anfragen:



  • Sorry, wie schon geschrieben, ich hab eine solche Weiterleitung im Resolver auch noch nie gemacht.
    Ich hätte es auch einfach mit einer zusätzlichen Zonen-Zeile versucht, oder mit einem kompletten zweiten Forward-Abschnitt und anderenfalls die Suchmaschine bemüht.



  • Ok, werde nachher mal google bemühen und melde mich wieder. Hast du evtl. eine Idee, warum die anderen beiden Anfragen (bzw. es gab mehrere) und nur diese auf den Port 53 rausgeschickt wurden? Eigentlich sollten sie ja mit der bestehenden Weiterleitung abgedeckt sein?



  • Wenn das nicht durch das Hinzufügen des localhost zu den "Network Interfaces" im Resolver behoben wurde, bin ich auch ratlos, woran es liegen könnte.
    Das hätte gepasst, wenn es Anfragen der pfSense selbst sind und diese nicht am Resolver zugreifen kann, schickt sie die Anfragen klarerweise an die DNS-Server im General Setup.



  • Also ich glaube und hoffe die Ursache gefunden zu haben. Kann es sein, dass nTop diese ganzen Anfragen generiert? Ich habe das Paket mal ausgeschaltet und werde ein paar Stunden beobachten.

    *edit: Hmm, wohl doch nicht… aber die PTR-Anfragen sind scheinbar nicht mehr vorhanden.