Hallo.
Hier gibt es einen merkwürdigen Effekt auf unserer OPNSense (24.1.2_1-amd64).
Wenn ich unter Berichterstattung -> Unbound DNS nachsehe, wird
als „Top passed Domain“ einfach nur „to.“ gelistet. Je nachdem, wie viel gerade im Netzwerk los ist, kann dieser Eintrag schon mal auf den vorderen Plätzen mitmischen.
Bei den Log-Details steht dann, dass die Anfrage vom Server (10.16.1.1) kommt. In den Details der Anfrage steht einfach nur sowas wie: server.meine-schule.de A to. Pass Cache NOERROR 0ms 1407
Diese Einträge wiederholen sich oft. Leider habe ich keine gute Erklärung was das ist oder wie das da reingekommen ist. Der Verdacht liegt nahe, dass im AD bzw DNS des Servers etwas nicht ganz stimmt – aber was kann das sein? Seltsam finde ich auch, dass es sich da um einen (unvollständigen) A-Record handelt
Also einfach nur to ohne weiteren Domainnamen o.ä.
Wenn man die Berichte übrigens löscht, tauchen die Einträge kurz danach wieder auf. Es wird also aktiv vom Server versucht, eine Verbindung aufzubauen, die dann offenbar im Nirvana landen muss?!?
Wer hat eine gute Idee, was das sein kann oder wie man das abstellt?
Wie zu erwarten, liefern die Anfragen host to oder auch nslookup to auf dem Server nichts.
Wer hat eine gute Idee, wie man das eingrenzen kann?
Viele Grüße,
Michael
könnte es sein, dass da ein Leerzeichen im Log zwischen to und dem Punkt fehlt? Mit . könnte dann die DNS-Rootzone gemeint sein. Da auf dem Server ja ein DNS-Server läuft, könnte der Bedarf haben sich aktuelle IPs der Rootzone-DNS-Server abzurufen. Oder zwischen to und Punkt fehlt eine Angabe eines Ziels, weil ein DNS-Override konfiguriert wurde, wo das Feld für „IP address“ leer gelassen wurde? vgl. Unbound DNS — OPNsense documentation
Das war copy & paste – von daher: Im Log steht es so: to. (ohne Leerzeichen)
Mittlerweile habe ich gesehen, dass in den besagten Log-Files durchaus auch solche Einträge vorkommen:
server.meine-schule.de A com. Pass Cache NOERROR 0ms 563
(aber viel selterner als to.)
oder auch
server.meine-schule.de DS email. Pass Cache NOERROR 0ms 2110
(wobei ich nicht weiß, wofür „DS“ steht). Aber das com. ist genauso seltsam wie das to. , oder?
Wir haben ein paar Overrides definiert.
Da steht aber nirgendwo ein „to“ – bei den Überschreibungen geht es immer nur darum, dass Server direkt bei uns im LAN gefunden werden, anstatt zuerst nach draußen zu routen. Das ist es also vermutlich nicht.
Vielleicht kommen wir der Sache ja noch auf die Spur.
Viele Grüße,
Michael
ich meinte nicht, dass du was ausgelassen hast, sondern die Software vielleicht beim Protokollieren was ausgelassen hat. Das Log könnte vielleicht so zu lesen sein:
<Client> <Ressource-Record> to <Domain>. Pass Cache ...
Client ist server.meine-schule.de Ressource-Record kann A, MX, DS, TXT usw. sein, alles was auf Resource Record – Wikipedia gelistet ist. to steht für „DNS-Paket geht zu/nach/an“ Domain wäre dann aus irgendeinem Grund (Softwarefehler, Fehlkonfiguration, …) leer. . steht für die Rootzone als Wurzel und Ende des DNS-Namens, siehe auch die Beispiele im RR-Wikipediaartikel
Wenn bei Domain nur com. und email. auftauchen, vielleicht wird auch nur die Top-Level-Domain (TLD) protokolliert. Wenn dann ein Client nur Hostnamen statt FQDN abfragen würde, wäre im Protokoll das Feld <Domain> für die TLD leer. In dem Fall müsste man in der Konfiguration des DNS-Servers auf server.meine-schule.de nachschauen und den so einstellen, dass an Anfragen, die nur aus Hostnamen bestehen (s)eine (Standard)-Domain selbst anhängt oder diese Anfragen nicht weiterleitet.
