Schon vielfach wurde im Netz und in Fachzeitschriften \u00fcber das \u00c4rgernis berichtet, dass die Telekom (und auch einige andere Anbieter) bei DNS-Anfragen zu nicht existierenden Dom\u00e4nen keine Fehler liefern, sondern frech und vor allem f\u00e4lschlich eine eigene Adresse ausliefern.<\/p>\n
Bei unserem heutigen Fall f\u00fchrte dies zu einem \u00e4rgerlichen Problem: Der Notebook ist \u00fcber ein VPN Teil einer Windows-Dom\u00e4ne. Beim Netzwerkaufbau wird \u00fcber das VPN eine private IP-Adresse im Subnetz der Dom\u00e4ne \u00fcbertragen und auch der Dom\u00e4nennameserver \u00fcbermittet. In normalen fremden WLAN-Netzen oder auch per UMTS-Stick etc. wird, wenn nun der vorhandene Exchange-Server von Outlook angefragt wird, zuerst der offizielle Nameserver des jeweiligen Netzes abgefragt, dieser liefert eine Fehlermeldung f\u00fcr den privaten Exchange-Servernamen zur\u00fcck, sodann wird der private DNS abgefragt, der dann korrekt aufl\u00f6st und alles l\u00e4uft perfekt.<\/p>\n
Nicht so bei der Telekom: Auf die erste Anfrage liefert der Telekom-Nameserver eine Adresse der Telekom zur\u00fcck, Outlook versucht f\u00e4lschlicherweise, diesen als den Exchangeserver anzusprechen und scheitert. Der Frust beim Kunden war vorprogrammiert.<\/p>\n
Die L\u00f6sung ist zwar relativ einfach, aber trotzdem ist es sehr \u00e4rgerlich, dass solche Workarounds genutzt werden m\u00fcssen: Wir haben in die lokale Hosts-Datei (unter Windows unter c:\\Windows\\System32\\Drivers\\etc) den FQDN eingetragen, so dass dieser dort ausgelesen wurde und keine Nameserveranfrage mehr stattfindet. \u00c4rgerlich ist nat\u00fcrlich auch, dass nun bei jeder \u00c4nderung im lokalen Namensbereich auf allen Notebooks die Hosts-Dateien ge\u00e4ndert werden m\u00fcssen.<\/p>\n
Zwar kann man diese Falschverhalten der Telekom beim eigenen DSL-Anschluss wegkonfigurieren, aber bei Nutzern, die sich in vielen verschiedenen Netzen aufhalten, ist dies keine L\u00f6sung.
\n