Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    DNS over TLS Einrichtung

    Scheduled Pinned Locked Moved Deutsch
    15 Posts 2 Posters 1.7k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • V
      viragomann
      last edited by

      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.".

      1 Reply Last reply Reply Quote 0
      • U
        un1que
        last edited by

        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).

        1 Reply Last reply Reply Quote 0
        • V
          viragomann
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • U
            un1que
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • V
              viragomann
              last edited by

              Hi,

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

              1 Reply Last reply Reply Quote 0
              • U
                un1que
                last edited by

                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)
                1 Reply Last reply Reply Quote 0
                • V
                  viragomann
                  last edited by

                  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.

                  1 Reply Last reply Reply Quote 0
                  • U
                    un1que
                    last edited by

                    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?

                    1 Reply Last reply Reply Quote 0
                    • V
                      viragomann
                      last edited by

                      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.

                      1 Reply Last reply Reply Quote 0
                      • U
                        un1que
                        last edited by

                        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.

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.