43
Ping ".local" Hosts nicht möglich
Hallo,
ich habe hier einen Windows 10 21H2 Notebook, das mit unserer Domain verbunden ist. Die Domain heißt xy.local und hat bisher nie Schwierigkeiten gemacht. Nun ist da Notebook per SSL-VPN verbunden mit der Zentrale und Pings an alle ".local" Hosts kommen nicht zum Ziel. Andere Anfragen wie .de und .com Adressen werden beantwortet. Bei der Suche nach einer Lösung habe ich bereits rausgefunden, das .local nun von mDNS verwendet wird. Da unsere Domain älter ist, als diese Änderung, ist dies nie aufgefallen. Gibt es eine Möglichkeit dem Client zu ermöglichen weiterhin ".local" Domains aufzulösen ?
Danke für eure Hilfe.
ich habe hier einen Windows 10 21H2 Notebook, das mit unserer Domain verbunden ist. Die Domain heißt xy.local und hat bisher nie Schwierigkeiten gemacht. Nun ist da Notebook per SSL-VPN verbunden mit der Zentrale und Pings an alle ".local" Hosts kommen nicht zum Ziel. Andere Anfragen wie .de und .com Adressen werden beantwortet. Bei der Suche nach einer Lösung habe ich bereits rausgefunden, das .local nun von mDNS verwendet wird. Da unsere Domain älter ist, als diese Änderung, ist dies nie aufgefallen. Gibt es eine Möglichkeit dem Client zu ermöglichen weiterhin ".local" Domains aufzulösen ?
Danke für eure Hilfe.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2041137050
Url: https://administrator.de/forum/ping-local-hosts-nicht-moeglich-2041137050.html
Ausgedruckt am: 26.12.2024 um 13:12 Uhr
43 Kommentare
Neuester Kommentar
Moin,
ich gehe mal von folgendem aus:
Behebe den ersten Punkt und es wird funktionieren.
Gruß
em-pie
ich gehe mal von folgendem aus:
- ihr gebt dem VPN-Client keinen DNS-Server mit, zumindest keinen, der eure *.local auflösen könnte
- die Anfragen an *.com, *.de gehen über den WAN-Anschluss vor Ort und nicht über eure VPN-Strecke
Behebe den ersten Punkt und es wird funktionieren.
Gruß
em-pie
Die TLD .local ist für Multicast-DNS gedacht und nicht für das normale Unicast-DNS. Nutze daher bitte die dafür geeignete TLD .home.arpa., denn die läuft über Unicast-DNS und ist wie die site-local-IPv6-Adressen so benutzbar, ohne dass es Störungen gibt, weil diese Hierarchie niemandem gegeben wird.
Dein Problem ist das Konzept eurer Namensauflösung.
mDNS nutzt link-local Multicast und funktioniert daher nur, wenn auf Quelle und Ziel mDNS läuft und sich diese auf dem gleichen Link befinden. Ein Router dazwischen und es ist Schluss mit Namensauflösung.
Dein Problem ist das Konzept eurer Namensauflösung.
mDNS nutzt link-local Multicast und funktioniert daher nur, wenn auf Quelle und Ziel mDNS läuft und sich diese auf dem gleichen Link befinden. Ein Router dazwischen und es ist Schluss mit Namensauflösung.
1
Die TLD .local ist für Multicast-DNS gedacht und nicht für das normale Unicast-DNS.
Genau deshalb rät auch Microsoft dringenst davon ab diese TLD zu benutzen !! Ein fataler DNS Design Fehler.Hinweise zur Verwendung der Domäne .local in DNS und mDNS
https://www.heise.de/select/ct/2017/26/1513540412603853
Bzw. die Grundlagen:
https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS
Kein Wunder also das es da solche Probleme gibt wenn man laienhaft eine falsche bzw. global reservierte TLD verwendet.
2
Moin,
Abgesehen davon, das es von MS eine Schnapsidee war, in seinen früheren Beispielen .local zu nehmen und die Leute, die dem gefolgt sind, daher heutzutage ein prinzipiellen Problem haben:
Wenn Du "lokale" Namen über VPN auflösen willst, must Du Deinen VPN-Client auch so konfigurieren, das er die richtigen Nameserver nimmt.
lks
Abgesehen davon, das es von MS eine Schnapsidee war, in seinen früheren Beispielen .local zu nehmen und die Leute, die dem gefolgt sind, daher heutzutage ein prinzipiellen Problem haben:
Wenn Du "lokale" Namen über VPN auflösen willst, must Du Deinen VPN-Client auch so konfigurieren, das er die richtigen Nameserver nimmt.
lks
2Zitat von @Lochkartenstanzer:
Wenn Du "lokale" Namen über VPN auflösen willst, must Du Deinen VPN-Client auch so konfigurieren, das er die richtigen Nameserver nimmt.
Wobei das dann auch nicht mit der TLD .local funktioniert, es sei denn man verhält sich nicht so wie im Protokoll vorgesehen und müsste dann Unicast-DNS dafür verwenden.
Die Nutzung fremder Namensräume ist einfach ein Problem.
Zitat von @Windows10Gegner:
Wobei das dann auch nicht mit der TLD .local funktioniert, es sei denn man verhält sich nicht so wie im Protokoll vorgesehen und müsste dann Unicast-DNS dafür verwenden.
Die Nutzung fremder Namensräume ist einfach ein Problem.
Zitat von @Lochkartenstanzer:
Wenn Du "lokale" Namen über VPN auflösen willst, must Du Deinen VPN-Client auch so konfigurieren, das er die richtigen Nameserver nimmt.
Wobei das dann auch nicht mit der TLD .local funktioniert, es sei denn man verhält sich nicht so wie im Protokoll vorgesehen und müsste dann Unicast-DNS dafür verwenden.
Die Nutzung fremder Namensräume ist einfach ein Problem.
Die Aussage oben war eher allgemeiner natur. Mit "loḱale" Namen waren die Namen im Intranet gemeint, unabhängig ob man nun .local oder "ad.firma.tld" verwendet. Daß man mit .local sich noch zusätzliche Probleme aufgehalst hat, kommt als Sahnehäubchen obendrauf.
lks
PS: Man kann mit "Murksereien" auch VPN mit .local-Domains machen, aber auf lange Sicht ist es einfacher, die Domain zu migrieren.
@Windows10Gegner und @148523
Sorry, aber eure Aussagen sind vollkommener Quatsch.
(Auf die "Herkunft" der .local Domains ist LKS ja schon eingegangen)
ADs mit .local TLD zu betreieben ist auch im Jahr 2022 kein Problem. Und nein, das ist kein "fataler Designfehler"). Einzig und allein die am Client eingestellte DNS Server müssen korrekt sein, dann funktioniert das Problemlos.
Die Lösung hat bereits @em-pie im ersten Post gepostet.
lg,
Slainte
Sorry, aber eure Aussagen sind vollkommener Quatsch.
(Auf die "Herkunft" der .local Domains ist LKS ja schon eingegangen)
ADs mit .local TLD zu betreieben ist auch im Jahr 2022 kein Problem. Und nein, das ist kein "fataler Designfehler"). Einzig und allein die am Client eingestellte DNS Server müssen korrekt sein, dann funktioniert das Problemlos.
Die Lösung hat bereits @em-pie im ersten Post gepostet.
lg,
Slainte
2
Nein, .local ist für mDNS vorgesehen und nicht für andere Dinge. DNS ist nicht nur MS AD, sondern ein standardisiertes Protokoll.
https://en.wikipedia.org/wiki/.local
.local zu nutzen ist daher Schwachsinn und man muss es umgehend ändern. Hat man keinen registrierten Domainnamen zur Verfügung kann man home.arpa nutzen.
https://en.wikipedia.org/wiki/.local
.local zu nutzen ist daher Schwachsinn und man muss es umgehend ändern. Hat man keinen registrierten Domainnamen zur Verfügung kann man home.arpa nutzen.
Na, auf der Boxerzeitung geschlafen? :D
local zu nutzen ist daher Schwachsinn und man muss es umgehend ändern.
Diese Aussage ist auch Schwachsinn und hat mit der Praxis mal so gar nix zu tunZitat von @Windows10Gegner:
Nein, .local ist für mDNS vorgesehen und nicht für andere Dinge. DNS ist nicht nur MS AD, sondern ein standardisiertes Protokoll.
https://en.wikipedia.org/wiki/.local
.local zu nutzen ist daher Schwachsinn und man muss es umgehend ändern. Hat man keinen registrierten Domainnamen zur Verfügung kann man home.arpa nutzen.
Nein, .local ist für mDNS vorgesehen und nicht für andere Dinge. DNS ist nicht nur MS AD, sondern ein standardisiertes Protokoll.
https://en.wikipedia.org/wiki/.local
.local zu nutzen ist daher Schwachsinn und man muss es umgehend ändern. Hat man keinen registrierten Domainnamen zur Verfügung kann man home.arpa nutzen.
Marco, sammel erstmal Erfahrung, bevor Du solche Aussagen machst.
lks
Moin
Muss umgehend geändert werden? Wieso muss? Höchstens ein sollte. Ich muss da gar nichts ändern, wenn ich wie @slainthemhath und @em-pie schrieb die Sache im Griff habe. Wir haben auch eine local Domain und der Aufwand die jetzt auf die Domain.de zu ändere ist deutlich größer als die eventuellen Probleme, die ich ggf. haben könnte, wenn ich es nicht ändere.
Im oben geteilten Administrator-Link steht am Ende auch von @emeriks:
Gruß
Doskias
Muss umgehend geändert werden? Wieso muss? Höchstens ein sollte. Ich muss da gar nichts ändern, wenn ich wie @slainthemhath und @em-pie schrieb die Sache im Griff habe. Wir haben auch eine local Domain und der Aufwand die jetzt auf die Domain.de zu ändere ist deutlich größer als die eventuellen Probleme, die ich ggf. haben könnte, wenn ich es nicht ändere.
Im oben geteilten Administrator-Link steht am Ende auch von @emeriks:
Solange man auf dem internen DNS-Servern keine Zone für "local." hostet und auch keine bedingte Weiterleitung > dafür, passiert rein gar nichts.
[...]
Und damit meine ich wirklich nur die Zone für diese TLD. Eine Zone für z.B. "mydomain.local." ist vollkommen unproblematisch.
[...]
Und damit meine ich wirklich nur die Zone für diese TLD. Eine Zone für z.B. "mydomain.local." ist vollkommen unproblematisch.
Gruß
Doskias
Zitat von @Lochkartenstanzer:
Marco, sammel erstmal Erfahrung, bevor Du solche Aussagen machst.
Zitat von @Windows10Gegner:
Nein, .local ist für mDNS vorgesehen und nicht für andere Dinge. DNS ist nicht nur MS AD, sondern ein standardisiertes Protokoll.
https://en.wikipedia.org/wiki/.local
.local zu nutzen ist daher Schwachsinn und man muss es umgehend ändern. Hat man keinen registrierten Domainnamen zur Verfügung kann man home.arpa nutzen.
Nein, .local ist für mDNS vorgesehen und nicht für andere Dinge. DNS ist nicht nur MS AD, sondern ein standardisiertes Protokoll.
https://en.wikipedia.org/wiki/.local
.local zu nutzen ist daher Schwachsinn und man muss es umgehend ändern. Hat man keinen registrierten Domainnamen zur Verfügung kann man home.arpa nutzen.
Marco, sammel erstmal Erfahrung, bevor Du solche Aussagen machst.
Ich habe damit keine Erfahrung, weil ich diesen Fehler gar nicht erst gemacht habe.
Man kann diese TLD für Unicast-DNS nutzen, ist aber einfach eine schlechte Idee. Man kann auch auf der falschen Straßenseite fahren. Technisch problemlos möglich, nur in manchen Situationen einfach eine schlechte Idee.
2007 war .local eine Empfehlung von Microsoft zur Anlage einer AD-Domain Da es bis dahin bestens funktioniert hat, hat auch niemand sich darüber Gedanken gemacht. Da der Fehler erst seit kurzem Auftritt, gehe ich davon aus das es mit einem Update mitgekommen ist. Wir werden nun erstmal eine andere Domaine nutzen um die Server zu erreichen und den AD Domainumzug Planen.
1Wir werden nun erstmal eine andere Domaine nutzen um die Server zu erreichen und den AD Domainumzug Planen.
Nochmal: das ist nicht nötig, und wird dein Problem im VPN auch nicht beheben. Du brauchst ledliglich eine korrekte DNS Config am Client.1Zitat von @dfritz:
Wir werden nun erstmal eine andere Domaine nutzen um die Server zu erreichen und den AD Domainumzug Planen.
Wir werden nun erstmal eine andere Domaine nutzen um die Server zu erreichen und den AD Domainumzug Planen.
Wenn Du Deine Nameserver im VPN-Client richtig einträgst, mußt Du erstmal nichts ändern, um die Namen aufzulösen. Auf lange Sicht ein Domänenumzug zu planen ist nicht verkehrt, ist für das aktuelle Problem aber unerheblich.
lks
1Zitat von @SlainteMhath:
Wir werden nun erstmal eine andere Domaine nutzen um die Server zu erreichen und den AD Domainumzug Planen.
Nochmal: das ist nicht nötig, und wird dein Problem im VPN auch nicht beheben. Du brauchst ledliglich eine korrekte DNS Config am Client.Das ist nur leider Murks und bleibt es auch. Anfragen für .local müssen per mDNS beantwortet werden und sind nur auf dem lokalen Link (und damit nicht über Routergrenzen hinweg) gültig.
https://datatracker.ietf.org/doc/html/rfc6762
This document specifies that the DNS top-level domain ".local." is a
special domain with special semantics, namely that any fully
qualified name ending in ".local." is link-local, and names within
this domain are meaningful only on the link where they originate.
This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6
addresses in the FE80::/10 prefix, which are link-local and
meaningful only on the link where they originate.
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).Zitat von @Windows10Gegner:
Nein, .local ist für mDNS vorgesehen und nicht für andere Dinge. DNS ist nicht nur MS AD, sondern ein standardisiertes Protokoll.
https://en.wikipedia.org/wiki/.local
.local zu nutzen ist daher Schwachsinn und man muss es umgehend ändern. Hat man keinen registrierten Domainnamen zur Verfügung kann man home.arpa nutzen.
Nein, .local ist für mDNS vorgesehen und nicht für andere Dinge. DNS ist nicht nur MS AD, sondern ein standardisiertes Protokoll.
https://en.wikipedia.org/wiki/.local
.local zu nutzen ist daher Schwachsinn und man muss es umgehend ändern. Hat man keinen registrierten Domainnamen zur Verfügung kann man home.arpa nutzen.
Glückwunsch. Du erneuerst also auch sämtliche Balken in einem Fachwerkhaus, weil 2013 beschlossen wurde, dass es ungünstig ist, Eiche statt Buche zu verwenden?
Der betroffene RFC 6762 ist erst 2013 verabschiedet worden. Ein AD, welches in den späten 90ern etabliert und zwischenzeitig verwachsen und verwurzelt ist, wird man nicht "mal eben" umbiegen können.
Klar, ich könnte eine neue Domain alá ad.contoso.tld nutzen und eine Vertrauensstellung zum alten AD aufbauen. anschließend alles Zug um Zug umziehen. Komme ich damit aber einer GF, wird die mir etwas Husten, wenn es aktuell keine Probleme gibt. Anders mag es sein, wenn man sich mit M365 beschäftigt und vieles dorthin verlagern will/ möchte.
Anders ist es natürlich, wenn ich heutzutage auf einer grünen Wiese starte, dann würde ich es direkt richtig umsetzen. Dann ggf. aber direkt mit [Standort].ad.company.tld wobei Standort = drei Buchstaben sind. sollte das Unternehmen doch mal überraschend expandieren, wäre man safe
2Das ist nur leider Murks und bleibt es auch. Anfragen für .local müssen per mDNS beantwortet werden und sind nur auf dem lokalen Link (und damit nicht über Routergrenzen hinweg) gültig.
https://datatracker.ietf.org/doc/html/rfc6762
https://datatracker.ietf.org/doc/html/rfc6762
This document specifies that the DNS top-level domain ".local." is a
special domain with special semantics, namely that any fully
qualified name ending in ".local." is link-local, and names within
this domain are meaningful only on the link where they originate.
This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6
addresses in the FE80::/10 prefix, which are link-local and
meaningful only on the link where they originate.
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).Wo du grade Murks erwähnst
Wieso funktioniert unsere VPN Verbindung denn dann? Unsere VPN-Verbindung gibt die Namensauflösung auf den DC weiter und der kennt unsere-Domain.local. Keine Auflösung zur 224.0.0.251. Der Weg kurz graphisch dargestellt:
Notebook -> Firewall als VPN Gateway -> DC-Server
Ja das was du schreibst ist richtig, aber du kannst es umgehen, wenn du deinen Nameserver und deine DNS Einträge korrekt pflegst.
Gruß
Doskias
1 Ja das was du schreibst ist richtig, aber du kannst es umgehen, wenn du deinen Nameserver und deine DNS Einträge korrekt pflegst.
Kann man machen, ist nur gegen das Protokoll und jeder Rechner, der protokollgerecht arbeitet, wird das per mDNS auflösen.
Wie gesagt, man kann auch links fahren, funktioniert problemlos, ist nur gegen die StVO.
.local für Unicast-DNS nutzen ist nicht RFC-Konform und daher etwas, was man tunlichst vermeiden sollte.
Zitat von @Windows10Gegner:
Kann man machen, ist nur gegen das Protokoll und jeder Rechner, der protokollgerecht arbeitet, wird das per mDNS auflösen.
Ja das was du schreibst ist richtig, aber du kannst es umgehen, wenn du deinen Nameserver und deine DNS Einträge korrekt pflegst.
Kann man machen, ist nur gegen das Protokoll und jeder Rechner, der protokollgerecht arbeitet, wird das per mDNS auflösen.
Ja genau. Wenn du unbedingt im Straßenverkehr bleiben möchtest gerne. Mir als Firma, also meiner Domain, ist es aber freigestellt den Linksverkehr auf dem Werksgelände anzuordnen. Heißt in deinem Fall: Wenn ich mit meinem DNS meinefirma.local pflege, dann passieren auch keine Unfälle.
Wenn ich aber, was hier das Problem ist, den DNS Server intern nicht mitgebe, dann Fragt der Client den falschen DNS Server, der von meiner internen Regel nichts weiß. Und dann kommt es halt zum Unfall, ungefähr so, wie wenn du einen Engländer fragst auf welcher Seite man fährt, er links sagt und du dann hier auch links fährst
Also nochmal: Mit einem richtig eingerichteten internen DNS Server, dem ich der VPN-Verbindung mitgebe, habe ich kein Problem mit der Domain .local. und es arbeitet trotzdem alles protokollgerecht
Zitat von @Doskias:
Also nochmal: Mit einem richtig eingerichteten internen DNS Server, dem ich der VPN-Verbindung mitgebe, habe ich kein Problem mit der Domain .local. und es arbeitet trotzdem alles protokollgerecht
Also nochmal: Mit einem richtig eingerichteten internen DNS Server, dem ich der VPN-Verbindung mitgebe, habe ich kein Problem mit der Domain .local. und es arbeitet trotzdem alles protokollgerecht
Dann lese bitte nochmal den RFC-Auszug, den ich zitiert habe. Da ist nämlich exakt das ausgeschlossen.
Das oben beschriebene Problem ist mit Sicherheit ein DNS-Fehler, wie von den Kollegen bereits gesagt. Gib' dem Client den richtigen DNS mit und er löst Dir auch per VPN die .local-Adressen auf. Das habe ich auch so öfters erfolgreich im Einsatz. Der beschriebene Fehler ist doch der Klassiker.
Ja, .local sollte man nicht mehr machen, wurde früher aber zig-fach so eingerichtet und auch von MS so vorgestellt. Das kann man eben leider nicht mehr so einfach ändern.
IMHO: Es steht auch in keinem Verhältnis zum Aufwand, ich hatte noch nie dadurch Probleme feststellen können (habe aber auch reine Windows-Netzwerke ohne Linux/Mac Rechner) und alles entsprechend konfiguriert. Sowas ohne Vorwissen zum Netzwerk gleich als "laienhaft" abzustempeln, klingt für mich nach gerade ausgelernt ohne lange Praxiserfahrung.
EDIT: Um es noch mal klar zu sagen... wenn neu, dann natürlich richtig machen !
Ja, .local sollte man nicht mehr machen, wurde früher aber zig-fach so eingerichtet und auch von MS so vorgestellt. Das kann man eben leider nicht mehr so einfach ändern.
IMHO: Es steht auch in keinem Verhältnis zum Aufwand, ich hatte noch nie dadurch Probleme feststellen können (habe aber auch reine Windows-Netzwerke ohne Linux/Mac Rechner) und alles entsprechend konfiguriert. Sowas ohne Vorwissen zum Netzwerk gleich als "laienhaft" abzustempeln, klingt für mich nach gerade ausgelernt ohne lange Praxiserfahrung.
EDIT: Um es noch mal klar zu sagen... wenn neu, dann natürlich richtig machen !
Ja, .local sollte man nicht mehr machen, wurde früher aber zig-fach so eingerichtet und auch von MS so vorgestellt. Das kann man eben leider nicht mehr so einfach ändern.
MS kann halt nicht einfach so eine TLD nutzen. Den Quatsch hat AVM mit .box. ja auch gemacht, diese ist aber jetzt gTLD.
1
Gut das protokollgerecht stimmt nicht, aber das ist das jetzt alles was du noch daran auszusetzen hast?
Dir ist an dieser Stelle (also genau hier und jetzt) aber schon klar, dass du versuchst uns mit Theorie zu überzeugen, dass das was ich und einige andere hier in der Praxis machen nicht funktioniert? Du hast mir ja noch immer nicht erklärt, wieso meine Verbindung dann funktioniert obwohl sie es nicht dürfte. Und selbst wenn wir hier keine lokal-Domain hätten, bräuchte die VPN-Verbindung weiterhin einen DNS-Server der die interne Domain auflöst. Ob das nun Firma.local oder Firma.de ist, ist dabei unerheblich.
Dir ist an dieser Stelle (also genau hier und jetzt) aber schon klar, dass du versuchst uns mit Theorie zu überzeugen, dass das was ich und einige andere hier in der Praxis machen nicht funktioniert? Du hast mir ja noch immer nicht erklärt, wieso meine Verbindung dann funktioniert obwohl sie es nicht dürfte. Und selbst wenn wir hier keine lokal-Domain hätten, bräuchte die VPN-Verbindung weiterhin einen DNS-Server der die interne Domain auflöst. Ob das nun Firma.local oder Firma.de ist, ist dabei unerheblich.
Zitat von @Doskias:
Gut das protokollgerecht stimmt nicht, aber das ist das jetzt alles was du noch daran auszusetzen hast?
Dir ist an dieser Stelle (also genau hier und jetzt) aber schon klar, dass du versuchst uns mit Theorie zu überzeugen, dass das was ich und einige andere hier in der Praxis machen nicht funktioniert?
Du hast mir ja noch immer nicht erklärt, wieso meine Verbindung dann funktioniert obwohl sie es nicht dürfte.
Es funktioniert, wenn man sich die an das Protokoll ("Regeln") hält.Gut das protokollgerecht stimmt nicht, aber das ist das jetzt alles was du noch daran auszusetzen hast?
Dir ist an dieser Stelle (also genau hier und jetzt) aber schon klar, dass du versuchst uns mit Theorie zu überzeugen, dass das was ich und einige andere hier in der Praxis machen nicht funktioniert?
Du hast mir ja noch immer nicht erklärt, wieso meine Verbindung dann funktioniert obwohl sie es nicht dürfte.
Und selbst wenn wir hier keine lokal-Domain hätten, bräuchte die VPN-Verbindung weiterhin einen DNS-Server der die interne Domain auflöst. Ob das nun Firma.local oder Firma.de ist, ist dabei unerheblich.
Ob .local oder Firma.de ist eben NICHT unerheblich. .de ist eine gTLD die von den root-Servern an den DENIC delegiert wird. Dann wird deine Domäne an deine DNS-Server delegiert.
.local wird nicht delegiert, es ist auch nicht vorgesehen, das zu tun, denn das ist für mDNS gedacht und für sonst nix.
Das alles kannst du selbst mit dig überprüfen.
home.arpa wird an ein Blackhole delegiert, um die Last von den root-Servern zu nehmen. Das wäre für interne Domainnamen, die nicht global sein sollen, die geeignete Wahl.
Wenn du home.arpa nutzt brauchst du dafür natürlich einen Unicast-DNS, aber du musst keine Änderungen an deinen Clients durchführen, die gegen das Protokoll sind und dann woanders Störungen verursachen.
Ob .local oder Firma.de ist eben NICHT unerheblich. .de ist eine gTLD die von den root-Servern an den DENIC delegiert wird. Dann wird deine Domäne an deine DNS-Server delegiert.
Ich glaube ja, du willst nur ein bischen trollen.... legt auch deine Forenname nahe... Was interessiert mich in meiner internen AD dann, ob .local von der DENIC delegiert wird, oder nicht?aber du musst keine Änderungen an deinen Clients durchführen, die gegen das Protokoll sind und dann woanders Störungen verursachen.
Und was zur Hölle muss ich an den Clients umstellen damit .local als TLD funktioniert? Ausser den AD-DNS verwenden?Und mal ein Erfahrungsbericht aus dem echten Leben: unser AD (xxx.yyy.local) "funktioniert" mit allen aktuellen Feinheiten inkl. Exchange Hybrid, AAD Sync, Hybrid DomainJoin ohne weiteres.
Naja - es is ja wieder spannend was hier abgeht... Hier gibt es z.B. diverse unterschiedliche ".local"-Domains ohne das geringste Problem. Warum sollte ich das ändern MÜSSEN? Klar, wenn ich irgendwann mal vorm Rechner sitze und mitm Finger in der Nase hänge kann man das mal angehen... Es ist eben nicht wie der gute Win-Gegner sagt das man "links auf der Strasse fährt" und dabei fast zwangsweise was kaputt geht. Es mag nicht ganz nach Standard sein - ok, schön. So what?
Zumindest is hier noch kein Server in Flammen aufgegangen, der Belzebub is auch noch nich durch die Korridore gelaufen,... Scheint also erstmal eine kosmetische Sache zu sein. Klar - wenn man es mal neu aufbaut dann würde ich es ggf. auch nicht mehr so machen ABER wenn ich aussagen lese wie "geändert werden MUSS" frage ich mich auch ob die anderen soviel Zeit haben das die für sowas wirklich gleich die ganze Domain umbenennen... Mir fehlt die nämlich leider...
Zumindest is hier noch kein Server in Flammen aufgegangen, der Belzebub is auch noch nich durch die Korridore gelaufen,... Scheint also erstmal eine kosmetische Sache zu sein. Klar - wenn man es mal neu aufbaut dann würde ich es ggf. auch nicht mehr so machen ABER wenn ich aussagen lese wie "geändert werden MUSS" frage ich mich auch ob die anderen soviel Zeit haben das die für sowas wirklich gleich die ganze Domain umbenennen... Mir fehlt die nämlich leider...
Und selbst wenn wir hier keine lokal-Domain hätten, bräuchte die VPN-Verbindung weiterhin einen DNS-Server der die interne Domain auflöst. Ob das nun Firma.local oder Firma.de ist, ist dabei unerheblich.
Ob .local oder Firma.de ist eben NICHT unerheblich. .de ist eine gTLD die von den root-Servern an den DENIC delegiert wird. Dann wird deine Domäne an deine DNS-Server delegiert.
aber du musst keine Änderungen an deinen Clients durchführen, die gegen das Protokoll sind und dann woanders Störungen verursachen.
Ich muss auch so nichts an irgendwelchen Clients ändern.
Moin,
Macht Euch Mal etwas locker. Marco ist noch ein Jugendlicher, der der ganzen Welt mitteilt, wie toll er mit Computern umgeht und es auch besser weiß wie die alten Hasen. Treibt es nicht zu bunt, sonst verliert er wieder seinen Account und muß wieder "von vorne" anfangen.
Also ein wenig Tee (oder einen Single Malt) trinken Und die Sache lockerer angehen.
lks
PS: wie geht es Deinem Opa Marco?
Macht Euch Mal etwas locker. Marco ist noch ein Jugendlicher, der der ganzen Welt mitteilt, wie toll er mit Computern umgeht und es auch besser weiß wie die alten Hasen. Treibt es nicht zu bunt, sonst verliert er wieder seinen Account und muß wieder "von vorne" anfangen.
Also ein wenig Tee (oder einen Single Malt) trinken Und die Sache lockerer angehen.
lks
PS: wie geht es Deinem Opa Marco?
1
Ich bin an der Stelle raus...
Obiger "Hinweis" von Windows10Gegner ist berechtigt, führt aber hier nicht zum Ziel, zumal es auch mit einer *.local-Domain funktioniert, undzwar ohne, dass irgendwo anders irgendwelche mDNS-Themen nicht funktionieren. Zumindest hat sich bei mir hier noch keiner unserer Nachbarn (Privat + Firmen) beschwert...
Der TO muss nur seine DNS-Server dem VPN-Client mitgeben Link und schon werden ALLE DNS-Anfragen zunächst an den internen DNS gesendet.
Dabei ist es unerheblich, ob der Client administrator.de oder DC.company.local anfragt...
Obiger "Hinweis" von Windows10Gegner ist berechtigt, führt aber hier nicht zum Ziel, zumal es auch mit einer *.local-Domain funktioniert, undzwar ohne, dass irgendwo anders irgendwelche mDNS-Themen nicht funktionieren. Zumindest hat sich bei mir hier noch keiner unserer Nachbarn (Privat + Firmen) beschwert...
Der TO muss nur seine DNS-Server dem VPN-Client mitgeben Link und schon werden ALLE DNS-Anfragen zunächst an den internen DNS gesendet.
Dabei ist es unerheblich, ob der Client administrator.de oder DC.company.local anfragt...
2
Es ist immer wieder die gleiche endlose Diskussion zum Thema ".local". @em-pie hat das oben sehr treffend mit seinem Beispiel des Fachwerkhauses erklärt.
Wie mehrfach erwähnt, dem VPN-Client den DNS mitgeben, der die ".local" auflösen kann und fertig ist der Lack.
Btw...ich bin mir sicher, das es noch tausende Domänen mit ".local" gibt, die tadellos laufen und das nur deshalb so eingerichtet haben, weil MS es lange als Vorschlag im Setup des SBS bzw. Essentials vorgegeben hat. Und genau diese Zielgruppe der KMU's (zähle mich dazu) hat oft nicht das technische Wissen, dies so ohne weiteres zu ändern.
Wie mehrfach erwähnt, dem VPN-Client den DNS mitgeben, der die ".local" auflösen kann und fertig ist der Lack.
Btw...ich bin mir sicher, das es noch tausende Domänen mit ".local" gibt, die tadellos laufen und das nur deshalb so eingerichtet haben, weil MS es lange als Vorschlag im Setup des SBS bzw. Essentials vorgegeben hat. Und genau diese Zielgruppe der KMU's (zähle mich dazu) hat oft nicht das technische Wissen, dies so ohne weiteres zu ändern.
Zitat von @Lochkartenstanzer:
Macht Euch Mal etwas locker. Marco ist noch ein Jugendlicher, der der ganzen Welt mitteilt, wie toll er mit Computern umgeht und es auch besser weiß wie die alten Hasen. Treibt es nicht zu bunt, sonst verliert er wieder seinen Account und muß wieder "von vorne" anfangen.
Ich denke wie immer macht der Ton die Musik, wenn ich augenscheinlich nur theoretisches Wissen besitze, sollte ich den Leuten, die täglich in der Praxis damit ihr Geld verdienen, vielleicht nicht versuchen einzureden was sie denn angeblich alles falsch machen und nicht wissen.Macht Euch Mal etwas locker. Marco ist noch ein Jugendlicher, der der ganzen Welt mitteilt, wie toll er mit Computern umgeht und es auch besser weiß wie die alten Hasen. Treibt es nicht zu bunt, sonst verliert er wieder seinen Account und muß wieder "von vorne" anfangen.
Zitat von @Archeon:
Zitat von @Lochkartenstanzer:
Macht Euch Mal etwas locker. Marco ist noch ein Jugendlicher, der der ganzen Welt mitteilt, wie toll er mit Computern umgeht und es auch besser weiß wie die alten Hasen. Treibt es nicht zu bunt, sonst verliert er wieder seinen Account und muß wieder "von vorne" anfangen.
Ich denke wie immer macht der Ton die Musik, wenn ich augenscheinlich nur theoretisches Wissen besitze, sollte ich den Leuten, die täglich in der Praxis damit ihr Geld verdienen, vielleicht nicht versuchen einzureden was sie denn angeblich alles falsch machen und nicht wissen.Macht Euch Mal etwas locker. Marco ist noch ein Jugendlicher, der der ganzen Welt mitteilt, wie toll er mit Computern umgeht und es auch besser weiß wie die alten Hasen. Treibt es nicht zu bunt, sonst verliert er wieder seinen Account und muß wieder "von vorne" anfangen.
Das ist mir schon klar. Nur ist das bei Marco vergebliche Liebesmühe. Und es sollte nicht so weit kommen, das sein Account gesperrt werden muß.
lks
Klar wäre das ärgerlich, aber ich denke an einem gesperrten Account sind im seltensten Fall die anderen schuld
Zitat von @Archeon:
Klar wäre das ärgerlich, aber ich denke an einem gesperrten Account sind im seltensten Fall die anderen schuld
Klar wäre das ärgerlich, aber ich denke an einem gesperrten Account sind im seltensten Fall die anderen schuld
Zumindest nicht alleine.
lka
Der TO hat ja mittlerweile so oder so aufgegeben und es kommt keinerlei themenbezogenes Feedback mehr von ihm !
Zeit also das er seinen Thread dann auch jetzt mal als erledigt schliesst !
Wie kann ich einen Beitrag als gelöst markieren?
Zeit also das er seinen Thread dann auch jetzt mal als erledigt schliesst !
Wie kann ich einen Beitrag als gelöst markieren?
Hallo in die Runde,
die eigentliche Frage wurde zwar m.E. zutreffend beantwortet, aber da ein Forum nach meinem Verständnis vorallem auch zum birektionalem Wissenaustausch dient, möchte ich dennoch noch einmal das Thema ".local" aufgreifen.
Ich hatte mich vor Längerem auch mal kurz mit dem Thema beschäftigt, weil man ja häufig liest, dass ".local" absolut böse sei und man dringend sofort seine ADs-Strukturen umbenennen müsse, obwohl dies so gar nicht mit der "real life experience" übereinstimmt. Zugegebener Maßen habe ich damals die dafür relevante RFC nicht gelesen, sondern nur ein wenig Wissen aus Sekundärquellen "ergoogelt". Dabei ergab sich damals für mich folgendes Bild:
Eine sehr häufig anzutreffende These war, dass lediglich die Toplevel-Domain "local." per Multicast-DNS aufgelöst würde. Betroffen wären demnach nur FQDNs wie "hostname.local." nicht jedoch "hostname.addomainname.local."
Letzteres würde immer "klassisch" per Unicast-DNS aufgelöst.
Diese These ist m.E. in Anbetracht der Zweckbestimmung von mDNS naheliegend und würde erklären, weshalb hunderttausende ADs, die weiterhin mit "*.addomainname.local." laufen, keine erkennbaren Probleme haben - selbst dann nicht, wenn sich - wie bei den von mir betreuten Schulen - teilweise sogar iPads, Macs und Apple-TVs im gleichen Netz tummeln.
Auch der Text des folgenden Artikels von Appple scheint diese These zu stützen: https://support.apple.com/en-us/HT204684
Dort heisst es:
Andererseits steht dort auch:
Dies scheint dem zuvor Zitierten zu widersprechen. Möglicherweise ist mein Verständnisproblem jedoch auch in meinen überschaubaren Englischkenntnissen begründet...
Gegen die These, dass lediglich die TLD "local." per mDNS aufgelöst wird, "domain.local." jedoch grundsätzlich nicht, spricht allerdings, welche ServiceRecords airprintfähige Drucker und Apple-TVs per mDNS probagieren. Da wir diese Dienste regelmäßig über Subnetzgrenzen hinweg zur Verfügung stellen müssen, nutzen wir die entsprechende Gateway-Funktion unserer WLAN-Controller. Dort sieht man dann Serviceinträge wie "_ipp._tcp.local." und "_printer._tcp.local." für Drucker sowie "_airplay._tcp.local." und "_raop._tcp.local." für Apple-TVs. Zumindest für die Domain "_tcp.local." kann die oben genannte These - zumindest im Fall von Apple-Endgeräten - also schonmal nicht stimmen, denn sonst würden diese Ressourcen nicht gefunden. Andererseits haben eben diese Apple-Endgeräte aber auch überhaupt kein Problem damit, FQDNs wie "hostname.(subdomain.)adrootdomainname.local." aufzulösen. Sicher ist deshalb, dass zumindest alle anderen Domains unterhalb "local." selbst von Apple-Geräten erforderlichenfalls zumindest auch per "klassischem" Unicast-DNS aufgelöst werden. Vermutlich als "Backup", wenn eine vorherige Multicast-DNS-Auflösung zu keinem Ergebnis geführt hat. Eine solche Implementierung dürfte jedenfalls nicht gegen die RFC 6762 verstoßen, denn mein heutiges kurzes "Anlesen" förderte folgendes zu Tage:
Vielleicht findet sich ja hier jemand, der die Muße hat, die RFC mal in Gänze zu studieren sowie das diesbezügliche Verhalten sowohl von Apple- als auch von Windows-Clients mit Wireshark genauer zu untersuchen, um der Mutmaßerei hier ein Ende zu setzen. Mir persönlich fehlt im Moment dafür leider die Zeit.
Gruß
sk
die eigentliche Frage wurde zwar m.E. zutreffend beantwortet, aber da ein Forum nach meinem Verständnis vorallem auch zum birektionalem Wissenaustausch dient, möchte ich dennoch noch einmal das Thema ".local" aufgreifen.
Ich hatte mich vor Längerem auch mal kurz mit dem Thema beschäftigt, weil man ja häufig liest, dass ".local" absolut böse sei und man dringend sofort seine ADs-Strukturen umbenennen müsse, obwohl dies so gar nicht mit der "real life experience" übereinstimmt. Zugegebener Maßen habe ich damals die dafür relevante RFC nicht gelesen, sondern nur ein wenig Wissen aus Sekundärquellen "ergoogelt". Dabei ergab sich damals für mich folgendes Bild:
Eine sehr häufig anzutreffende These war, dass lediglich die Toplevel-Domain "local." per Multicast-DNS aufgelöst würde. Betroffen wären demnach nur FQDNs wie "hostname.local." nicht jedoch "hostname.addomainname.local."
Letzteres würde immer "klassisch" per Unicast-DNS aufgelöst.
Diese These ist m.E. in Anbetracht der Zweckbestimmung von mDNS naheliegend und würde erklären, weshalb hunderttausende ADs, die weiterhin mit "*.addomainname.local." laufen, keine erkennbaren Probleme haben - selbst dann nicht, wenn sich - wie bei den von mir betreuten Schulen - teilweise sogar iPads, Macs und Apple-TVs im gleichen Netz tummeln.
Auch der Text des folgenden Artikels von Appple scheint diese These zu stützen: https://support.apple.com/en-us/HT204684
Dort heisst es:
To resolve a .local top-level domain over multicast in iOS 8, you can use any two-label name, such as “example.local”. This is compliant with the IANA assignment of the local domain to Bonjour.
You can also configure names with three or more labels (“host.example.local”) to use unicast DNS...If you need to access an internal corporate network that uses an internal, top-level domain name such as "mydomain.local", these steps can help. Gegen die These, dass lediglich die TLD "local." per mDNS aufgelöst wird, "domain.local." jedoch grundsätzlich nicht, spricht allerdings, welche ServiceRecords airprintfähige Drucker und Apple-TVs per mDNS probagieren. Da wir diese Dienste regelmäßig über Subnetzgrenzen hinweg zur Verfügung stellen müssen, nutzen wir die entsprechende Gateway-Funktion unserer WLAN-Controller. Dort sieht man dann Serviceinträge wie "_ipp._tcp.local." und "_printer._tcp.local." für Drucker sowie "_airplay._tcp.local." und "_raop._tcp.local." für Apple-TVs. Zumindest für die Domain "_tcp.local." kann die oben genannte These - zumindest im Fall von Apple-Endgeräten - also schonmal nicht stimmen, denn sonst würden diese Ressourcen nicht gefunden. Andererseits haben eben diese Apple-Endgeräte aber auch überhaupt kein Problem damit, FQDNs wie "hostname.(subdomain.)adrootdomainname.local." aufzulösen. Sicher ist deshalb, dass zumindest alle anderen Domains unterhalb "local." selbst von Apple-Geräten erforderlichenfalls zumindest auch per "klassischem" Unicast-DNS aufgelöst werden. Vermutlich als "Backup", wenn eine vorherige Multicast-DNS-Auflösung zu keinem Ergebnis geführt hat. Eine solche Implementierung dürfte jedenfalls nicht gegen die RFC 6762 verstoßen, denn mein heutiges kurzes "Anlesen" förderte folgendes zu Tage:
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). ... Implementers MAY choose to look up such names concurrently via other mechanisms (e.g., Unicast DNS) and coalesce the results in some fashion. Implementers choosing to do this should be aware of the potential for user confusion when a given name can produce different results depending on external network conditions (such as, but not limited to, which name lookup mechanism responds faster). Vielleicht findet sich ja hier jemand, der die Muße hat, die RFC mal in Gänze zu studieren sowie das diesbezügliche Verhalten sowohl von Apple- als auch von Windows-Clients mit Wireshark genauer zu untersuchen, um der Mutmaßerei hier ein Ende zu setzen. Mir persönlich fehlt im Moment dafür leider die Zeit.
Gruß
sk
MAY bedeutet eben, dass man das machen kann, aber nicht muss. Manche werden es tun, andere nicht, ergo kann man sich nicht drauf verlassen.
Da ich hier weder Windows noch Apple zur Verfügung habe, habe ich es mit einem Ubuntu 21.10 Live getestet.
Hier ist Avahi für mDNS installiert und es wird bei test.local nur per mDNS gefragt, bei heise.de natürlich nur Unicast-DNS.
Bei test1.test.local wird gar nicht gefragt, es kommt ein Fehler bei der Namensauflösung.
Da ich hier weder Windows noch Apple zur Verfügung habe, habe ich es mit einem Ubuntu 21.10 Live getestet.
Hier ist Avahi für mDNS installiert und es wird bei test.local nur per mDNS gefragt, bei heise.de natürlich nur Unicast-DNS.
Bei test1.test.local wird gar nicht gefragt, es kommt ein Fehler bei der Namensauflösung.
Da sind wir wieder bei theoretischem Wissen und praktischer Erfahrung...
Mir ist unklar, was dieser Nonsens jetzt soll. Ich habe hier jetzt ausprobiert, wie sich das mit Ubuntu verhält. Was ist daran theoretisches Wissen?
Erkläre es mir bitte.
Es geht hier um eine Windows Umgebung und du hast mal schnell was mit Linux probiert, du gibst hier "Anweisungen" an Leute die diverse dieser Domänen betreuen ohne das selbst jemals gemacht zu haben oder über die Erfahrung zu verfügen.
Du wurdest oben gefragt, warum denn diese Umgebungen trotzdem laufen, obwohl sie das deiner Aussage nach gar nicht können und wenn ich nichts übersehen habe, kam da keine wirkliche Antwort drauf.
Aber lass mal gut sein, du wirst schon noch deine Erfahrungen machen, ich bin hier jetzt raus.
Du wurdest oben gefragt, warum denn diese Umgebungen trotzdem laufen, obwohl sie das deiner Aussage nach gar nicht können und wenn ich nichts übersehen habe, kam da keine wirkliche Antwort drauf.
Aber lass mal gut sein, du wirst schon noch deine Erfahrungen machen, ich bin hier jetzt raus.
Zitat von @Windows10Gegner:
Mir ist unklar, was dieser Nonsens jetzt soll. Ich habe hier jetzt ausprobiert, wie sich das mit Ubuntu verhält. Was ist daran theoretisches Wissen?
Erkläre es mir bitte.
Mir ist unklar, was dieser Nonsens jetzt soll. Ich habe hier jetzt ausprobiert, wie sich das mit Ubuntu verhält. Was ist daran theoretisches Wissen?
Erkläre es mir bitte.
Ganz einfach: du setzt zuhause irgendein System ein... Ich kann mit nahezu JEDE These beweisen wenn ich die Randbedingungen passend wähle. Zum Beispiel können auch Schweine fliegen - ich muss halt nur eine Randbedingung schaffen bei der ich das beweisen kann (z.B. einen Parabel-Flug). Würdest du also jetzt sagen das Schweine wirklich fliegen können?
Und was dein "MAY" usw. in den RFCs angeht: Auch da hast du in der THEORIE recht. In der PRAXIS wirst du aber eben auch oft genug finden das System sich generell eh nicht an diese "Standards" halten. Ein RFC ist nunmal ein "Request for Comment". Und selbst in den "realen" Standards sind die Systeme noch oft genug sehr "frei" in der interpretation. Dabei sind die "grossen" Firmen (MS, Cisco,...) oft auch noch sehr kreativ in der Auslegung (was z.B. bei Cisco nen Port-Channel ist hat beim nächsten Hersteller wieder nen anderen Namen,...). Ergebnis ist das eben oft ist das die Hersteller einen Minimal-Standard "gemeinsam" implementieren aber jeder seine Geschmacksrichtung reinbringt. Und damit funktionieren dann eben auch .locals. Natürlich KANN ich das System überzeugen das nicht zu machen. Und natürlich kann es in X Jahren auch sein das es mal nicht mehr geht. Genauso wie Leute wie du schon vor min 10-15 Jahren kamen "man MUSS zwingend auf IPv6 umstellen, weil IPv4 demnächst nicht mehr geht". Nun, funktioniert heute auch noch prächtig. Klar KANN man (und ggf. sollte man) zumindest schon mal parallel auf v6 gehen aber es ist eben auch HEUTE noch kein zwingendes "MUSS".
Weiterhin hast du ein schönes Theorie-Wissen mit deinen Aussagen. Nur: In der Praxis würden grad bei kleineren/mittleren Unternehmen ggf. Leute geholt werden die diese Umstellung machen (wobei ich hoffe die würden auch einem Kunden sagen "mach ma locker"). Und die Kosten dann mal 1000 Euro/Tag und mehr. Da muss also ne alte Frau lange für Stricken wenn da jemand für ne Woche kommt (und ggf. noch Kosten für Ausfälle wenn das System grad mal nich läuft, mögliche Hardware-Kosten wenn man eh schon dabei ist,...). Das kann bei nem kleinem Office auch schnell mal in den Bereich von 10k+ gehen - für eine Änderung die völlig nutzlos ist wenn man eben nicht genau die Randbedingungen schafft? Es gibt eben auch noch nicht-technische Aspekte (der Fachmann würde da z.B. Finanzielle zu sagen).
Aus der PRAXIS kann ich eben auch nur sagen: Es gibt hier einige .local-Domains. Mit Endgeräten die teilweise aus allen Teilen der Welt kommen und von Leuten bedient werden die keine ITler sind. Trotzdem gehts einfach - es ist noch nix in Flammen aufgegangen, es ist noch kein Schiff dadurch gesunken - es is noch nich mal irgendein Service abgesemmelt... Und bei den Endgeräten is vom Laptop/Computer über Mobil-Geräte bis zu Entertainment-Geräten wie z.B. Amazons Alexa ziemlich ALLES dabei.
2
Wow, ich hätte nicht gedacht, das eine wahrhaftes Problem solche Diskussionen auslösen kann.
Es ist definitiv so, das der Rechner WIndows 10 21H2 frisch ab Werk (Lenovo) nicht in der Lage ist .local Domainen aufzulösen. Dies scheint kein Problem zu sein, wenn das Windows Schritt für Schritt geupdatet wurde. Es gibt aber im Netz Berichte von Leuten, die nicht mehr in der Lage waren Ihren Rechner am AD anzumelden, weil die Auflösung nicht mehr funktionierte. Der Trick war dann ein älteres Image für die Installation zu verwenden und dann zu updateten. Das war dann für den DNSClient Dienst in Ordnung. Ich habe auch bereits diverse Registry Einträge ausprobiert um mDNS Auflösung zu unterbinden, allerdings ohne Erfolg. Eine Auflösung funktioniert weiterhin nicht. Das es der richtige DNS ist und ich nicht zu blöd bin dem Client die richtige IP mitzuliefern, weiß ich daher das ich Fake Einträge in anderen DNS Zonen (nicht .local) gesetzt habe und die mit nslookup abfragen konnte.
Ich gehe davon aus, das Microsoft im DNSclient Dienst die entsprechende RFC irgendwann umgesetzt hat.
Ich habe das Problem nun damit gelöst, das ich die .local DNS Zone unter neuen Namen geklont habe.
Der Plan ist nun, den .local Domänennamen zu ändern bzw. in eine neue Domain zu mitgrieren, die RFC konform ist. Ich habe keine Lust irgendwann morgens in Büro zu kommen und festzustellen, das die komplette IT steht, weil keine Gerät dank eines MS Updates mehr per DNS kommunizieren kann.
Es ist definitiv so, das der Rechner WIndows 10 21H2 frisch ab Werk (Lenovo) nicht in der Lage ist .local Domainen aufzulösen. Dies scheint kein Problem zu sein, wenn das Windows Schritt für Schritt geupdatet wurde. Es gibt aber im Netz Berichte von Leuten, die nicht mehr in der Lage waren Ihren Rechner am AD anzumelden, weil die Auflösung nicht mehr funktionierte. Der Trick war dann ein älteres Image für die Installation zu verwenden und dann zu updateten. Das war dann für den DNSClient Dienst in Ordnung. Ich habe auch bereits diverse Registry Einträge ausprobiert um mDNS Auflösung zu unterbinden, allerdings ohne Erfolg. Eine Auflösung funktioniert weiterhin nicht. Das es der richtige DNS ist und ich nicht zu blöd bin dem Client die richtige IP mitzuliefern, weiß ich daher das ich Fake Einträge in anderen DNS Zonen (nicht .local) gesetzt habe und die mit nslookup abfragen konnte.
Ich gehe davon aus, das Microsoft im DNSclient Dienst die entsprechende RFC irgendwann umgesetzt hat.
Ich habe das Problem nun damit gelöst, das ich die .local DNS Zone unter neuen Namen geklont habe.
Der Plan ist nun, den .local Domänennamen zu ändern bzw. in eine neue Domain zu mitgrieren, die RFC konform ist. Ich habe keine Lust irgendwann morgens in Büro zu kommen und festzustellen, das die komplette IT steht, weil keine Gerät dank eines MS Updates mehr per DNS kommunizieren kann.
