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

drahtbruecke
Goto Top
Hi,

Gleich vorweg: Das ist keine technische Frage, sondern eine zur Geschichte.

es ist schon eine Weile her, dass ich Probleme mit DNS Zonen hatte, die ".local" verwendeten und Konflikte mit Zeroconf verursachten, doch jetzt hab ich wieder mal so ein Netz bekommen und gerade über eine Stunde Troubleshooting auf Karfreitag verbrannt.

Weiß jemand, warum die ausgerechnet ".local" und nicht irgendwas designiertes genommen haben, was nicht durch falsch-intuitive Anwendung zu Problemen führt?

Meintwegen ".local.bonjour.apple.com" oder ".rfc6762.arpa.", aber ausgerechnet ".local", was die Leute in ihre Fritzboxen eintragen und dann über "Windows Server kann auch der Junior von der Sekretärin einrichten" in kleine Firmen kommt und ewig funktioniert, bis an ganz anderer Stellen ganz andere Probleme auftreten und dann noch diskutiert wird "aber vorher ging es doch auch".

Ich hab gegooglet, wo das eigentlich herkommt, aber leider nicht herausgefunden. In der Geschichte dieser mDNS Protokolle tauchen ja viele Namen auf, die schon öfter mit Pech beim Denken auffielen: Microsoft, Apple, Pöttering...

Weiß jemand, wem das passiert ist oder hat sogar ein Link zur Entstehungsgeschichte, was das beantwortet?

Frohe Ostern!

ps: warum darf man kein Slash/Schrägstrich im Titel verwenden?

Content-Key: 2508538860

Url: https://administrator.de/contentid/2508538860

Ausgedruckt am: 14.08.2022 um 10:08 Uhr

Mitglied: 148523
148523 15.04.2022 aktualisiert um 15:48:19 Uhr
Goto Top
RFC lesen hilft:
https://datatracker.ietf.org/doc/rfc6762/
Und auch:
https://www.heise.de/select/ct/2017/26/1513540412603853
https://administrator.de/contentid/909777511
warum darf man kein Slash/Schrägstrich im Titel verwenden?
Frag den Forenbesitzer @Frank in der Rubrik https://administrator.de/latest/?tag=feedback
Mitglied: altmetaller
Lösung altmetaller 15.04.2022 um 17:08:59 Uhr
Goto Top
Hallo,

Microsoft hat .contoso.local lange Zeit als Beispiel in Büchern, Anleitungen usw. genutzt und diese TLD auch aktiv empfohlen was dazu führte, dass viele ihre Domain mit .local terminiert haben.

Zudem hat der damals extrem populäre SBS2011 ebenfalls .local genutzt. Das war letztendlich ein Server-Potpourris (AD, Sharepoint, Exchange usw.) für bis zu 75 User, bei dem ein Umzug durch die Verflechtung der Dienste auf eine andere Domain nicht ganz untrivial war.

Afaik wird .local auch heute noch als Standard bei der Gründung eines neuen AD vorgeschlagen.

Irgendwann war Apple mal wieder auf dem Zickentrip, wollte Windows-Admins schikanieren und hat einen Standard vorangetrieben, der derartig konfigurierte Netze stört. Kurzum: RFC 6762 existiert zwar, wurde aber letztendlich durch zwei Apple-Mitarbeiter indoktriniert und hat nie die vollständigen Diskussionsprozesse durchlaufen.

Wenn Du keine proprietären Systeme (Apple) nutzt, kannst Du den Quatsch mit gutem Gewissen deaktivieren. Das wird von Microsoft im gewerblichen (sicherheitsaffinen) Umfeld sogar empfohlen, siehe mDNS in the Enterprise

Gruß,
Jörg

Übrigens: „Hauptanwendung“ dafür war übrigens das Bonjour-Protokoll von Apple, dass heute aber keine signifikante Rolle mehr spielt. Außer, Du möchtest deine Schnippi-Schnappi-Klingeltöne mit anderen Usern im Netz teilen, vielleicht… face-smile
Mitglied: 148523
148523 15.04.2022, aktualisiert am 16.04.2022 um 12:41:13 Uhr
Goto Top
heute noch als Standard bei der Gründung eines neuen AD vorgeschlagen.
Nicht mehr aktuell:
https://social.technet.microsoft.com/wiki/contents/articles/34981.active ...
Auch hier hilt ein RFC:
https://datatracker.ietf.org/doc/html/draft-ietf-homenet-dot?from=litvz
und
https://datatracker.ietf.org/doc/html/rfc2606
kannst Du den Quatsch mit gutem Gewissen deaktivieren.
Ist leider ziemlicher Unsinn. mDNS ist heute umfassend in fast allen Produkten enthalten die sich DAU freundlich im Netz bekannt machen wie allerlei Medienplayer, NAS, IoT usw. also faktisch alles. Das es einmal nur Apple war ist längst Geschichte !
Gleiche Story im übrigen wie Microsoft mit SSDP.
Mitglied: altmetaller
altmetaller 15.04.2022 um 20:35:26 Uhr
Goto Top
Hallo,

Zitat von @148523:

Nicht mehr aktuell:

Bei einem "Server 2016 Essentials" war das noch so. Neuere Systeme kenne ich tatsächlich nicht.

Gruß,
Jörg
Mitglied: sk
sk 17.04.2022 um 16:58:45 Uhr
Goto Top
Hallo drahtbruecke,

ich bzweifle, dass zu Deiner Frage nach dem "Warum" etwas Substanzielles kommen wird.

Konstruktiver als diese Frage wäre ohnehin, wenn Du mal darstellen würdest, was denn nun die konkreten Probleme waren, mit denen Du Dich beschäftigen musstest. Und zwar möglichst nicht nur beschreiben, was nicht funktionierte, sondern auch die detaillierte technische Analyse der Ursache und der Randbedingungen.

Bislang ist das Forum nach meiner Wahrnehmung noch völlig frei von reproduzierbaren Problemdefinitionen und diesbezüglichen technischen Analysen. Kürzlich berichtete Mitglied dfritz davon, dass ein Lenovo Notebook mit vom Hersteller vorinstalliertem Win10 21H2 keine auf .local endenden DNS-Namen auflösen könnte (siehe https://administrator.de/forum/ping-local-hosts-nicht-moeglich-204113705 ..). In Anbetracht desssen, dass täglich weltweit sicherlich hunderttausendfach aktuelle Windows10-Versionen in bestehnde .local-ADs hineindeployt werden und das Internet dennoch nicht von entsprechenden Fehlerberichten überquillt, kann ich mir nicht vorstellen, dass MS klammheimlich eine tiefgreifende Veränderung im Namensauflösungsverhalten aktueller Windows-Versionen implementiert hat. Vermutlich war das Lenovo-Image mit irgendeiner Bloatware verseucht, die Bonjour-Komponenten mitbringt...

Wie dem auch sei. Da Du nach eigener Aussage schon mehrfach Probleme aufgrund .local-Domains fixen musstest, wäre es sehr wünschenswert, wenn Du hier davon berichten würdest!

Gruß
sk
Mitglied: altmetaller
altmetaller 17.04.2022 um 17:15:46 Uhr
Goto Top
Hallo,

das reicht u.U. schon, wenn Du iTunes installierst und nicht aufpasst.

Gruß,
Jörg
Mitglied: 148523
148523 18.04.2022 um 09:35:50 Uhr
Goto Top
Zeit das der TO seinen Thread nun auch endlich einmal als erledigt schliesst !
https://administrator.de/faq/32
Mitglied: drahtbruecke
drahtbruecke 19.04.2022 um 23:18:22 Uhr
Goto Top
Zitat von @148523:

RFC lesen hilft:
https://datatracker.ietf.org/doc/rfc6762/
Und auch:
https://www.heise.de/select/ct/2017/26/1513540412603853
https://administrator.de/contentid/909777511
warum darf man kein Slash/Schrägstrich im Titel verwenden?
Frag den Forenbesitzer @Frank in der Rubrik https://administrator.de/latest/?tag=feedback

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.
Mitglied: drahtbruecke
drahtbruecke 19.04.2022 um 23:24:21 Uhr
Goto Top
Danke für Deine ausführliche Antwort.

Zitat von @altmetaller:
Microsoft hat .contoso.local lange Zeit als Beispiel in Büchern, Anleitungen usw. genutzt

ja, ich weiß face-smile

Afaik wird .local auch heute noch als Standard bei der Gründung eines neuen AD vorgeschlagen.

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

Wenn Du keine proprietären Systeme (Apple) nutzt, kannst Du den Quatsch mit gutem Gewissen deaktivieren.

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).

Übrigens: „Hauptanwendung“ dafür war übrigens das Bonjour-Protokoll von Apple, dass heute aber keine signifikante Rolle mehr spielt. Außer, Du möchtest deine Schnippi-Schnappi-Klingeltöne mit anderen Usern im Netz teilen, vielleicht… face-smile

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...

Irgendwann war Apple mal wieder auf dem Zickentrip, wollte Windows-Admins schikanieren

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?
Mitglied: drahtbruecke
drahtbruecke 20.04.2022 aktualisiert um 01:32:35 Uhr
Goto Top
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.

Zitat von @sk:
ich bzweifle, dass zu Deiner Frage nach dem "Warum" etwas Substanzielles kommen wird.

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

Konstruktiver als diese Frage wäre ohnehin, wenn Du mal darstellen würdest, was denn nun die konkreten Probleme waren, mit denen Du Dich beschäftigen musstest. Und zwar möglichst nicht nur beschreiben, was nicht funktionierte, sondern auch die detaillierte technische Analyse der Ursache und der Randbedingungen.

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 ace-sad"

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.

Bislang ist das Forum nach meiner Wahrnehmung noch völlig frei von reproduzierbaren Problemdefinitionen und diesbezüglichen technischen Analysen. Kürzlich berichtete Mitglied dfritz davon, dass ein Lenovo Notebook mit vom Hersteller vorinstalliertem Win10 21H2 keine auf .local endenden DNS-Namen auflösen könnte (siehe https://administrator.de/forum/ping-local-hosts-nicht-moeglich-204113705 ..).

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.

In Anbetracht desssen, dass täglich weltweit sicherlich hunderttausendfach aktuelle Windows10-Versionen in bestehnde .local-ADs hineindeployt

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.

werden und das Internet dennoch nicht von entsprechenden Fehlerberichten überquillt, kann ich mir nicht vorstellen, dass MS klammheimlich eine tiefgreifende Veränderung im Namensauflösungsverhalten aktueller Windows-Versionen implementiert hat. Vermutlich war das Lenovo-Image mit irgendeiner Bloatware verseucht, die Bonjour-Komponenten mitbringt...

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 face-smile).

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.

Wie dem auch sei. Da Du nach eigener Aussage schon mehrfach Probleme aufgrund .local-Domains fixen musstest, wäre es sehr wünschenswert, wenn Du hier davon berichten würdest!

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 face-smile 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 face-smile
na dann gute Nacht!
Mitglied: drahtbruecke
drahtbruecke 20.04.2022 um 01:25:07 Uhr
Goto Top
Zitat von @148523:

Zeit das der TO seinen Thread nun auch endlich einmal als erledigt schliesst !
https://administrator.de/faq/32

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?
Mitglied: altmetaller
altmetaller 20.04.2022 um 09:56:07 Uhr
Goto Top
Hallo,

Zitat von @drahtbruecke:

Weil jetzt wieder so viel off topic kam, dass niemand mehr versuchen wird, meine Frage zu beantworten?

a) Ich habe deine Frage beantwortet

b) Guck' mal in sein Profil - offenbar ist er in heiliger Mission unterwegs, hier immer wieder zum Schließen von Threads aufzurufen. Vielleicht macht ihn das ja irgendwie „scharf“?!? face-smile

Gruß,
Jörg
Mitglied: GrueneSosseMitSpeck
GrueneSosseMitSpeck 20.04.2022 um 13:53:37 Uhr
Goto Top
nun das sollte man sich auf die linke Hand tätowieren:

.local ist verboten
224.0.0.1 und 224.0.0.11 sind verboten
bevor ich was verwende google ich RFCs nach No-Gos

Und wer mal mit Lets Encrypt zu tun hat, der kommt am ehesten zu einem Zertifikat wenn die Windows Domäne gleich einer DNs Domäne ist die einem gehört. Aber das Verständnis dafür hat den Leuten damals auch wie heute gefehlt.
Mitglied: altmetaller
altmetaller 20.04.2022 um 15:29:55 Uhr
Goto Top
Hallo,

Zitat von @GrueneSosseMitSpeck:


Und wer mal mit Lets Encrypt zu tun hat, der kommt am ehesten zu einem Zertifikat wenn die Windows Domäne gleich einer DNs Domäne ist die einem gehört.

Umgekehrt wird ein Schuh draus: Wer eine Windows-Domäne betreibt, verteilt natürlich die eigene CA über Gruppenrichtlinien.

Und fährt in seiner lokalen Infrastruktur sicher keine Zertifikate von einer CA, bei der er nicht weiß, wer alles Zugriff auf den privaten Schlüssel hat oder bekommt.

Brave Admins trauen nur sich selber face-wink

Gruß,
Jörg
Mitglied: drahtbruecke
drahtbruecke 21.04.2022 um 12:50:11 Uhr
Goto Top
Zitat von @altmetaller:

Hallo,

Zitat von @drahtbruecke:

Weil jetzt wieder so viel off topic kam, dass niemand mehr versuchen wird, meine Frage zu beantworten?

a) Ich habe deine Frage beantwortet

Du meinst:
> > > Irgendwann war Apple mal wieder auf dem Zickentrip, wollte Windows-Admins schikanieren
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 face-smile) 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.

b) Guck' mal in sein Profil - offenbar ist er in heiliger Mission unterwegs, hier immer wieder zum Schließen von Threads aufzurufen. Vielleicht macht ihn das ja irgendwie „scharf“?!? face-smile

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 face-smile

Danke an alle!
Mitglied: drahtbruecke
drahtbruecke 21.04.2022 um 13:29:11 Uhr
Goto Top
Zitat von @GrueneSosseMitSpeck:

nun das sollte man sich auf die linke Hand tätowieren:

.local ist verboten
224.0.0.1 und 224.0.0.11 sind verboten
bevor ich was verwende google ich RFCs nach No-Gos

Und wer mal mit Lets Encrypt zu tun hat, der kommt am ehesten zu einem Zertifikat wenn die Windows Domäne gleich einer DNs Domäne ist die einem gehört. Aber das Verständnis dafür hat den Leuten damals auch wie heute gefehlt.

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.
Mitglied: drahtbruecke
drahtbruecke 21.04.2022 um 13:29:34 Uhr
Goto Top
es wird vermutlich kein weiterer Erkenntnisgewinn möglich sein.
Aber es war schön, mit euch zu reden, hat mir Spaß gemacht face-smile

Danke an alle!

Mitglied: 148523
148523 21.04.2022 um 14:09:24 Uhr
Goto Top
Aber dazu mache ich lieber eine eigene Frage auf.
Bitte nicht !!!! face-big-smile