esp32 WiFi DNS - wo ist der Fehler.

[Mike M. (mike303)]

Mein esp board verbindet sich mit dem Hausrouter und ich kann mich via 
IP mit dem esp-Webserver verbinden. Der Router zeigt in seiner Statistik 
den esp mit seinem WiFi.setHostname("alarmrc") an. Und ab hier steh ich 
auf dem Schlauch:

C:\Users\mike>nslookup alarmrc
Server:  DD-WRT
Address:  192.168.1.1
Name:    alarmrc
Address:  192.168.1.120

C:\Users\mike>ping 192.168.1.120
Ping wird ausgeführt für 192.168.1.120 mit 32 Bytes Daten:
Antwort von 192.168.1.120: Bytes=32 Zeit=218ms TTL=64

C:\Users\mike>ping alarmrc
(2 Sekunden stille)
Ping-Anforderung konnte Host "alarmrc" nicht finden. Überprüfen Sie den 
Namen, und versuchen Sie es erneut.

Der Router ist dem Windows als primaryDNS bekannt. Wo liegt der Fehler?

[Mario M. (thelonging)]

Secondary DNS gesetzt, so dass die Anfrage an den falschen Server gehen 
kann? Was sagt nslookup direkt nach dem fehlgeschlagenen Ping?

[Mike M. (mike303)]

Habe die Lösung:
Im Router eine wilde Domain gesetzt und jetz kann ich meinen esp 
anpingen.

ping alarmrc.wildDomain

Nun gut...

[Harald K. (kirnbichler)]

Mike M. schrieb:
> Im Router eine wilde Domain gesetzt und jetz kann ich meinen esp
> anpingen.

Hmm. Üblich ist .local - so machen's beispielsweise Fritzboxen.

[Oliver S. (oliverso)]

Harald K. schrieb:
> Mike M. schrieb:
>> Im Router eine wilde Domain gesetzt und jetz kann ich meinen esp
>> anpingen.
>
> Hmm. Üblich ist .local - so machen's beispielsweise Fritzboxen.

Bei denen ist .fritz.box voreingestellt.

Oliver

[Harald K. (kirnbichler)]

.local funktioniert trotzdem:

ping kiste.fritz.box
ping kiste.local

liefert das gleiche Ergebnis.

[Εrnst B. (ernst)]

Harald K. schrieb:
> ping kiste.fritz.box
> ping kiste.local
>
> liefert das gleiche Ergebnis.

Aber aus unterschiedlichen Gründen.

Das erste Ping fragt den DNS-Server nach der Adresse, das zweite Ping 
löst eine Multicast-DNS-Abfrage im Netzwerk aus, auf die "kiste" 
reagieren kann oder auch nicht.

[Daniel A. (daniel-a)]

Harald K. schrieb:
> .local funktioniert trotzdem:
>
> ping kiste.fritz.box
> ping kiste.local

Die korrekte Domain für Heimnetzwerke, sofern man keine eigene 
Registriert hat und split DNS benutzt, ist home.arpa. (oder eine 
Subdomain darunter), Siehe RFC 8375: 
https://www.rfc-editor.org/rfc/rfc8375.html

Wenn man eine andere Domain, die einem nicht gehört, verwendet, kann man 
unter anderem keinen DNS Resolver nehmen, der DNSSEC überprüft, denn dir 
gehört die ja nicht. Das trifft auch zu, wenn es die Domain noch nicht 
gibt [1].

home.arpa. ist eine Zone, die Explizit unter arpa. existiert, aber 
selbst bewusst nicht signiert ist (also keinen DS record hat, die NS / A 
records für home.arpa. selbst in der arpa. Zone sind schon signiert). In 
anderen Worten, diese Zone erlaubt es explizit, das man sie wie man 
lustig ist manipuliert und selbst verwaltet, dafür ist sie da.

TLDs sind hier auch nicht anders als andere Domains, die sind halt in 
der . Zone hinterlegt. Meines Wissens sind alle TLDs mit DNSSEC 
signiert, aber noch längst nicht jede Domain. Grosse Firmen wie z.B. 
Google bringen es immer noch nicht auf die Reihe, die wollen Regeln & 
Fakten schaffen, nicht sie selbst einhalten...

---

Jetzt noch zu local. Nutzt NIEMALS local. als DNS Zone in eurem unicast 
DNS Server, das ist nochmal eine ganze Nummer Problematischer, als 
selbst eine zu erfinden.

local. ist (wie auch home.arpa.) eine special-use-domain. Alle special 
use domains können bei IANA eingesehen werden: 
https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

local. wird für mdns (Multicast DNS) genutzt (RFC 6762, 
https://www.rfc-editor.org/rfc/rfc6762.html), als default (stichwort 
Zeroconfig).

mDNS ist was anderes als normale unicast DNS. Statt sich mit einem DNS 
Server zu Verbinden, wird im Netzwerk per Multicast nach Domains 
gefragt, jeder fragt jeden und kriegt von jedem im Netzwerk Antworten.

mDNS könnte man auch mit anderen Domänen als local. verwenden, aber das 
macht eigentlich keiner. Ausserdem sind System heute in der regel so 
eingestellt, dass bei local. mDNS abfragen gemacht werden, und bei 
anderen Domänen reguläre DNS abfragen. (enachdem werden auch bei local. 
noch regulare DNS abfragen gemacht, aber nicht bei allen Systemen.
Unter Linux z.B. wird die Namensauflösung (DNS, mDNS, sonstwas), 
meistens per nsswitch konfiguriert, sofern die libc das unterstützt, und 
systemd-resolved implementiert neben DNS auch noch gleich mDNS, wenn man 
das nutzt.

local. über mDNS ist in Ordnung, aber macht keine Zone local. in 
regulärem DNS.

---

Noch eine Randnotiz zu DNS-SD (Service discovery). Per default wird das 
per mDNS mit .local gemacht, aber auch über normale unicast DNS mit 
anderer Domain ist es möglich. Wenn man vollständiges DNSSEC usw. für 
sein DNS-SD will, führt da kein Weg dran vorbei.
Das geht aber nur bei iOS und Mac OS out of the box. Unter Android 
scheint nur mDNS mit .local beachtet zu werden. Unter linux mit 
Avahi-Daemon werden search Domains neben local. zwar aufgelistet, aber 
per default nur local. durchsucht. Da müsste man andere Domänen also 
explizit angeben, was das Zeroconfig Konzept aber ad absurdum führt...
Ein DNS-SD Service muss aber als "Hostname" (die eigentliche Adresse des 
Services, eigentlich eine FQDN und kein Hostname, angegeben per SRV 
record) des Services nicht zwangsläufig seine eigene Domäne, oder gar 
einer unter der Suchdomäne, angeben. So kann man einen Serivce 
Drucker\032Buero._ipps._tcp.local haben, der auf irgendwo.com zeigt, und 
damit zumindest den Teil per DNSSEC absichern. Bisher habe ich Android 
davon aber auch davon noch nicht begeistern können, iOS und Linux Avahi 
hingegen störte es nicht. (wobei, DNS-SD unter Android ist sowieso 
unzuverlässig, vielleicht lag das auch an was anderem, keine Ahnung...).

1) https://dnsinstitute.com/documentation/dnssec-guide/ch06s02.html