freetz dnsmasq Such Domain macht nicht das was Sie soll

michael_wl

Neuer User
Mitglied seit
14 Jul 2020
Beiträge
23
Punkte für Reaktionen
1
Punkte
3
Hallo Forum,

ich habe dnsmasq laufen mit den folgenden Einstellungen.
local-ttl=25200
domain-needed
log-async=25
no-resolv
server=192.168.12.1
server=192.168.12.1
bogus-priv
dhcp-range=192.168.12.150,192.168.12.249,774h
domain=micha.local
expand-hosts
read-ethers
stop-dns-rebind
### content of /tmp/flash/dnsmasq/dnsmasq.extra
dhcp-option=6,192.168.12.1,208.67.222.222,208.67.220.220 #Force DNS Server
dhcp-option=42,192.168.12.1,194.25.134.196 #Zeitserver Speedport NTP server

dnsmasq läuft auch super, nur eines verstehe ich nicht. Villeicht habt ihr eine Idee.

Der Befehl "scutil --dns" unter MAC zeigt mir
Code:
resolver #1
  search domain[0] : micha.local
  nameserver[0] : fe80::1%en0
  nameserver[1] : 192.168.12.1
  nameserver[2] : 208.67.222.222
  nameserver[3] : 208.67.220.220
  if_index : 4 (en0)
  flags    : Scoped, Request A records, Request AAAA records
  reach    : 0x00020002 (Reachable,Directly Reachable Address)

Wenn ich jetzt auf ein vorhandenes Gerät pine mit "ping pi-micha.micha.local" erhalte ich die Meldung "Unknown host".
Gebe ich ein "ping pi-micha.local" wird der Host ohne Probleme gefunden.

Irgendwas läuft hier schief, nur was. :(
 
Zuletzt bearbeitet:
Bin etwas weitergekommen, aber noch nicht zur Lösung.

Code:
dig @192.168.12.2 pi-micha.micha.local

ergibt die Ausgabe

Code:
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Raspbian <<>> @192.168.12.2 pi-micha.wlotkowski.local
; (1 server found)
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62051
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;pi-micha.micha.local.    IN    A

;; AUTHORITY SECTION:
.            567    IN    SOA    a.root-servers.net. nstld.verisign-grs.com. 2021070500 1800 900 604800 86400

;; Query time: 1006 msec
;; SERVER: 192.168.12.2#53(192.168.12.2)
;; WHEN: Mo Jul 05 20:39:18 CEST 2021
;; MSG SIZE  rcvd: 118

und

Code:
dig @192.168.12.2 pi-micha.micha.local -p 50053

Code:
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Raspbian <<>> @192.168.12.2 pi-micha.micha.local -p 50053
; (1 server found)
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25955
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;pi-micha.micha.local.    IN    A

;; ANSWER SECTION:
pi-micha.micha.local. 25200 IN    A    192.168.12.3

;; Query time: 1 msec
;; SERVER: 192.168.12.2#50053(192.168.12.2)
;; WHEN: Mo Jul 05 20:41:02 CEST 2021
;; MSG SIZE  rcvd: 70

Somit funktioniert dnsmasq, es wird nur der falsche Port angesprochen.

Code:
server=192.168.12.2#50053
Bringt leider keine Veränderung. Der Port bleibt bei #53.
 
Zuletzt bearbeitet:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
Gibt Dir das nicht zu denken?

Alles das, was mit einer TLD local arbeitet, wird üblicherweise (wenn der anfragende Client beides kennt) per mDNS aufgelöst und gar nicht erst ein (fester) DNS-Server dazu befragt - deshalb auch das "leaken" einer mDNS-Abfrage ins "richtige" DNS in der zweiten Zeile der Warnung, weil das eigentlich nicht vorkommen sollte, wenn der Client ordentlich arbeitet. Bei mDNS sind auch mehrstufige Namen zusammen mit der TLD eher ungewöhnlich - daher ist eine Verwendung dieser TLD für "normale" DNS-Server eigentlich ein no-go.

Deshalb funktioniert auch Dein ping pi-micha.local aus #1 vermutlich - da wird wohl ein mDNS-Daemon auf dem RasPi laufen, der regelmäßig den Server-Namen per Broadcast (bzw. Multicast) bekannt macht und auch ansonsten auf Suchen nach diesem Namen (innerhalb der TLD local) antwortet - das läuft dann aber über UPnP und nicht über DNS. Da wird für das Pingen also gar nicht über "richtiges" DNS aufgelöst, sondern über mDNS (Apple-Name Bonjour, Linux verwendet fast immer avahi).

Was soll eigentlich 192.168.12.2 sein? In allen Beiträgen taucht das nur in den dig-Aufrufen auf - woher soll ein Leser jetzt wissen, welche Aufgaben dieser Netzwerk-Client bei Dir hat und warum gerade auf dem irgendein Resolver läuft? Und wie hast Du den "offenen Port" 50053 am Ende gefunden? Bei mDNS wird üblicherweise UDP-Port 5353 verwendet - aber eben mit Multicast-Adressen. Daher paßt der offensichtlich auf Port 50053 laufende Resolver eigentlich in keine der beiden Welten so richtig hinein - kein DNS-Client fragt einen Server auf Port 50053 im normalen Leben und die Option existiert eigentlich auch nur, damit man einen Server testen/abfragen kann, der - warum auch immer - auf einen anderen Port konfiguriert wurde.

Welcher Prozess steckt denn hinter diesem offenen Port und was ist diese 192.168.12.2 überhaupt für ein System? Warum ist diese Adresse jetzt plötzlich auch noch im Spiel in #2, obwohl von ihr in #1 nie die Rede war?
 
  • Like
Reaktionen: michael_wl
Hallo @PeterPawn ,
danke für deine Antwort und Danke für das was du hier in diesem Forum machst. Ich selber nutze freetz bin aber lange nicht so tief drin in diesem Thema wie du.
Auskennen mit Hacken tu ich mich auch, aber auf einem anderen Gebiet. Bei Interesse kleine Werbung von mir wenn ich darf. Forum ist komplett offen auch für andere Themen wie freetz. Bin hier zu finden.
https://www.hackintosh-forum.de/user/38895-anonymous-writer/

Dnsmasq läuft bei mir auf der FritzBox mit freetz. Hintergrund ist das ich einen Speedport Hybride nutzen muss welcher leider ständig Probleme macht. Habe dann festgesellt wenn ich auf dem Speedport Hybride DHCP deaktiviere und dafür Dnsmasq vom freetz Paket benutze läuft das ganze Heimnetzt damit viel stabiler.
192.168.12.2 ist daher meine Fritzbox die per LAN mit dem Speedport Hybride verbunden ist.
Leider funktioniert das Setup auch nur richtig mit der neusten Firmware der Box. Ältere Versionen verweigern noch mehr die Zusammenarbeit vom Speedport Hybride mit der FritzBox.

Denn Port 50053 habe ich aus der freetz Dnsmasq Anleitung. Leider führt Port 53 zu ständigen Neustarts welche wahrscheinlich auf das alt bekannte Watchdog Problem zurück zu führen sind.

Dnsmasq auf Port 53 löst das Problem mit der Namensauflösung, führt aber dann zu denn ständigen Neustarts alle 3 Minuten.

Dnsmasq auf Port 5353 verhindern komplett die Namensauflösung. Warum auch immer.

freetz.jpg

Was Dnsmasq angeht bin ich was meine Erfahrung angeht noch ganz am Anfang.
Jedenfalls nochmal vielen Dank für deine Informationen. Ich werde mir diese Informationen am Wochenende nochmal ansehen und dann berichten.
 
Um das noch einmal ganz deutlich zu machen: Die TLD local ist NICHT für die Verwendung mit normalem DNS gedacht, egal welche Portnummern man da konfiguriert. DAS ist der Pferdefuß an dem ganzen Setup.

Und es macht keinen Sinn, einen DNS-Server für x-beliebige Clients zu betreiben, der auf einem anderen Port als 53 arbeitet - ganz einfach deshalb, weil es bei DNS-Einstellungen nur die Angabe eines Namens oder einer Adresse gibt und (üblicherweise) keinen Port. Einen Server abseits von Port 53 zu betreiben, macht nur dann einen Sinn, wenn es einen anderen Resolver irgendwo gibt, welcher auf Port 53 läuft und der eigentliche Ansprechpartner für die Clients ist, die eine Abfrage ausführen wollen. Das macht praktisch jedes Programm auf jedem Client selbst, weil das über eine Bibliothek erfolgt, die man mit ein paar Dateien passend konfigurieren kann, z.B. der /etc/resolv.conf: https://man7.org/linux/man-pages/man5/resolv.conf.5.html) und wenn dieser Resolver(-Server) dann seinerseits den Server auf dem "Nicht-Standard"-Port als Forwarder verwendet.

Schon die Kommunikation zwischen Name-Servern untereinander ist schwierig, wenn diese andere Ports als 53 verwenden. Es gibt in einem SOA-Record (das ist der "Startpunkt" einer gesondert verwalteten Domain) nun mal keine Portangabe für irgendeinen Name-Server (auch nicht im NS-Record) ... und DNS hat generell wenig mit IP-Ports am Hut, auch wenn es um die Auflösung eines Namens geht - auch die erfolgt immer nur in Form einer Adresse und SRV-Records sind die berühmte Ausnahme von der Regel. Aber auch um SRV-Records abfragen zu können (für andere Dienste), braucht es erst mal überhaupt eine normierte Möglichkeit der Kommunikation (eben über Port 53).

Ich weiß nicht, wo bei Deinem dnsmasq der Port 50053 her kommen mag - ich sehe da eigentlich nur eine Einstellmöglichkeit für den Port (was nur mäßigen Sinn macht, weil das oben Geschriebene auch für die FRITZ!Box und dort verwaltete Domains gilt) und der Standard wäre immer noch 53. Das würde sich zwar mit dem DNS-Resolver/-Server im multid von AVM beißen, aber die Benutzung eines anderen Ports ist hier keine echte Lösung.
 
  • Like
Reaktionen: michael_wl
Das mit dem Port auf 53 war die richtige Lösung. Danach klappt die Namensauflösung wie erwartet.
Unter OSX und Windows musste ich zusätzlich noch die richtige DNS für IPV6 eintragen. Leider wird hier egal was ich versucht habe immer die vom Router (Speedport Hybride) übernommen und nicht die von der FritzBox welche per LAN hinter dem Speedport Hybride hängt. Das ist aber nicht wirklich dramatisch wenn man das einmal erkannt hat.

Denn Watchdog muss ich leider deaktivieren da mit dem neusten FritzBox Version 07.27 alle 3 Minuten ein Neustart der Box erfolgt.
Habe gelesen das man das eigentlich nicht machen soll und daher werde ich das mal weiter beobachten. Bis jetzt läuft die FritzBox aber auch ohne Watchdog 1A.

DNSMASQ auf der FritzBox mit IPV6 funktioniert gar nicht.
Ist auch nicht weiter dramatisch da auch ohne IPV6 alles sehr gut funktioniert.

Danke nochmal an @PeterPawn für die sehr hilfreichen Hinweise.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.