Schon vielfach wurde im Netz und in Fachzeitschriften über das Ärgernis berichtet, dass die Telekom (und auch einige andere Anbieter) bei DNS-Anfragen zu nicht existierenden Domänen keine Fehler liefern, sondern frech und vor allem fälschlich eine eigene Adresse ausliefern.

Bei unserem heutigen Fall führte dies zu einem ärgerlichen Problem: Der Notebook ist über ein VPN Teil einer Windows-Domäne. Beim Netzwerkaufbau wird über das VPN eine private IP-Adresse im Subnetz der Domäne übertragen und auch der Domänennameserver übermittet. 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ür den privaten Exchange-Servernamen zurück, sodann wird der private DNS abgefragt, der dann korrekt auflöst und alles läuft perfekt.

Nicht so bei der Telekom: Auf die erste Anfrage liefert der Telekom-Nameserver eine Adresse der Telekom zurück, Outlook versucht fälschlicherweise, diesen als den Exchangeserver anzusprechen und scheitert. Der Frust beim Kunden war vorprogrammiert.

Die Lösung ist zwar relativ einfach, aber trotzdem ist es sehr ärgerlich, dass solche Workarounds genutzt werden müssen: 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. Ärgerlich ist natürlich auch, dass nun bei jeder Änderung im lokalen Namensbereich auf allen Notebooks die Hosts-Dateien geändert werden müssen.

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