DNS over TLS Einrichtung
-
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:
- pfsense.pool.ntp.org
- www.openbl.org (+ AAAA und CNAME)
-
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.