12
Hinweise zur Verwendung der Domäne .local in DNS und mDNS
Aus gegebenem Anlass habe ich kurz die wesentlichen Punkte zur Verwendung der .local Domäne (bzw. korrekterweise der Top-Level-Domain local.) zusammengefasst.
Die Domäne .local. ist für die Verwendung mit mDNS reserviert und darf nicht für andere Zwecke - insbesondere nicht als Domäne für normales DNS - verwendet werden. Dies wird in folgendem RFC vom Februar 2013 beschrieben: https://datatracker.ietf.org/doc/html/rfc6762
Das Dokument rfc6762 gilt als PROPOSED STANDARD ( https://datatracker.ietf.org/doc/html/rfc7127 ). Dies stellt zwar den niedrigsten IETF Level für Standards dar, bedeutet aber auch, dass das beschriebene Verfahren stabiles standartisiertes Protokoll angesehen wird. Abweichungen von einem PROPOSED STANDARD machen wenig Sinn. Man will ja das Internet nicht neu erfinden.
Microsoft hat lange Zeit .local in der Windows-Dokumentation als Beispieldomäne angegeben. Auch die einschlägige Fachliteratur hat dies häufig übernommen. Dies darf heute so nicht mehr implementiert werden. Stattdessen könnte man z.B: auf .lokal. zurückgreifen. Besser wäre es natürlich, eine Subdomäne einer eigenen registrierten Domäne zu verwenden, z.B. local.meinedomäne.de
Was ist das Problem? Gemäß der mDNS-Spezifikation in rfc6762 müssen DNS-queries der Domain .local. an die link-local Multicast Adresse 224.0.0.251 gesendet werden.
Dies kann zu unerwartetem Verhalten bei der DNS-Auflösung, oder der Funktion von mDNS führen.
Grüße
lcer
Die Domäne .local. ist für die Verwendung mit mDNS reserviert und darf nicht für andere Zwecke - insbesondere nicht als Domäne für normales DNS - verwendet werden. Dies wird in folgendem RFC vom Februar 2013 beschrieben: https://datatracker.ietf.org/doc/html/rfc6762
Das Dokument rfc6762 gilt als PROPOSED STANDARD ( https://datatracker.ietf.org/doc/html/rfc7127 ). Dies stellt zwar den niedrigsten IETF Level für Standards dar, bedeutet aber auch, dass das beschriebene Verfahren stabiles standartisiertes Protokoll angesehen wird. Abweichungen von einem PROPOSED STANDARD machen wenig Sinn. Man will ja das Internet nicht neu erfinden.
Microsoft hat lange Zeit .local in der Windows-Dokumentation als Beispieldomäne angegeben. Auch die einschlägige Fachliteratur hat dies häufig übernommen. Dies darf heute so nicht mehr implementiert werden. Stattdessen könnte man z.B: auf .lokal. zurückgreifen. Besser wäre es natürlich, eine Subdomäne einer eigenen registrierten Domäne zu verwenden, z.B. local.meinedomäne.de
Was ist das Problem? Gemäß der mDNS-Spezifikation in rfc6762 müssen DNS-queries der Domain .local. an die link-local Multicast Adresse 224.0.0.251 gesendet werden.
Any DNS query for a name ending with ".local." MUST be sent to the
mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6
equivalent FF02::FB). Dies kann zu unerwartetem Verhalten bei der DNS-Auflösung, oder der Funktion von mDNS führen.
Grüße
lcer
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 909777511
Url: https://administrator.de/contentid/909777511
Printed on: April 24, 2024 at 17:04 o'clock
12 Comments
Latest comment
Bei Univention wird alternativ ".intranet" vorgeschlagen.
VG
VG
Dies darf heute so nicht mehr implementiert werden.
Richtig ! Siehe dazu auch:https://www.heise.de/select/ct/2017/26/1513540412603853
https://www.heise.de/news/Ueberfaellig-ICANN-legt-sich-auf-Namen-fuer-in ....
Ein Standard von IETF und IANA ist die HNCP Definition mit der offiziellen .home.arpa Domain zumindestens für SoHo Netze:
https://datatracker.ietf.org/doc/html/draft-ietf-homenet-dot?from=litvz
Was passiert, wenn es doch noch eine .local Domain gibt?
Dann öffnet sich die Hölle!
2
vermutlich nichts, solange kein mDNS-Client installiert ist. Ist auf dem Rechner jedoch ein mDNS-Client (am häufigsten Bonjour) installiert, sendet der, wie vorgesehen, den DNS-Query per mDNS an die Multicastadresse. Kann man per Wireshark (Anzeigefilter "dns or mdns") gut nachvollziehen:
Bei mir (Windows10, keine .local Domäne):
No. Time Source Destination Protocol Length Info
6529 48.154394 192.168.0.152 192.168.200.18 DNS 69 Standard query 0x45dc A me1.local
6531 48.211354 192.168.200.18 192.168.0.152 DNS 144 Standard query response 0x45dc No such name A me1.local SOA a.root-servers.net
6533 48.213544 192.168.0.152 224.0.0.251 MDNS 69 Standard query 0x0000 A me1.local, "QM" question
6534 48.214559 192.168.0.152 224.0.0.251 MDNS 69 Standard query 0x0000 AAAA me1.local, "QM" question Wenn man Glück hat, ist das nur unnützer Overhead. Wenn man Pech hat, kann man da sehr schön die Namensauflösung manipulieren.
Grüße
lcer
1
Ja, mindesten! 
Solange man auf dem internen DNS-Servern keine Zone für "local." hostet und auch keine bedingte Weiterleitung dafür, passiert rein gar nichts.
Edit:
Solange man auf dem internen DNS-Servern keine Zone für "local." hostet und auch keine bedingte Weiterleitung dafür, passiert rein gar nichts.
Edit:
... keine Zone für "local."
Und damit meine ich wirklich nur die Zone für diese TLD. Eine Zone für z.B. "mydomain.local." ist vollkommen unproblematisch.1
Für nicht öffentliche interne Domainnamen hat sich die IANA nun offenbar auf .internal festgelegt.
Überfällig: ICANN legt sich auf Namen für interne Domains fest
Die ICANN muss das aber noch endgültig abnicken.
Überfällig: ICANN legt sich auf Namen für interne Domains fest
Die ICANN muss das aber noch endgültig abnicken.
1
Richtig. Und jetzt alle Admins dieser Welt - um Gottes Willen - sofort alle Active Direcktory, welche ".local" nutzen, mal so richtig, aber auch wirklich so richtig, sauber machen und alles neu aufsetzen. Asap! Gott stehe uns bei ...
*Ironie Ende*
*Ironie Ende*
Und dann kommt Apple und schnappt sich .internal für sein iDNS.
Hab ich ein Glück, dass ich die schon länger einsetze
