Geschichtliches: Warum musste mDNS, Bonjour, Zeroconf ausgerechnet ".local" nehmen?

Hallo,

Danke für die Links. Den ersten kannte ich natürlich schon, da steht aber nichts zum Warum, den zweiten kann ich nicht lesen (kein Abo) und im dritten steht auch nichts zu meiner Frage.
Danke für den Link zur Rubrik, ich habe da mal gefragt.

Danke für Deine ausführliche Antwort.


ja, ich weiß


Das wäre selbst für Microsoft ein bisschen zu fett lol nee nicht wirklich, oder?


ja schon klar, wobei das im Allgemeinen vermutlich keine gute Idee ist, wenn man nicht alle Geräte kontrollieren kann (und wer weiß, was das tolle Multifunktionsgeräte dann wieder falsch macht).


Na ja, leider gibt es durchaus Netze, wo das schon ne Rolle spielt - und sich teils schlecht ersetzen lässt. Ich kenne (in anderen Netzwerken) etliche Anwendungen (die man auch ohne partout nicht zum Laufen kriegt), ich fürchte, es wächste eine neue Generation von Entwicklern heran, die die alten Automagics Fehler erstmal selbst wiederholen müssen...


oh jaaaaaaaaa... das wäre in der Tat eine Erklärung... Hast Du für den Teil "Zicke" einen Beleg, ein Blog von einem Insider oder so?

Hallo,

danke für Deine ausführliche Antwort!

Ich habe weiter unten ab "Meine Erfahrungen mit dem Problem" dieselben beschrieben. Das passt hier eigentlich nicht rein, weil es hier um Geschichte geht, vielleicht kann man das woandershin kopieren.

Das Fehlerbild kann m.E. nach wirklich übel sein, daher stehen ab "Meine Erfahrungen mit dem Problem" ein paar Fallen, in die ich getreten bin. Vielleicht hilft es ja jemandem.


ja, ich merk schon ;)
Dafür kann ich ein bisschen was beitragen, immerhin


Warum das?

Ich wollte nur mal wissen, warum man ausgerechnet .local nehmen musste, was halt damals viele als Suffix für RFC-1597 / RFC-1918 Ips ("Address Allocation for Private Internets") genommen haben - denn RFC-8375 gab es damals noch nicht (und es ist auch noch blöd, ausgerechnet "home.arpa.").

Es hat sich auch kein TLD Betreiber herabgelassen, mal ein registry zu machen, meintwegen "lan.net" oder "local.net" (gehören beiden Heuschrecken! Könnte man gleich der Welt geben, würde nichts schlechter machen, ausser das ne Heuschrecke einen "erhofften" Gewinn verpasst, aber neeeeeein, das geht auf gar keinen Fall).

Ganz früher hat DENIC versprochen, sie werden nie nie TLDs akzeptieren, und die Leute haben dankbar "org.de" benutzt, oder einfach "my.de", aber schon 2009 konnte man der Kohle nicht wiederstehen (es geht da wohl bloß um ein paar tausend Euro, mehr waren die privaten dem DENIC also nicht wert, tja) und dann verkauften die eben unter anderem "org.de"... und na klar! An eine Heuschrecke! Kein Mensch nutzt diese Domains, aber privat darf man sie auch nicht nutzen (wenn man morgen nicht wieder neue Probleme kriegen will). Ich hoffe für das DENIC, es wars wert, die ganzen RFC-1918 Nutzer für ein paar scalper hängen zu lassen und ein paar tausend Euro einzunehmen

Aber gut (nicht ganz ernst gemeint folgender Zynismus zur allgemeinen Unterhaltung):

1) Konkrete Probleme:
"etwas.local" wurde als DNS-Domain (und Active Directory Domain) in einem Netzwerk genutzt wurde, dieses Netz über VPN mit einem anderen verbunden wurde, was mDNS "kann" (rein praktisch standen da wohl zwei Apple-TV und ein paar Drucker rum, die das brauchen, wobei das bei den Druckern wohl gar nicht stimmt, die lösen über DNS auf, aber vielleicht auch beides), ich hab die DNS gegenseitig delegiert, aber aus dem mDNS aktiven Netz wird irgend.etwas.local nicht aufgelöst.

2) detaillierte technische Analyse der Ursache
Es ist gar kein technischer Grund, sondern die blöde Idee eines Sonntagprogrammierers, für einen unsichtbare technische Bezeichner keinen technischen Bezeichner zu wählen, sondern ".local", auf einem Malprogramm-Lader (MacOS 9), was gerade "Mehrbenutzerunterstützung" als neues Feature feierte (und bald darauf von Steve Jobs durch sein OPENSTEP ersetzt wurde),
und der Ignoranz der IANAs und NICs dieser Welt, zwar in einem RFC (später RFC-1918) privat benutzbare IP Adressen zu spezifizieren, aber es irgendwie tatsächlich schaffen, das nicht auch für Namen zu machen, und zwar über Jahre hinweg trotz aller Hinweise,
und Microsoft, hier vermutlich die Idee eines hochdekorierten Mega-Managers, die auch ausgerechnet ".local" nehmen müssen, obwohl (ich meine mich zu erinnern) sie den link local block (169.254.0.0/16) gekauft haben, haben sie nicht dran gedacht, auch gleich einen Namensblock zu kaufen, vielleicht local.net oder so (aber das wäre bestimmt ein mslocal.win.com geworden und eh keiner benutzt).

3) Randbedingungen
Ganz wichtig: in den ganzen Gremien bloß nicht mitander reden oder gar mit den Usern! Man geht in die Gremien, um die Politik der Firma zu vertreten und nicht etwa, um eine gute technische Lösung zu erreichen. Im Gegenteil! Das könnte ja dann jeder und das bringt nur Konkurenz. Weiterhin ist es sehr hilfreich, nicht auf Fachleute, Informatiker oder Nerds zu hören, denn die bringen es nie zur World Domination.


Konnte er es nicht auflösen, oder über DNS nicht auflösen? Sprich: konnte er über blah/etc/hosts Einträge machen und nutzen? Konnte er über mDNS registrierte .local auflösen? Wenn beides JA, dann hat er vermutlich versucht, local über DNS aufzulösen, aber einen mDNS provider und keinen mDNS Clienten. Der mDNS Server verhält sich dann korrekt zu dem RFC.


Du meinst, es gibt heute noch .local ADs? Ich dachte, ich hätte jetzt das fast einzige noch bestehende uralte .local Netz erwischt... Die armen Admins, ich fürchte, das Problem wird in Zukunft stärker.


Ja, das mag sein. Die werden das sicherlich nicht Bonjour sondern ZeroConf nennen, aber ja, inzwischen (?) reden etliche Entwickler davon, wie toll das sei (spart bisschen Arbeit und troubleshooting machen ja dann die User) und die Admins sind eh zu teuer... "Wäre es nicht toll, wenn Dein AD von der Sekretärin konfiguriert wird"? (das war überhaupt schon immer MS Strategie "die Sekretärin kann den Drucker einrichten" und inzwischen tut sie das, oder ein Admin, dem man dann kaum mehr bezahlen möchte ).

Meine Erfahrungen mit dem Problem

Dann noch ein bisschen Halbwissen aus der Dev-Szene: Windows 10 hatte früher schon mDNS Unterstützung, da mussten die Programme aber irgendwas spezielles für tun, also angepasst werden. Hat aber halt keiner gemacht. Damit ging mit alten Programmen kein example.local über mDNS (bzw nicht ohne weitere Tricks). Das ist inzwischen anders, es geht automatisch, ohne das das Programm angepasst wird. Damit ist wohl zu erwarten, dass neuere Programme (also die mit neueren Windowsversionen bzw SDKs gebaut wurden) das automatisch können - bzw im .local Netz kaputt machen. Das schöne ist, dass man das dem Programm nicht ansieht. Weiß ich alles nur aus zweiter oder dritter Hand, aber wurde mir so versichert, ein Bekannter arbeitet da an einer Software und sagte, dass die alten Versionen kein mDNS machen, die neuen schon, weil sie gegen neueres SDK bauen. Die packen aber die DLLs auch mit ein. Im Normalfall würden aber die DLLs vom System genommen. Da könnte es sein, dass ein altes Programm auf eine neueren Windows 10 Version dann doch plötzlich mDNS kann - und zwar später, als Windows mDNS an sich per default eingeführt hat (das war ja schon vor ner Weile). Ja, und das sieht man dem Programm dann nicht an... Ganz toll alles; arme Admins, die das ausbügeln müssen...

Ja, und dann muss man noch einen üblen Trick kennen: es ist nicht unüblich, dass die mDNS clients gucken, ob sie in der .local Domain sind oder auch: ob es eine .local gibt, und falls ja, sicherheitshalber kein mDNS machen. Dann merkt man sein Problem erstmal nicht, aber das ist fragil und kann morgen schon anders sein. Beispielsweise können die auf DHCP gucken, und wenn das mal bisschen spät dran ist, ist mDNS an, man merkt erstmal keinen Unterschied, hat nichts geändert, nur plötzlich geht local nicht mehr. Linux avahi macht [über ein Wrapperscript (mindestens unter Debian)] ein SOA RR request gegen den DNS aus dem DHCP (und nicht etwa auf den eigenen Namen!). Das hatte bei mir nicht wie gedacht funktioniert, weil mein DNS für die split/redirect ".local" zone (ins andere Netz) kein SOA proxy gemacht hat. Damit ging der SOA request also schief und avahi dachte, dass es .local nicht gibt und nahm sich .local. Gleiches Gerät an anderer Dose: Gegen den DNS von Windows AD kommt SOA aber natürlich mit Erfolg zurück, damit verhält sich der Linux Laptop dann komplett anders.
Tja und wenn man jetzt beide DNS Server im Netz hat (und vielleicht noch balancing hat oder so), dann hat man ein geht/geht nicht Muster, ohne was zu ändern und sucht sich tot! Unter Linux geht das ja noch (mit strace sieht man, dass er mDNS macht und kann es abschalten), aber wenn da jetzt einer mit nem Tablett ankommt, kann man da wohl nicht mehr viel troubleshooten (und deswegen finde ich solche Protokolle auch doof). Unter Windows wüsste ich auch nicht, wie man das rauskriegt (nur tcpdump / wireshark als ersten Anhaltspunkt).

Ich fürchte, dass wird durch die Mobilgeräte (ich glaube, auch Android) gepusht werden (oder wird es schon) und dann immer mehr stören. Dann kann der Chef über seine Super-Planer-App nicht drucken oder der Secure OfficeShare geht nicht ("aber bei mir Zuhause geht es doch auch?! Da hat der Kumpel von meinem Sohn mit ner Fritzbox...."), hab ich alles schon gehört.


Ja ok, das ist wahr, vielleicht kann ich jemandem helfen, aber ich fürchte, es bleibt nicht viel übrig, ausser .local umzubenennen. Und juhu (trommelwirbel) -- es gibt immer noch nichts, was garantiert funktioniert (bis auf home.arpa., viel Spaß beim Boss). Das ärgert mich so ungemein und es ist so unnütz, hätten die einfach nicht .local sondern "mdns.arpa" genommen oder sonstwas. Egal, zum Thema:

Zur Analyse habe ich einen Linux Laptop genommen. Da war avahi aber auch an, ist seit einer Weile Standard. Das ist ja wieder so ein Pöttering-Projekt mit komischen defaults und keinem Admin-freundlichem Logging, da muss man dann echt strace nutzen, um zu sehen, was passiert. Tja und da sieht man natürlich keine Netzwerknachricht, weil ja alles lokal über möglichst viele indirekte Ebenen gecacht wird Also abgeschaltet. Dann mit Tools wie "nslookup" (ich nehm meist lieber "host" oder "dig", und dig kann auch mDNS [dig -p 5353 @224.0.0.251 example.local]) feststellen, dass der AD Server das alles auflöst. Tja, aber mDNS machen ja die Clienten, also nützt einem das nichts. Eigentlich ne tolle Idee: machen zwei mDNS im LAN, finden die sich, egal was der DNS und sonstwer macht. Geht vor allem auch über link local (oder ähnliches). Aber leider auch, wenn es DNS und alles gibt, in einem gemanagten Netz, denn mDNS machen ja die Clienten unter sich aus.

Erkennt man dann, dass bei diesen Namen gar kein DNS query übers Netz geht: also im tcpdump / wireshark macht die Station nichts gegen einen Port 53 - "tcpdump -v" zeigt sogar die gefragten Namen an, da muss man nur filtern und sieht es quasi in Echtzeit über die Console rauschen, vielleicht ein "tcpdump -n -v -i any host 192.168.1.2 and port 53" (ungetestet) aufrufen. Dann mal ein DNS resolve (ping asdfasdfasdfasd.com - die existiert übrigens) im trace sehen und dann ein .local testen. Unter Android kann man sich übrigens eine Shell installieren, z.B. Termux, da kann man sich dann von ping über traceroute bis sonstwas installieren - cmd.exe style oder powershell finde ich für Android auf die Schnelle leider nicht, aber wäre doch mal ne Suche wert). Das war bei mir interessant, weil ich über WLAN einen anderen DNS Server hatte (siehe oben zum Thema "local domain testen").

Mit Kommandozeilentool mdns kann man dann Namen registrieren und abfragen (da sieht man auch, wie fragil das alles ist). avahi hat ein browser (avahi-browse). Kann man vielleicht in einem bridged container (oder kleiner VM) laufen lassen. Bei IBM gibts ein dns-sd tool für Windows, weil die Download-Links nicht ganz sauber aussahen, lieber selbst googlen und prüfen, ob/wann man das nutzen darf.

Ja, last but not least: umbenennen muss man, wenn man die Clients nicht konfigurieren kann, weil dann ein böser Client servername.local. (oder wie auch immer) registrieren kann und sich so z.B. die ganzen AD SRV records zu sich umbiegen kann. Das stört natürlich nur auf mDNS Clienten, also heute noch nicht so, aber morgen dann auf den Tabletts etc. Dann redirected sich ein hacker einen Lokalen Netzwerk Dienst und captured sich die Passwörter raus, oder sowas, echt blöd, da geht bestimmt irgendwas).

ich hoffe, es hilft mal jemandem und die ganze Tipperei war nicht umsonst
na dann gute Nacht!

Weil jetzt wieder so viel off topic kam, dass niemand mehr versuchen wird, meine Frage zu beantworten? Oder warum sollte ich den als erledigt schließen?

Du meinst:
ja? OK, Apple schreibt ein IchWünschMirWas, aber wie wurde es IETF Standard? Und warum hat Microsoft nichts gemacht? Die sehen sich als "technical leader in IETF standards activities for decades" und wollen das übersehen haben, obwohl das seit mindestens 15, eher 20 Jahren ein Thema in den Mailinglisten (ja, also wohl eher 20 Jahre ) war?

Auch in:
https://datatracker.ietf.org/doc/rfc6762/ballot/
https://datatracker.ietf.org/doc/rfc6762/history/
finde ich keine Kritik an .local. Die haben link-local IP Registrierung bei IANA geprüft, also z.B. 254.169.in-addr.arpa., was niemanden stört, weil das vorher ein öffentliches Netz war, aber bei dem Namen, der von MS empfohlen wird, da kümmert sich niemand? Das ist doch schon bemerkenswert, finde ich.

Vielleicht hat Microsoft gedacht, ach, lass Apple mal machen, die sind so klein (das ging um das Jahr 2000 los), von denen merkt man in der Praxis eh nichts und dann kam ein paar Jahre später das iPhone? Das wäre auch plausibel.


hihi
ja und eigentlich hat er ja auch Recht, es wird vermutlich kein weiterer Erkenntnisgewinn möglich sein.
Aber es war schön, mit euch zu reden, hat mir Spaß gemacht

Danke an alle!

Wozu man aber ja auch erstmal eine Domain braucht, was ja hier schon ein Thema ist (wenn man viele Jahre Ruhe haben möchte)...

Ja, Lets Encrypt gibt jedem und allem mit einem Webserver ein X.509 Zertifikat. Ein X.509 Zertifikat verbindet eine technische ID (ein Public Key) mit einer menschenverständlichen ID (man braucht mindestens Namen und Land), damit man beim Surfen nicht prüfen muss, ob "B7:15:9D:C6:68:42:54:CF:B4:9D:2C:79:66:F6:53:A8:06:ED:12:CC:03:34:E8:EE:0B:E1:BE:EF:CA:86..." wirklich die Deutsche Bank ist, sondern das für Menschen einfacher zu merkende "Organisation = Deutsche Bank AG" prüfen kann (und immer das Land mit prüfen, es kann ja in Südafrika auch einen Deutsche Bank geben, die nichts mit der deutschen zu tun hat - sowas gab es schon mehrfach!).

Und was fehlt bei Lets Encrypt? Trommelwirbel... Die menschenverständliche ID! TADAAA!

Die zertifizieren gar nicht, ob ein Key jemand bestimmten gehört (was die Aufgabe einer CA ist), sondern das ein Key mal zu einem Hostnamen gehört hat - und "authorisieren" das, in den sie prüfen, ob der Antragsteller Zugriff auf die Domain hatte. Damit kriegt er ein Zertifikat, was formal sauber die Existenz eines Hostnames garantiert und mehr nicht. Wenn jemand "im DNS" oder "im IP Pfad" "sitzt" (das ist ja genau das, wovor Zertifikate schützen sollen), dann kann er für seinen Key ein Zertifikat beantragen und bekommt es. Ganz toll.

Immerhin sind sie so ehrlich, es "Let's Encrypt" und nicht "Let's Secure" zu nennen.

Da kann man mit dem Angreifer, der sich das Zertifikat geholt hat, verschlüsselt kommunizieren und niemand anders (auch nicht der echte Empfänger), kann es lesen. Tja, Hauptsache verschlüsselt...

Gibt es denn irgendwo sowas wie "Lebenszeitlang garantierte Domains" oder so? Da könnte Deutschland mal digitalisieren und z.B. eine paar Subdomains unter .de dafür reservieren. Also, das hätte man in den 90ern machen sollen, aber da mussten wir die damals neuen Emailadressen noch per Fax verteilen. Wobei... eigentlich wie heute lol

Wenn ich das gemacht hätte, dann könnte (müsste?) man seit 20 Jahren einen DNS Namen eintragen, der dann vom Amts wegen unter hra.de (war damals vielleicht noch frei) bzw hrb.de erscheint.

Ich hatte früher gratis dyndns.org (war mal gratis, und heute zahle ich da ausgerechnet an Oracle :/), aber gratis gabs auch nur Hostnamen, keine Domains. Wenn man eine Domain kauft, muss eine firstlevel nehmen (weil es keine amtlichen second level dafür gibt), hängt man immer mit einem ISP (Strato oder so) drin, gibts maximal für 10 Jahre (ICANN Regel glaube ich).

Aber dazu mache ich lieber eine eigene Frage auf.