Die Telekom hilft Community zieht um und ist bis zum 8. Januar 2025 nur eingeschränkt zugänglich.
DNS Server Problem (T-Online DNS)
vor 16 Jahren
Sehr geehrte Damen und Herren,
ich habe jetzt schon an 10 verschiedenen Hotlines angerufen und keiner kann mir dabei helfen.
Es geht um DNS abfragen von T-Online Zugängen aus.
Also folgendes:
Wir haben hier mehrere Außendienstler mit T-Online Zugängen und mehrere mit anderen Zugängen (z.B. Arcor)!
Bei den Arcor Zugängen ist alles OK. Das bedeutet wenn ich bei Arcor ein NSLOOKUP auf z.B.
Srvrdc1.burmt.de (nicht öffentlicher Server – Dieser steht bei uns im internen Netz und dürfte nicht öffentlich bekannt sein) mache dann findet der DNS Server diesen auch nicht: Non-existing Domain!
Bei den T-Online Zugängen ist das alles anders und dürfte nicht so sein! Das bedeutet:
Ich habe hier ein T-Online Zugang mit einem Speedport Modem:
Nach der DSL Einwahl erhalt ich folgende DNS Server zugewiesen:
217.0.43.97
217.0.43.113
Wenn ich nun ein NSLOOKUP auf srvrdc1.burmt.de mache erhalte ich:
C:\Dokumente und Einstellungen\Hackbert>nslookup
Standardserver: speedport.ip
Address: 192.168.2.1
> srvrdc1.burmt.de
Server: speedport.ip
Address: 192.168.2.1
Nicht autorisierte Antwort:
Name: srvrdc1.burmt.de
Addresses: 80.156.86.78, 62.157.140.133
Jedoch dürfte dieser DNS diese Namen nicht auflösen dürfen! Weiterhin sind die zurückgelieferten IP Adressen mir unbekannt!
Bitte helfen Sie mir bei diesem Thema oder geben mir wenigsten einen Ansprechpartner welcher dieses Problem beheben kann.
mfg Eric Egelhof
ich habe jetzt schon an 10 verschiedenen Hotlines angerufen und keiner kann mir dabei helfen.
Es geht um DNS abfragen von T-Online Zugängen aus.
Also folgendes:
Wir haben hier mehrere Außendienstler mit T-Online Zugängen und mehrere mit anderen Zugängen (z.B. Arcor)!
Bei den Arcor Zugängen ist alles OK. Das bedeutet wenn ich bei Arcor ein NSLOOKUP auf z.B.
Srvrdc1.burmt.de (nicht öffentlicher Server – Dieser steht bei uns im internen Netz und dürfte nicht öffentlich bekannt sein) mache dann findet der DNS Server diesen auch nicht: Non-existing Domain!
Bei den T-Online Zugängen ist das alles anders und dürfte nicht so sein! Das bedeutet:
Ich habe hier ein T-Online Zugang mit einem Speedport Modem:
Nach der DSL Einwahl erhalt ich folgende DNS Server zugewiesen:
217.0.43.97
217.0.43.113
Wenn ich nun ein NSLOOKUP auf srvrdc1.burmt.de mache erhalte ich:
C:\Dokumente und Einstellungen\Hackbert>nslookup
Standardserver: speedport.ip
Address: 192.168.2.1
> srvrdc1.burmt.de
Server: speedport.ip
Address: 192.168.2.1
Nicht autorisierte Antwort:
Name: srvrdc1.burmt.de
Addresses: 80.156.86.78, 62.157.140.133
Jedoch dürfte dieser DNS diese Namen nicht auflösen dürfen! Weiterhin sind die zurückgelieferten IP Adressen mir unbekannt!
Bitte helfen Sie mir bei diesem Thema oder geben mir wenigsten einen Ansprechpartner welcher dieses Problem beheben kann.
mfg Eric Egelhof
30103
13
Das könnte Ihnen auch weiterhelfen
vor 5 Monaten
1032
0
6
vor 11 Jahren
34511
0
57
vor 5 Jahren
in
1087
0
2
vor 3 Jahren
1902
0
1
vor 9 Jahren
12301
0
2
vor 16 Jahren
Das sind die "Fehlerseiten" der T-Online-Navigationshilfe.
Die Navigationshilfe kann man im Kundencenter ausschalten (wird erst nach Neueinwahl wirksam).
Olli.
0
3 Sterne Mitglied
vor 16 Jahren
Das sind die "Fehlerseiten" der T-Online-Navigationshilfe.
Die Navigationshilfe kann man im Kundencenter ausschalten (wird erst nach Neueinwahl wirksam).
Olli.
Danke für den Tip! Das ist ja schon extrem doof was die da machen!
0
Telekom hilft Team
vor 16 Jahren
Hallo Egelhof,
Danke für den Tip! Das ist ja schon extrem doof was die da machen!
Lassen wir diese Verbalinjurien einmal beiseite:
Was passiert, wenn srvrdc1.burmt.de vom DNS-Server nicht
aufgelöst wird? Offenbar erreicht der Client dann ja schließlich doch
noch einen Server und wird von diesem bedient. Woher erhält der Client
die Information, welche (lokale) IP-Adresse zu verwenden ist?
Falls Ihnen diese Frage auch "doof" erscheinen sollte: Sorry! Sie ist
weder rhetorisch gemeint noch ist es eine Fangfrage, wir wollen es
wirklich wissen!
Mit freundlichen Grüßen
Ihr T-Home-Team
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
http://forum.t-online.de/ -> Service-Foren
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
0
3 Sterne Mitglied
vor 16 Jahren
also das ist so:
wenn man einen Client mit mehreren Netzwerkkarten hat dann spielt die Bindungsreihenfolge eine wesentliche Rolle. Bei vielen Clients unserer AD'ler war das so dass die RAS Verbindung in der Reihenfolge hinter den normalen LAN Verbindungen war.
Ohne VPN ist das kein Problem. Seiten welche eine DNS IP haben werden richtig aufgelöst und andere bekommen dann von euch die "Navigationshilfe-Seite".
Sollte das VPN nun aktiviert werden war es folgendermasen (Vor der Navigationshilfe) ...
Der Client versuchte z.b. SRVRDC1.burmt.de aufzulösen und ging so vor:
1. Anfrage an die erste gebundene Netzwerkschnittstelle (z.B. LAN Schnittstelle welche mit dem Router von T-Online verbunden ist) --> Keine Antwort da es dieser Server nicht auflösen konnte.
2. Anfrage an die nächste Schnittstelle und dann so weiter ...
Irgendwann kam dann die RAS Schnittstelle über welche das VPN lief und diese konnte ja dann die Auflösung der internen Server zurückmelden. ALLES WAR OK -> Richtige IP zum richtigen SERVER!
Nun mit der Navigationhilfe passiert folgendes:
1. Anfrage an die erste gebundene Schnittstelle (z.B. LAN - Eumex Router - T-Online)
Jetzt kommt das PROBLEM: Es wird nicht mehr eine Fehlermeldung zurückgeliefert sondern eine IP Adresse - UND ZWAR DIE VON EUREN NAVIGATIONSHILFEN! Es werden somit keine weiteren Schnittstellen mehr abgefragt da ja eine Antwort vorliegt.
So funktioniert der VPN Zugang nicht mehr da keine internen Server aufgelöst werden können.
Die Lösung wäre hierbei die richtige Bindungsreihenfolge - Also erst die RAS Verbindung und als letztes Eure LAN (T-Online). Das Problem ist nur dass es sehr viele unterschiedliche Hardware giebt welche auch abere Netzwerkschnittstellen hat und die Chance dass das so ist sind gering.
Also müssen alle AD'ler welche davon keine Ahnung haben beim Support anrufen.
Ich hoffe ich konnte das einigermasen erklären ...
Bei Rückfragen Antworte ich gerne ...
0
Telekom hilft Team
vor 16 Jahren
Hallo Egelhof,
Danke, der Rest ist uns klar. Die Bindungsreihenfolge der Netzwerk-
adapter zu ändern, ist zwar noch recht einfach, wenn man weiß, wie es
geht. (http://support.microsoft.com/kb/894564/de ist da sicher hilf-
reich.) Das kann aber auch unerwünschte Nebeneffekte haben, da dann ja
erst einmal alle Requests über das VPN gehen. Sofern dort dann ein
"richtiger" DNS-Server sitzt, der alle im Internet gültigen Hostnamen
kennt, dann ginge wohl auch der private Traffic über's VPN .
Vielen Dank für die Erläuterung, immerhin verstehen wir jetzt besser,
warum sich einige Nutzer über die "Navigationshilfe" so ärgern.
Mit freundlichen Grüßen
Ihr T-Home-Team
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
http://forum.t-online.de/ -> Service-Foren
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
0
3 Sterne Mitglied
vor 16 Jahren
das stimmt zwar dass das jetzt wo man die Ursachen kennt es für Administratoren und Techniker kein Problem darstellt ein Workaround zu liefern. Der Normaluser wie z.B. unsere AD'ler haben da aber schon mehr Probleme - Die können sich das nicht erklären.
Ich denke eh dass T-Online da noch einige Probleme bekommen wird bei anderen Diensten welche auf die gleiche Art funktionieren. Es wäre vielleicht ratsam die "Navigationshilfe" in der Grundeinstellung deaktiviert zu lassen und nur die welche das wollen können das aktivieren.
Obwohl ich in als Administrator arbeite hatte ICH noch nichts von dieser Sache gehört und auch erst einmal blöde geschaut. Nun ja - wenn demnächte noch die "Zensursula" zuschlägt wird es sicherlich noch mehr Probleme geben.
Wir haben hier jetzt einfach andere DNS Server bei den AD'ler gesetzt. Dann spielt das alles wieder KEINE Rolle.
0
Starter*in
vor 16 Jahren
Die Navigationshilfe gibt's ja schon ne weile, dennoch lässt sich bis jetzt in der T-Home Suche nix dazu finden*lippen_verschlossen (?)
T-Home Homepage
http://www.t-home.de/
T-Home faq
http://hilfe.telekom.de/hsp/cms/content/HSP/de/148
T-Home Hilfe A-Z
http://hilfe.telekom.de/hsp/cms/content/HSP/de/162
0
Telekom hilft Team
vor 16 Jahren
Hallo Egelhof,
Vermutlich würde kaum jemand, der kein Problem mit dem Zugang hat, an
seiner Konfiguration "drehen", daher haben wir uns für die "Opt out"-
Lösung entschieden. Uns ist klar, dass dies speziell für Ihre Situation
unbefriedigend bleibt.
Mit freundlichen Grüßen
Ihr T-Home-Team
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
http://forum.t-online.de/ -> Service-Foren
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
0
Telekom hilft Team
vor 16 Jahren
Hallo Inqo,
Stimmt, das ist erstaunlich. Allerdings finden Sie den Server unter
http://navigationshilfe.t-online.de. Wie Sie sehen, ist es die
Suchmaschine selbst, die sich nicht finden kann.
Mit freundlichen Grüßen
Ihr T-Home-Team
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
http://forum.t-online.de/ -> Service-Foren
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
0
Starter*in
vor 16 Jahren
Spätestens wenn man in seiner Umgebung nicht komplett mit FQDNs arbeitet und mehr als einen Domain-Suffix hat, wird der Resolver ggf. den "Navigationshilfe-DNS" anfragen und eine Antwort bekommen. Der Windows-Resolver fragt nämlich grundsätzlich alle DNS Server ab, bis er eine Antwort erhält. Die Bindungsreihenfolge beeinflusst halt nur die Reihenfolge der Abfrage...
Beispiel:
- DNS Suchreihenfolge enthält: domain-a.de; domain-b.de
- Client will auf murks zugreifen, murks ist in domain-b.de registriert.
- resolver fragt murks.domain-a.de. beim VPN DNS an und enthält eine negative Antwort
- resolver fragt murks.domain-a.de. beim "Navigationshilfe-DNS" an und bekommt eine falsche Antwort
Abgesehen davon unterstelle ich mal, dass das Verhalten des DNS Servers nicht ganz RFC konform ist und ich finde die Antworten des Support-Teams etwas "vom hohen Ros herab". Schade, denn ich denke diese Änderung sorgt in diversen Firmen für eine Menge Support-Aufwand.
0