phill93
Goto Top

Skuriles DNS Problem

Hallo,

hab hier ein kleines und skuriles DNS Problem.
Ich habe einen Magenta S ADSL 16k von der Telekom mit 3 VOIP Anschlüssen. Seit gestern ging das Telefon nicht mehr. Die Fehlermeldung meiner Telefonanlage (Auerswald COMPACT 3000) war Timeout (408) zum Registrar. Wenn ich den Registrar (tel.t-online.de) aus meinem internen Netz gepingt habe war er nicht erreichbar, wenn ich ihn jedoch von extern pinge ist er erreichbar. Also hab ich weitergesucht und siehe da mein eigener DNS Server liefert eine falsche IP aus. Wie sich herausstellt hat die Telekom mal wieder die IP ihrer DNS Server gändert und der interne DNS hat auf den Sekundären Forwarder umgeschaltet dieser ,der Google DNS, liefert einene falsche IP für tel.t-online.de.
>nslookup tel.t-online.de 8.8.8.8             
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
tel.t-online.de	canonical name = ims.voip.t-ipnet.de.
ims.voip.t-ipnet.de	canonical name = ims001.voip.t-ipnet.de.
ims001.voip.t-ipnet.de	canonical name = b-epp-001.isp.t-ipnet.de.
Name:	b-epp-001.isp.t-ipnet.de
Address: 217.0.23.100
Der über PPP ausgeliefert DNS Server gibt eine andere IP zurück die auch funktioniert:
>nslookup tel.t-online.de 217.0.43.129
Server:		217.0.43.129
Address:	217.0.43.129#53

Non-authoritative answer:
tel.t-online.de	canonical name = ims.voip.t-ipnet.de.
ims.voip.t-ipnet.de	canonical name = ims001.voip.t-ipnet.de.
ims001.voip.t-ipnet.de	canonical name = h-epp-001.isp.t-ipnet.de.
Name:	h-epp-001.isp.t-ipnet.de
Address: 217.0.23.36
Also hab ich meine DNS Config aktualisiert und siehe da alles geht wieder.

Kennt jemand einen DNS der Telekom der seine IP nicht wechselt? Will nicht alle 3 oder 4 Monate meine DNS Config aktualisieren

Content-Key: 336977

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

Ausgedruckt am: 19.03.2024 um 05:03 Uhr

Mitglied: Vision2015
Vision2015 05.05.2017 um 21:50:13 Uhr
Goto Top
194.25.2.129

Frank
Mitglied: LordGurke
LordGurke 05.05.2017 um 22:00:47 Uhr
Goto Top
Das Problem habe ich auch - das ist ein Problem bei der Telekom...
Siehe hier: https://twitter.com/dergrobi/status/860538245041586176

Man muss quasi den DNS-Resolver der Telekom verwenden, denn sonst erhält man möglicherweise nicht funktionierende Server zurückgemeldet.
Laut dem DTAG-Hostmaster, mit dem ich bereits vor einem Jahr wegen dieser ganz speziellen Windmühle diskutiert habe, hat die Telekom "Funktionen zum Lenken des SIP-Traffics in den DNS-Servern" und ganz offenbar äußert sich das so, dass du nicht unbedingt immer einen funktionierenden Server zurückgeliefert bekommst, wenn du keinen Telekom-DNS-Server verwendest. Nein, wirklich!
Mitglied: Phill93
Phill93 05.05.2017 um 22:05:08 Uhr
Goto Top
Hab ich auch gerade festgestellt. Hatte bis gerade eben noch den Telekom DNS in der TK Anlage gesetzt nach dem ich diesen auf den internen abgeändert habe. Bekomme ich wieder meinen Timeout. Scheinbar bekommt man eine falsche IP sobald ein zusätzlicher DNS zwischen der Telekom und dem Endgerät hängt.

Also nix mit dem internen DNS auf der TK Anlage.
Mitglied: aqui
aqui 06.05.2017 aktualisiert um 09:22:56 Uhr
Goto Top
Google DNS sollte für dich als verantwortungsvoller Netzwerker so oder so immer ein striktes Tabu sein, denn wie alle Welt ja weiss erstellen die ein Profil aller deinen Anfragen und verwerten diese Informationen über Drittanbiter an die sie diese Daten verkaufen.
Gehört ja mittlerweile zur Allgemeinbildung !
Abgesehen davon ist es ja auch ziemlich kontraproduktiv DNS Requests einmal um den Erdball zu schicken um eine lokale IP aufzulösen. Besonders wenn man weiss das die VoIP Provider ein striktes DNS Fencing für VoIP Daten machen.

Du hättest es komplett vermeiden können wenn du wie üblich deine DSL Router IP als DNS Server angegeben hättest als Weiterleitung deines internen DNS. Denn der arbeitet ja bekanntermaßen als Proxy DNS und nutzt immer die ihm aktuell via PPPoE übermittelten Provider DNS. So bleibt die Latency bei DNS Anfragen immer minimal.
Zur Sicherheit kannst du dann noch den zentralen Telekom DNS eintragen aber niemals Google oder andere sinnfreie externe DNS Server.
Simple DNS Binsenweisheiten...
Mitglied: LordGurke
LordGurke 06.05.2017 aktualisiert um 14:22:43 Uhr
Goto Top
@aqui:
Ich habe das Problem hier mit meinem lokalen DNS-Resolver. Der macht DNSSEC und aus irgendeinem Grund ist das durch die Telekom-Resolver hindurch so unfassbar langsam (> 10s pro Host!), dass ich diese meide und stattdessen mein lokaler DNS-Server selbst rekursiv auflöst.

Will heißen: Ich frage die authoritativen DNS-Server der Telekom selbst (was quasi kein Latenzunterschied ist) und bekomme dennoch eine Adresse zurückgeliefert, welche nicht funktioniert weil hinter der Adresse kein SIP-Server antwortet.
Offenbar, weil die Telekom nur über eigenen Resolver eine funktionierende Adresse verteilt. Das ist nicht, was ich von einem authoritativen Server erwarte! Der soll (zum Henker nochmal!) als erstes bei solchen Störungen aktualisiert werden!

Ich finde schon, dass das etwas ist, was man der Telekom vorwerfen darf. Wenn ein Server ausfällt, nimmt man ihn gefälligst aus der DNS-Zone raus. "Simple DNS-Binsenweisheit", wie du sagen würdest face-wink


Aber selbst die Nutzung der bei DSL-Einwahl zugewiesenen Resolver scheint nur mittelprächtig zu funktionieren. Ich habe gestern Nachmittag eine Messung über RIPE ATLAS angeworfen und mal getestet was so als A-Record über die Resolver der DSL-Router aufgelöst wurde.
Wenn man die herausrechnet, die am Router andere Server eingestellt haben [1] liegen wir da immer noch bei knapp über 20% von 140 Probes, welche die nicht funktionierende IP-Adresse 217.0.23.100 zurückgeliefert bekommen haben.
Das scheinen dem IPv6-Präfix nach zu urteilen all jene Kunden zu sein, welche einen Hybrid-Zugang haben und DNS-Resolver zugewiesen bekommen, welche nicht dieses von der Telekom angepriesene "SIP-Routing" können.
Rechnet man die Kunden mit anderem Resolver nicht heraus, sind es sogar fast 50% der Probes!

Es bleibt dabei: Die Telekom hätte einfach in ihren authoritativen Zonen den kaputten SIP-Server entfernen und den funktionierenden eintragen sollen und fertig ist das Gartenhäuschen. Hätte viel Ärger für alle Kunden erspart.

Letztes Jahr im Februar hatte ich wie im vorherigen Beitrag angedeutet ein ähnliches Problem mit meinem Resolver. Da kam nämlich manchmal für "tel.t-online.de" ein NXDOMAIN zurück. Das lag daran, dass hin und wieder einzelne auth. Server dieser Zone eben jenen Eintrag für 1-2 Minuten nicht mehr hatten und dann der Name nicht mehr gefunden wurde.
Das habe ich dann an den Hostmaster der Zone gemeldet und eine Zeile zurückerhalten dass man das Problem gefixed hat und zehn Zeilen darüber wie toll deren DNS-Resolver sind und dass ich das Problem mit den DTAG-Resolvern ja nicht hätte.
Offenbar ruht man sich bei der Telekom auf dieser Begründung noch immer aus, denn sonst wäre das gestrige (ja, ich nenne es mal) Desaster nicht aufgetreten.


Zu deinen Datenschutzbedenken beim Google-DNS: Ich verwende den auch nicht - aber denk mal darüber nach was mit deinen Daten passiert, wenn du vergisst bei deinem Provider (inzwischen haben das ja quasi alle) dieses DNS-Rewriting bei nichtgefundenen Domains abzuschalten.
Da gibt es nicht nur DNS-Anfragen sondern gleich Cookies face-wink Und was die Telekom logged weiß auch niemand...

Was die Latenz angeht ist die 8.8.8.8 nur 3ms weiter von mir entfernt als der DTAG-DNS, das ist kein echter Nachteil.
Das gilt übrigens für die meisten Anschlüsse in Deutschland - das Zauberwort heißt "Anycast".
Aber wie gesagt: Ich nutze den auch nicht - aber dass die deine Daten für irgendwelche monetarisierten Zwecke verwerten ist wohl auch mehr ein weiter verbreitetes Gerücht als ein Allgemeinwissen. Und je nach Provider funktioniert die Google-DNS-Infrastruktur tragischerweise deutlich besser und schneller als die deines Anbieters. Aber wer "to protect our user" anfängt DNS-Zonen absichtlich nicht aufzulösen oder zu verändern hat ohnehin bei mir verloren face-wink


[1] Gemessen über eine parallele DNS-Anfrage an "whoami.akamai.net" - damit konnte ich also sicher ermitteln, wer einen Telekom-Resolver verwendet und wer nicht.
Mitglied: aqui
aqui 06.05.2017 aktualisiert um 20:24:41 Uhr
Goto Top
Ich habe einen Cisco mit Proxy DNS hier laufen (VDSL) und rein gar nichts gemerkt von der Umstellung. OK, kein dedizierter lokaler DNS, deshalb war es vermutlich recht glimpflich (keinerlei Ausfall am Voice) aber die beschriebenen Delays von oben kann ich (zum Glück) nicht nachvollziehen.
Mitglied: LordGurke
LordGurke 06.05.2017 um 15:42:00 Uhr
Goto Top
Diese abartig hohen Delays treten auch nur auf, wenn man DNSSEC-Validation benutzt.
Ich kann wirklich nicht sagen weshalb, ich vermute aber dass die Telekom zu große EDNS-Pakete advertised, die großen RRSIG- und DSKEY-Antworten dann aber doch per UDP irgendwo verschütt gehen und durch diese ganzen Timeouts bis zum Wechsel auf TCP erstmal eine Menge Zeit verstreicht. Zumal die DNS-Server auch nicht immer per TCP erreichbar waren - das scheint aber inzwischen behoben zu sein.
Mitglied: aqui
aqui 06.05.2017 um 20:24:18 Uhr
Goto Top
Irgendwann werden die Telekomiker das wohl hoffentlich dann merken und das entsprechend anpassen....