UDM spamt pihole mit .in-addr.arpa Abfragen

Es gibt 27 Antworten in diesem Thema, welches 2.479 mal aufgerufen wurde. Der letzte Beitrag () ist von TheFreeman.

  • Hi,


    was genau macht die UDM, wenn die meinen piHole mit solchen Abfragen bombardiert?


    Code
    Oct  4 14:25:57 dnsmasq[964746]: query[PTR] lb._dns-sd._udp.0.0.168.192.in-addr.arpa from 192.168.0.xxx
    Oct  4 14:25:57 dnsmasq[964746]: query[PTR] b._dns-sd._udp.0.0.168.192.in-addr.arpa from 192.168.0.xxx
    Oct  4 14:25:57 dnsmasq[964746]: query[PTR] b._dns-sd._udp.0.0.168.192.in-addr.arpa from 192.168.0.xxx
    Oct  4 14:25:57 dnsmasq[964746]: query[PTR] b._dns-sd._udp.0.0.168.192.in-addr.arpa from 192.168.0.xxx
    Oct  4 14:25:57 dnsmasq[964746]: query[PTR] b._dns-sd._udp.0.0.168.192.in-addr.arpa from 192.168.0.xxx
    Oct  4 14:25:57 dnsmasq[964746]: query[PTR] lb._dns-sd._udp.0.0.168.192.in-addr.arpa from 192.168.0.xxx
    Oct  4 14:25:57 dnsmasq[964746]: query[PTR] b._dns-sd._udp.0.0.168.192.in-addr.arpa from 192.168.0.xxx
    Oct  4 14:25:57 dnsmasq[964746]: query[PTR] lb._dns-sd._udp.0.0.168.192.in-addr.arpa from 192.168.0.xxx
    Oct  4 14:25:57 dnsmasq[964746]: query[PTR] lb._dns-sd._udp.0.0.168.192.in-addr.arpa from 192.168.0.xxx

    Wie kann ich diese Abfragen aus der Statistik meines piHoles herausnehmen, bzw. kann ich diese Abfragen gegen piHole irgendwie unterdrücken, ohne diesen aus dem DNS-Eintrag in der UDM zu nehmen? :thinking_face:


    Danke schon Mal! :upside_down_face:

  • Ich denke, ich habe die Lösung schon gefunden:
    https://docs.pi-hole.net/ftldn…e/?h=addresses#pihole_ptr

    :grinning_squinting_face:

  • Danke!

    Aber, wie schon von mir geschrieben, habe ich meine piHoles nun so konfiguriert, dass sie PTR-Anfragen einfach ignorieren.
    Die UDM ist ja der dhcp und weiss auch die Namen der Hosts. :smiling_face:

  • iTweek

    Hat das Label von offen auf erledigt geändert.
  • Danke!

    Aber, wie schon von mir geschrieben, habe ich meine piHoles nun so konfiguriert, dass sie PTR-Anfragen einfach ignorieren.
    Die UDM ist ja der dhcp und weiss auch die Namen der Hosts. :smiling_face:

    Wenn deine UDM den Pihole befragt, hast Du sicher den Pihole im WAN angegeben als DNS ... Das ist so auch nicht Sinn der Sache.

  • Wenn deine UDM den Pihole befragt, hast Du sicher den Pihole im WAN angegeben als DNS ... Das ist so auch nicht Sinn der Sache.

    Jup. Korrekt. Warum nicht?
    Ich bin gespannt...

  • Ahja. Solche Antworten machen Sinn.

    Vielen Dank dafür. 👍

    Sicher hat jemand einen Link zum entsprechenden Post. ☺️

    So hätte ich das jedenfalls gemacht, anstatt einfach nur den Post Counter zu bedienen. 👍

  • Ich meine hier kannst du dazu was lesen:

  • Hmm...

    Vielen Dank. Aber da lese ich nur heraus, bei wem welche Konfigs funktionieren und welche nicht. Meine funktioniert hervorragend, da ich die DNS-Roots in meinen PiHoles nutze.

    Also, ich versuche eine obal gültige Regel zu erkennen.

  • Ich hatte das bei mir ebenfalls wie Du eingerichtet.

    Lief wunderbar, hatte keine Probleme.


    Ja, im pihole war immer nur die Anfrage der UDM zu sehen, keine IPs und ich wusste nicht welches Gerät was da so anfragt.

    Mir war das egal und es lief. Wenn es bei Dir läuft, dann lass es laufen.

  • Danke.

    😁

  • dnsmasq[964746]: query[PTR] b._dns-sd._udp.0.0.168.192.in-addr.arpa from 192.168.0.xxx

    Erstmal warum zum Heiligen Entität deine Wahl zensierst du ne RFC1918 Adresse ?

    Nun sei es drum Gerät 192.168.0.xxx fragt also nach den Eintrag für den

    DNS-SD Dienst. Ein Protokoll das Service Discovery über normales DNS macht.

    Sprich ähnliches wie mDNS genauer gesagt auch von Apple für Ronja


    Fragt sich nur wer genau hier DNS-SD mache will. Das Zeugs ist Sten alt.

    IOT Geräte werden eher mDNS verwenden. (sehr) Alter Drucker ?

    Altes Mac OS (so 2010-2014 rum) bzw. ein alter Bonjour Dienst auf ner Windows Kiste

    die das mitbekommt weil nen altes iTunes da seine Dienste verrichtet ?

    Oder irgendwas das Ständig vermischt rauszufinden was für Services im Netz verfügbar sind ?


    DNS-SD is wohl eher selten eingerichtet weil zum "guten" funktionieren Dynamische

    DNS Update erforderlich sind und Konfiguration von einem DNS Server benötigt

    das dann auch zulässt ohne das client B gleich alles in den Jordan reißen kann.

    (oder halt manuelle config). mDNS ist da etwas Cooler und Dynamischer am Gange

    weil es nichts braucht.


    Wenn du da einen Spammer hast, schalt ihn (oder die DNS-SD Funktion) und hab Ruhe

    Sonst gibt es von dann und wann mal ein paar abfragen als Grundrauschen.

    Allerdings nicht von Unifi Geräten. Die machen kein Service Discovery, warum auch.

  • 🤣🤣🤣 Heilige Entität? 👍

    Mir war halt danach.

    Kannst du mir das bitte alles nochmal gut verständlich auf Deutsch übersetzen? 😇😎🤔

    Hab nur 50% verstanden.

  • Also wenn ich das richtig verstehe, dann kann ich den Übeltäter, wwenn es nicht die UDM ist, nur über diese herausfinden, richtig? :confused_face:
    Kann man dazu in der UDM ein LOG einsehen, um zu sehen, wer da diese Anfragen an die UDM richtet? :thinking_face:

  • Ich habe eben auch mal wieder folgende Einträge vorgefunden:


    Time Type Domain Client Status Reply
    2024-10-05 16:11:52 PTR 1.101.10.10.in-addr.arpa BLA1.pc.local OK (cache) NXDOMAIN (0.0ms)
    2024-10-05 16:12:14 PTR 1.101.10.10.in-addr.arpa BLA1.pc.local OK (cache) NXDOMAIN (0.1ms)
    2024-10-05 16:12:08 PTR 131.209.251.142.in-addr.arpa BLA2.pc.local OK (answered by unbound02.dns.local#53) DOMAIN (15.0ms)
    2024-10-05 16:12:08 PTR 133.209.251.142.in-addr.arpa BLA2.pc.local OK (answered by unbound02.dns.local#53) DOMAIN (0.8ms)
    2024-10-05 16:12:37 PTR 138.209.251.142.in-addr.arpa BLA2.pc.local OK (answered by unbound02.dns.local#53) DOMAIN (14.4ms)
    2024-10-05 16:12:11 PTR 20.103.10.10.in-addr.arpa BLA2.pc.local OK (answered by unbound02.dns.local#53) NXDOMAIN (0.7ms)
    2024-10-05 16:12:17 PTR 202.181.250.142.in-addr.arpa BLA2.pc.local OK (answered by unbound02.dns.local#53) DOMAIN (46.6ms)
    2024-10-05 16:12:10 PTR 67.16.217.172.in-addr.arpa BLA2.pc.local OK (answered by unbound02.dns.local#53) DOMAIN (0.5ms)
    2024-10-05 16:12:08 PTR 8.111.10.10.in-addr.arpa BLA2.pc.local OK (cache) DOMAIN (0.1ms)
    2024-10-05 16:12:08 PTR 8.111.10.10.in-addr.arpa BLA2.pc.local OK (cache) DOMAIN (0.1ms)

    Die könnte ich mir auch gern sparen. Was hast Du denn konfiguriert TheFreeman :

    Ich denke, ich habe die Lösung schon gefunden:
    https://docs.pi-hole.net/ftldn…e/?h=addresses#pihole_ptr

    :grinning_squinting_face:

    ?

  • Ich habe eben auch mal wieder folgende Einträge vorgefunden:


    Time Type Domain Client Status Reply
    2024-10-05 16:11:52 PTR 1.101.10.10.in-addr.arpa BLA1.pc.local OK (cache) NXDOMAIN (0.0ms)
    2024-10-05 16:12:14 PTR 1.101.10.10.in-addr.arpa BLA1.pc.local OK (cache) NXDOMAIN (0.1ms)
    2024-10-05 16:12:08 PTR 131.209.251.142.in-addr.arpa BLA2.pc.local OK (answered by unbound02.dns.local#53) DOMAIN (15.0ms)
    2024-10-05 16:12:08 PTR 133.209.251.142.in-addr.arpa BLA2.pc.local OK (answered by unbound02.dns.local#53) DOMAIN (0.8ms)
    2024-10-05 16:12:37 PTR 138.209.251.142.in-addr.arpa BLA2.pc.local OK (answered by unbound02.dns.local#53) DOMAIN (14.4ms)
    2024-10-05 16:12:11 PTR 20.103.10.10.in-addr.arpa BLA2.pc.local OK (answered by unbound02.dns.local#53) NXDOMAIN (0.7ms)
    2024-10-05 16:12:17 PTR 202.181.250.142.in-addr.arpa BLA2.pc.local OK (answered by unbound02.dns.local#53) DOMAIN (46.6ms)
    2024-10-05 16:12:10 PTR 67.16.217.172.in-addr.arpa BLA2.pc.local OK (answered by unbound02.dns.local#53) DOMAIN (0.5ms)
    2024-10-05 16:12:08 PTR 8.111.10.10.in-addr.arpa BLA2.pc.local OK (cache) DOMAIN (0.1ms)
    2024-10-05 16:12:08 PTR 8.111.10.10.in-addr.arpa BLA2.pc.local OK (cache) DOMAIN (0.1ms)

    Die könnte ich mir auch gern sparen. Was hast Du denn konfiguriert TheFreeman :

    ?

    Ja, die tauchen bei mir auch noch auf, obwhol ich das per Konfig eigentlich ausgeschalten habe. :frowning_face:


    Irgendwie check ich das nicht. Warum tauchen dann Anteile der PTRs im System der UDM auf?


    Code
    :~# grep -rnw / -e 'dns-sd'
    /etc/dnsmasq.conf:641:#ptr-record=_http._tcp.dns-sd-services,"New Employee Page._http._tcp.dns-sd-services"
    /mnt/.rofs/etc/dnsmasq.conf:641:#ptr-record=_http._tcp.dns-sd-services,"New Employee Page._http._tcp.dns-sd-services"
    grep: /mnt/.rofs/usr/lib/aarch64-linux-gnu/libcups.so.2: binary file matches
    grep: /usr/lib/aarch64-linux-gnu/libcups.so.2: binary file matches
    grep: /var/log/journal/697dcce0053a52ecbcb3bfdbc4706bf2/system.journal: binary file matches

    Das verstehe ich nicht. Dann ist es ja doch die UDM, die bei den piHoles anfrägt?

  • Keines davon ist bei mir zutreffend. Ich habe keinen Bonjour-Dienst im Netzwerk.
    Ich habe einen neuen Drucker und neue MACs. :thinking_face:

  • Ich habe eben auch mal wieder folgende Einträge vorgefunden:

    Die könnte ich mir auch gern sparen. Was hast Du denn konfiguriert TheFreeman :

    ?

    Ich habe nun in meinen piHoles in der /etc/pihole/pihole-FTL.conf folgende Konfig angefügt:

    Code
    RESOLVE_IPV6=no
    RESOLVE_IPV4=no
    PIHOLE_PTR=NONE
    ANALYZE_ONLY_A_AND_AAAA=true

    Danach solltest Du FTL neu starten mit service pihole-FTL restart.
    Jetzt kommen keine PTR-Loops mehr zustande. Es kommt, wenn, dann nur ein einziger, der aber nicht verarbeitet wird und damit auch nicht in der Statistik autaucht. :smiling_face:


    Ich habe hier noch eine Menge dazu hrauslesen können: https://discourse.pi-hole.net/…es-in-the-query-log/44429

    Einmal editiert, zuletzt von TheFreeman ()

  • as verstehe ich nicht. Dann ist es ja doch die UDM, die bei den piHoles anfrägt?

    Schönen Dinge findest du da... Default Config Files die nicht in Nutzung sind.

    Irgend eine Printer Spooler Library die mit dem Kernel daher kommt aber auch nicht in Nutzung ist.


    Ja klar DNS-SD ist zwar alt und quasi Obsolete, wird aber durchaus immer noch benutzt und auch angefragt

    Ein paar Anfrage sind auch normal... nur Spam deutet auf ne fehl Konfiguration irgendwo hin.


    Keines davon ist bei mir zutreffend. Ich habe keinen Bonjour-Dienst im Netzwerk.
    Ich habe einen neuen Drucker und neue MACs

    Wiederspruch... Bonjour oder eher mDNS hat eigetlich jeder im Haus.

    Jedes APPLE gerät pustet darüber seine Dienste ins Netz.


    Lad dir Discovery aus dem Store (kostenlos) und staune selbst :smiling_face:

    Warum tauchen dann Anteile der PTRs im System der UDM auf?

    Weil da wohl irgendwer den DNS der UDM anfragt und dieser das an deinen PI weiterleitet...

    Machst du SSH auf die UDM


    tcpdump -I any -n port 56 und schau dir an wer wann wohin DNS macht.

    Einmal editiert, zuletzt von gierig ()