Danke!
Beiträge von TheFreeman
-
-
Hi,
wann macht es Sinn, eine USG PRO vor die UDM x zu packen?
Macht das überhaupt Sinn?🤔
LG
-
Ja, das habe ich verstanden.
Ich warte mal darauf, dass jemand den zusätzlichen Post liest. 😁☺️
-
Hmm.... Ich hab das jetzt schon ne Stunde im TMUX laufen....
Aber da kommt nichts..... Zumindest nicht über die VLANsAber da es sich um TCPdump hadelt..... Im piHole steht doch etwas von UDP, oder?
CodeOct 7 13:07:01 dnsmasq[22173]: query[PTR] b._dns-sd._udp.0.0.168.192.in-addr.arpa from 192.168.0.254 Oct 7 13:07:01 dnsmasq[22173]: query[PTR] b._dns-sd._udp.0.0.168.192.in-addr.arpa from 192.168.0.254 Oct 7 13:07:01 dnsmasq[22173]: query[PTR] b._dns-sd._udp.0.0.168.192.in-addr.arpa from 192.168.0.254 Oct 7 13:07:01 dnsmasq[22173]: query[PTR] b._dns-sd._udp.0.0.168.192.in-addr.arpa from 192.168.0.254 Oct 7 13:07:01 dnsmasq[22173]: query[PTR] b._dns-sd._udp.0.0.168.192.in-addr.arpa from 192.168.0.254
Also mit tcpdump -i br0 | grep mdns kommt jede Menge.
Hier mal ein Auszug:Code
Alles anzeigen15:13:14.718374 IP6 fe80::72d9:b266:eb70:3c68.mdns > ff02::fb.mdns: 0*- [0q] 1/0/0 (Cache flush) AAAA fe80::72d9:b266:eb70:3c68 (52) 15:13:14.718757 IP 192.168.0.252.mdns > mdns.mcast.net.mdns: 47605+ ANY (QM)? Bose-SM2-d43639899ecf.local. (45) 15:13:14.719046 IP6 fe80::9a9b:cbff:feb0:9fae.mdns > ff02::fb.mdns: 47605+ ANY (QM)? Bose-SM2-d43639899ecf.local. (45) 15:13:14.719556 IP 192.168.0.252.mdns > mdns.mcast.net.mdns: 43205+ ANY (QM)? MoeniKommandoZentrale.local. (45) 15:13:14.719813 IP unifi.mdns > mdns.mcast.net.mdns: 0*- [0q] 2/0/0 (Cache flush) AAAA fe80::245a:4cff:fe96:430a, (Cache flush) A 192.168.0.254 (83) 15:13:14.719860 IP6 fe80::9a9b:cbff:feb0:9fae.mdns > ff02::fb.mdns: 43205+ ANY (QM)? MoeniKommandoZentrale.local. (45) 15:13:14.720116 IP6 fe80::245a:4cff:fe96:430a.mdns > ff02::fb.mdns: 0*- [0q] 1/0/0 (Cache flush) AAAA fe80::245a:4cff:fe96:430a (67) 15:13:14.743961 IP BRNB42200C179E6.mdns > mdns.mcast.net.mdns: 0*- [0q] 2/0/1 (Cache flush) A 192.168.0.50, (Cache flush) AAAA fe80::b622:ff:fec1:79e6 (97) 15:13:14.744100 IP6 fe80::b622:ff:fec1:79e6.mdns > ff02::fb.mdns: 0*- [0q] 2/0/1 (Cache flush) A 192.168.0.50, (Cache flush) AAAA fe80::b622:ff:fec1:79e6 (97) 15:13:14.759471 IP nas.ext.local.de.mdns > mdns.mcast.net.mdns: 0*- [0q] 1/0/0 (Cache flush) A 192.168.0.6 (44) 15:13:14.800786 IP 192.168.0.74.mdns > mdns.mcast.net.mdns: 0*- [0q] 1/0/1 (Cache flush) A 192.168.0.74 (61) 15:13:14.802289 IP Mac-mini.mdns > mdns.mcast.net.mdns: 0*- [0q] 2/0/1 (Cache flush) AAAA fe80::c5:9ee0:807c:f98, (Cache flush) A 192.168.0.188 (90) 15:13:14.802431 IP6 fe80::c5:9ee0:807c:f98.mdns > ff02::fb.mdns: 0*- [0q] 2/0/1 (Cache flush) AAAA fe80::c5:9ee0:807c:f98, (Cache flush) A 192.168.0.188 (90) 15:13:14.808661 IP Samsung.mdns > mdns.mcast.net.mdns: 0*- [0q] 1/0/2 (Cache flush) A 192.168.0.160 (78) 15:13:14.811029 IP 192.168.0.76.mdns > mdns.mcast.net.mdns: 0*- [0q] 1/0/1 (Cache flush) A 192.168.0.76 (61) 15:13:14.821856 IP BOSE-OBEN.mdns > mdns.mcast.net.mdns: 0*- [0q] 2/0/0 (Cache flush) HINFO, (Cache flush) A 192.168.0.60 (80) 15:13:14.887628 IP 192.168.0.5.mdns > mdns.mcast.net.mdns: 0 [b2&3=0x400] [1au] A (QM)? QNAP-NAS01.local. (50) 15:13:14.894056 IP BOSE-UNTEN.mdns > mdns.mcast.net.mdns: 0*- [0q] 2/0/0 (Cache flush) HINFO, (Cache flush) A 192.168.0.62 (80) 15:13:15.057431 IP 192.168.0.153.mdns > mdns.mcast.net.mdns: 0*- [0q] 1/0/1 (Cache flush) A 192.168.0.153 (70) 15:13:55.036706 IP Samsung.mdns > mdns.mcast.net.mdns: 0 [6a] [1au] PTR (QM)? _http._tcp.local. (225) 15:13:55.037858 IP unifi.mdns > mdns.mcast.net.mdns: 0*- [0q] 4/0/0 PTR shellypro3em-34987a44ec64._http._tcp.local., (Cache flush) SRV ShellyPro3EM-34987A44EC64.local.:80 0 0, (Cache flush) TXT "gen=2", (Cache flush) A 192.168.50.107 (148) 15:13:55.068494 IP unifi.mdns > mdns.mcast.net.mdns: 0*- [0q] 4/0/0 PTR wled-6abd03._http._tcp.local., (Cache flush) SRV wled-6abd03.local.:80 0 0, (Cache flush) TXT "", (Cache flush) A 192.168.50.101 (115) 15:13:55.090107 IP unifi.mdns > mdns.mcast.net.mdns: 0*- [0q] 4/0/0 PTR shellyplus2pm-a0dd6c28d12c._http._tcp.local., SRV ShellyPlus2PM-A0DD6C28D12C.local.:80 0 0, TXT "gen=2", (Cache flush) A 192.168.50.108 (150) 15:13:55.096752 IP unifi.mdns > mdns.mcast.net.mdns: 0*- [0q] 4/0/0 PTR wled-51a480._http._tcp.local., (Cache flush) SRV wled-51a480.local.:80 0 0, (Cache flush) TXT "", (Cache flush) A 192.168.50.103 (115) 15:13:55.124598 IP unifi.mdns > mdns.mcast.net.mdns: 0*- [0q] 4/0/0 PTR wled-ad8223._http._tcp.local., (Cache flush) SRV wled-ad8223.local.:80 0 0, (Cache flush) TXT "", (Cache flush) A 192.168.50.102 (115) 15:13:55.126887 IP unifi.mdns > mdns.mcast.net.mdns: 0*- [0q] 4/0/0 PTR shellypro4pm-08f9e0e53960._http._tcp.local., SRV ShellyPro4PM-08F9E0E53960.local.:80 0 0, TXT "gen=2", (Cache flush) A 192.168.50.110 (148) 15:13:55.142999 IP unifi.mdns > mdns.mcast.net.mdns: 0*- [0q] 4/0/0 PTR shellyplus2pm-c4d8d557baf0._http._tcp.local., SRV ShellyPlus2PM-C4D8D557BAF0.local.:80 0 0, TXT "gen=2", (Cache flush) A 192.168.50.162 (150) 15:14:25.161507 IP BOSE-OBEN.mdns > mdns.mcast.net.mdns: 0 [2q] SRV (QM)? BOSE UNTEN._soundtouch._tcp.local. SRV (QM)? BOSE OBEN._soundtouch._tcp.local. (67) 15:14:25.161679 IP BOSE-OBEN.mdns > mdns.mcast.net.mdns: 0*- [0q] 2/0/0 (Cache flush) SRV Bose-SM2-d43639899ecf.local.:8090 0 0, (Cache flush) A 192.168.0.60 (102) 15:14:25.192005 IP BOSE-UNTEN.mdns > mdns.mcast.net.mdns: 0*- [0q] 2/0/0 (Cache flush) SRV Bose-SM2-a81b6a654228.local.:8090 0 0, (Cache flush) A 192.168.0.62 (103)
-
-
Danke. Genau danach habe ich gesucht. 👍
-
Niemand?
-
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:
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.Ich habe hier noch eine Menge dazu hrauslesen können: https://discourse.pi-hole.net/…es-in-the-query-log/44429
-
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.
Keines davon ist bei mir zutreffend. Ich habe keinen Bonjour-Dienst im Netzwerk.
Ich habe einen neuen Drucker und neue MACs. -
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.
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?
-
Also wenn ich das richtig verstehe, dann kann ich den Übeltäter, wwenn es nicht die UDM ist, nur über diese herausfinden, richtig?
Kann man dazu in der UDM ein LOG einsehen, um zu sehen, wer da diese Anfragen an die UDM richtet? -
🤣🤣🤣 Heilige Entität? 👍
Mir war halt danach.
Kannst du mir das bitte alles nochmal gut verständlich auf Deutsch übersetzen? 😇😎🤔
Hab nur 50% verstanden.
-
Hi.
Irgendwie geht mir die Backup - Geschichten auf den Geist.
Online Backups möchte ich nicht.
Ich backuppe alles andere automatisiert auf meine QNAP NAS per RSYNC.
Hat von euch jemand eine Lösung für die UDM und deren Apps als automatisierte Backups ins Netzwerk oder NAS?
LG
-
-
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.
-
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. 👍
-
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... -
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. -
Ich denke, ich habe die Lösung schon gefunden:
https://docs.pi-hole.net/ftldn…e/?h=addresses#pihole_ptr -
Hi,
was genau macht die UDM, wenn die meinen piHole mit solchen Abfragen bombardiert?
CodeOct 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?
Danke schon Mal!