Split DNS für tel.t-online.de aus dem T-Dialin-Netz?
Ich hab es mal zu den Geschäftskunden verschoben. Es ist ja kein übliches Privatkundensetup 
Damit die Fachkollegen schneller Kontakt zu Dir bekommen, befülle bitte dein Profil mit deinen persönlichen Daten, Kundennummer und Rückrufnummer, (sehen nur die MA der Telekom). Wenn geschehen, dann bitte hier nochmal kurz melden.
Hallo @thomas069,
deine PBX macht die Namensauflösung für die Telefonie nach folgendem Schema?
Man sieht der Telefonieserver der Telekom präferiert folgende Reihenfolge: SIPS/tcp, SIP/udp und SIP/tcp.
Jetzt hast du doch deine Adresse.
Nachtrag:
Der Aufruf von dig muß richtigerweise so aussehen:
dig @8.8.8.8 -t NAPTR tel.t-online.de
Hallo thomas069,
bei Deinen Tests hast Du offenbar die A-Records für tel.t-online.de abgefragt? Verwende besser die SRV-Records hierfür!
Zum Vergleich habe ich selbst mal einen Test durchgeführt:
1.) Für tel.t-online.de bekomme ich über den Telekom-DNS-Server ebenfalls die 217.0.27.53 und über den Google-DNS-Server ebenfalls die 217.0.27.52.
2.) Frage ich die SRV-Records ab (bei Windows z.B. mit nslookup -q=srv _sip._udp.tel.t-online.de) bekomme ich vom Telekom-DNS folgendes Ergebnis:
_sip._udp.tel.t-online.de SRV service location:
priority = 10
weight = 0
port = 5060
svr hostname = s-epp-110.edns.t-ipnet.de
_sip._udp.tel.t-online.de SRV service location:
priority = 20
weight = 0
port = 5060
svr hostname = d-epp-100.edns.t-ipnet.de
_sip._udp.tel.t-online.de SRV service location:
priority = 30
weight = 0
port = 5060
svr hostname = h2-epp-100.edns.t-ipnet.de
3.) Der Google-DNS (8.8.8.8) liefert mir folgende SRV-Records für _sip._udp.tel-t-online.de:
_sip._udp.tel.t-online.de SRV service location:
priority = 20
weight = 0
port = 5060
svr hostname = h2-epp-801.edns.t-ipnet.de
_sip._udp.tel.t-online.de SRV service location:
priority = 10
weight = 0
port = 5060
svr hostname = do-epp-801.edns.t-ipnet.de
Die Telekom scheint offenbar über ihre eigenen DNS-Server je nach IP (und damit auch Region) des Nutzers unterschiedliche Server zurückzumelden. Das ist durchaus sinnvoll, so kann man den VoIP-Verkehr regional steuern, sodaß nicht jedes Gespräch kreuz und quer durchs Land geroutet wird. Bei "fremden" DNS-Server wie dem Google-DNS funktioniert diese Regionalisierung nicht, was man an den anderen Servern sehen kann - man bekommt dann halt nicht unbedingt die "nächsten" Voice-Gateways / RTP-Server zugewiesen.
Mein Router verwendet mit dem Telekom-DNS-Server erfolgreich die unter 2.) genannten Server. Die unter 3.) gelisteten Server habe ich jetzt nicht getestet - ich nehme aber mal an, daß auch diese funktionieren würden. Eine Garantie für dieses Szenario wird Dir aber vermutlich niemand geben können.
Warum bei den A-Records unterschiedliche Server zurückgemeldet werden und warum manche dieser Server offenbar funktionieren und manche nicht, wird sich hier vermutlich nicht ergründen lassen. Die "offizielle" Antwort wird vermutlich sein: "Nutzen Sie am besten die SRV-Records mit Telekom-DNS - idealerweise mit den üblichen Telekom-Routern" 
cu talk
Hallo,
interessante Ergebnisse. Ich hatte nur auf die Hostnamen der angegebenen Server geschaut, aber nicht, auf welche IP sie schließlich auflösen.
Vereinfacht gesagt läßt sich sagen, daß man über Nicht-Telekom-DNS-Server folgende zwei SRV-Einträge für _sip._udp.tel.t-online.de bekommt:
1.) do-epp-801.edns.t-ipnet.de mit der IP 217.0.27.52 sowie
2.) h2-epp-801.edns.t-ipnet.de mit der IP 217.0.128.132
Der erste Server wird dabei aktuell durch die niedrigere "priority" im SRV-Lookup bevorzugt und funktioniert bei Dir nicht. Was ist, wenn Du den zweiten Server direkt konfigurierst? Funktioniert dieser dann?
Hier im Forum gab es mal einen Fall, wo bei einem Nutzer der Server in Dortmund (217.0.27.52) funktioniert hat, der in Hannover (217.0.128.132) aber nicht. Siehe hierzu folgende Diskussion https://telekomhilft.telekom.de/t5/Telefonie-Internet/Per-Telekom-DNS-Server-aufgeloester-SIP-Reg-Se...
Offenbar wurde dort der nicht funktionierende Server sogar über einen Telekom-DNS-Server verbreitet. Leider ist die damalige Diskussion ohne konkretes Ergebnis im Nichts versandet.
Wenn ich Dich richtig verstehe, dann antwortet 217.0.27.52 auf Deine Anfragen überhaupt nicht? Oder verweigert er "nur" den Log-In? Falls letzteres, könnte er evtl. nur für bestimmte Kunden und Produkte gedacht sein oder vielleicht eine bestimmte Authentifizierungsart voraussetzen.
Die Telekom-VoIP-Produkte sind meines Wissens nicht für die Nutzung von fremden Providern aus gedacht, von daher fallen eventuell falsche bzw. überholte Einträge (wenn sie über fremde DNS-Server verbreitet werden) nicht so schnell auf. Denn Telekom-Kunden, die nicht die offiziellen Telekom-DNS-Server nutzen, dürfte es vermutlich relativ wenige geben...
Letztlich wird das wohl ein Fall für den Telekom-Support werden (das Telekom-Hilft-Team könnte ja eine Anfrage ans VoIP-Service-Management stellen): Sind die über Fremd-DNS-Server via SRV-Lookup angebotenen SIP-Server (vgl. oben) für die Nutzung von Telekom-VoIP freigegeben? Falls ja, warum werden dort dann teilweise nicht funktionierende SIP-Server zurückgemeldet?
Leider gibt es seitens der Telekom keine Listen o.ä. mit dauerhaft gültigen DNS-Servern im eigenen Netz; Du hast ja selbst zitiert, wie die Telekom auf die über PPPoE zugewiesenen DNS-Server verweist. Da eine eigene Lösung zu basteln, dürfte vermutlich immer ein gewisses Restrisiko beinhalten. Ich würde daher dafür plädieren, daß mal geklärt wird, was es mit den über fremde DNS-Server verbreiteten Telekom-SIP-Servern auf sich hat und ob diese Einträge ggf. angepaßt oder falls nötig aktualisiert werden können.
Daß Asterisk offenbar nur den "ersten" SRV-Eintrag verwendet und die restlichen ignoriert, habe ich bei meiner Recherche auch gelesen, das ist aber im Grunde ein klarer Widerspruch zur Idee der SRV-Records. Wundert mich, daß Asterisk da solche Probleme macht.
cu talk
Hallo,
genau, der Server unter 217.0.27.52 antwortet mir gar nicht. Auf der Asterisk Konsole finde ich im 10-Sekunden-Takt SIP/UDP Timeouts. Wenn ich SIP Debug mitlaufen lasse, so dass ich alle Nachrichten sehe, werden nur ausgehende angezeigt. Die Firewall Logs zeigen nur ausgehende, keine ankommenden Pakete an, auch keine blockierten. Daraus schließe ich, dass der Registrar meine Anfragen verwirft.
Ich gehe mit, dass es wahrscheinlich nicht gerade die Mehrzahl der User ist, die sich einen eigenen DNS zu Hause hinstellt. Aber in Zeiten, in denen es mehr Maker- und Nerdzeitschriften gibt als Herrenmagazine, belustigt es mich, dass alles, was über den Anschluss eines Speedport-Routers mit zwei iPads dahinter hinausgeht, erst einmal in den Business-Bereich verschoben wird. #Neuland
Immerhin sind wir heute so weit, dass ich als Benutzer von ein paar Linux-Servern nicht mehr mit der Hotline diskutieren muss, dass ich im ganzen Haus nur Geräte anschließen darf, die einen Stempel der Deutschen Bundespost tragen. Auch diese Diskussionen sind keine 10 Jahre her.
Insofern bin ich wie gesagt sehr angetan von den fundierten Antworten, die ich hier bekomme und freue mich, dass ich hier auf viel Hilfsbereitschaft stoße. Würde mich über eine Auflösung des Rätsels um die verschiedenen DNS-Einträge sehr freuen.
Noch ein kurzer technischer Nachtrag:
Die per SRV Lookup über den per PPP gemeldeten Telekom DNS aufgelöste Registrar IP 217.0.21.65 lässt mich gerade auch nicht mehr rein - heute Vormittag hat das noch funktioniert. Habe den SRV Lookup jetzt deaktiviert, löse per Telekom DNS und A-Record auf und telefoniere fröhlich über die 217.0.27.53. Nicht anfassen, geht gerade
Gruß
Thomas
@Melanie B. schrieb:
ich habe Ihre Frage an die Fachseite weitergeleitet.
Sobald ich von den Kollegen dazu eine Antwort erhalte, melde ich mich .
Prima, wir sind gespannt!
@thomas069 schrieb:
Ich gehe mit, dass es wahrscheinlich nicht gerade die Mehrzahl der User ist, die sich einen eigenen DNS zu Hause hinstellt. Aber in Zeiten, in denen es mehr Maker- und Nerdzeitschriften gibt als Herrenmagazine, belustigt es mich, dass alles, was über den Anschluss eines Speedport-Routers mit zwei iPads dahinter hinausgeht, erst einmal in den Business-Bereich verschoben wird. #Neuland
Die meisten Nutzer dürften mit vielen technischen Fachbegriffen wie DNS, SRV, PPPoE, SIP, RTP, etc. relativ wenig anfangen können. Ich würde sogar vermuten, daß das technische Wissen teilweise wieder etwas rückläufig ist. Denn vor ca. 10 Jahren mußte man sich bei der Konfiguration eines Routers mit mehr technischen Details beschäftigen, als heute - wo man nun ausführliche Hilfen oder gar eine automatische Konfiguration durch den Provider nutzen kann.
cu talk
Tut mir leid, wenn das so angekommen ist. Ich kann und will Deine Kompetenz nicht anhand eines Beitrages beurteilen und offensichtlich hast Du mir mit dem Verschieben helfen können, weil der Beitrag da, wo er jetzt steht, rege diskutiert wird. Der Kommentar bezog sich in keiner Weise auf Dich.
Ich stelle nur generell fest, dass ich mit meinen Anforderungen als Privatperson bei allen Kommunikationsprovidern direkt an die Business-Abteilungen verwiesen werde (ich bin auch Voda**** Business-Kunde und Unit****** Business Kunde).
Das ist in meinem Berufsumfeld nicht ungewöhnlich - viele meiner ebenfalls technisch versierten Kollegen haben privat auch Business-Anschlüsse, weil man nur dann an bestimmte Dinge wie eine feste IPv4-Adresse usw. kommt. Mir erschließt sich nur nicht, weshalb man die Dienste nicht im Privatkundengeschäft anbietet; ich kenne viele technisch ambitionierte Privatpersonen, die das gerne nutzen würden und ebenso viele selbständige Freiberufler, die einfach nur das Telefon anstöpseln wollen. Der Zusammenhang, dass man ein Server Rack nur im Keller eines Großkonzerns findet, ist in meinen Augen ein Trugschluss. Darauf bezog sich mein Kommentar.
Zum Thema Bundespoststempel: Dass das seit der Privatisierung der Netzdienste passé ist, habe ich auch versucht, dem Hotline-Mitarbeiter zu erklären. Das trug sich im Jahr 2013 zu. Ein Techniker hatte meinen anschluss bei anderen Arbeiten, die nichts mit meinem Anschluss zu tun hatten, versehentlich am DSLAM abgeklemmt. Der Fehler konnte über Monate nicht gefunden werden und ich musste mir täglich an der Hotline anhören, dass ich selbst für die Störung verantwortlich wäre, weil ich keinen Speedport verwende und die Verbindungen nicht genau aussehen wie im Willkommen-bei-der-T-Faltblatt.
Typischer Gesprächsverlauf:
- Ich möchte eine Störung melden.
- Blinkt denn die grüne Lampe am Speedport?
- Ich habe keinen Spee....
- Dann kann es nicht funktionieren | Dann haben Sie es kaputt gemacht | Das dürfen Sie nicht | ...
In dem Kontext wurde mir noch 2013 an der Hotline mitgeteilt, dass ich nur Geräte von der Telekom verwenden dürfe, weil nur die den Poststempel hätten. War nicht die einzige Kuriosität in der Zeit, aber das ist jetzt arg weit off Topic.
Sollte also alles keine persönliche Anfeindung sein, ich verstehe aber dass es so ankommen konnte. Jetzt sind wir hoffentlich wieder Freunde?
Viele Grüße
Thomas
Hallo,
hier ist die Antwort von den Kollegen der Fachseite:
Bitte fragen sie bei den Betreibern des des verwendeten DNS-Servers (also Google) fragen, warum er falsche Einträge für tel.t-online.de vorhält. Das können wir als Telekom nicht beurteilen. [...]
Hilft Ihnen diese Antwort weiter?
Leider nein. 
Der Google-DNS bekommt seine Daten ja von den zuständigen Servern der Telekom, die ihm dann die zitierten SIP-Server mitteilen. Das kann man sogar selbst nachstellen:
Mit einer SOA-Abfrage kann man den für die Domain t-online zuständigen Domain-Server abfragen:
t-online.de
primary name server = dns00.btx.dtag.de
responsible mail addr = hostmaster.t-ipnet.net
serial = 2018102601
refresh = 1800 (30 mins)
retry = 900 (15 mins)
expire = 7257600 (84 days)
default TTL = 3600 (1 hour)Zuständig für Informationen zur Domain t-online.de ist also der Server dns00.btx.dtag.de. Wenn man diesen nun zum Server tel.t-online.de befragt, verweist dieser wiederum auf folgende Nameserver:
> tel.t-online.de
Server: dns00.btx.dtag.de
Addresses: 2003:180:4:a:0:2:0:53
194.25.2.132
tel.t-online.de nameserver = ns6.edns.t-ipnet.de
tel.t-online.de nameserver = ns5.edns.t-ipnet.de
tel.t-online.de nameserver = ns4.edns.t-ipnet.de
tel.t-online.de nameserver = ns3.edns.t-ipnet.de
tel.t-online.de nameserver = ns2.edns.t-ipnet.de
tel.t-online.de nameserver = ns1.edns.t-ipnet.deWenn man dann einem dieser Server (also z.B. ns1.edns.t-ipnet.de) eine SRV-Anfrage für _sip._udp.tel.t-online.de stellt, erhält man folgende Antwort:
> _sip._udp.tel.t-online.de
Server: ns1.edns.t-ipnet.de
Addresses: 2003:180:8::53
212.185.255.209
_sip._udp.tel.t-online.de SRV service location:
priority = 20
weight = 0
port = 5060
svr hostname = h2-epp-801.edns.t-ipnet.de
_sip._udp.tel.t-online.de SRV service location:
priority = 10
weight = 0
port = 5060
svr hostname = do-epp-801.edns.t-ipnet.deDie Telekom teilt also fremden DNS-Servern (wie dem von thomas069 verwendeten Google-DNS-Server) letztlich mit, daß für den Dienst "SIP" mit dem Protokoll "UDP" auf "tel.t-online.de" die beiden Server h2-epp-801.edns.t-ipnet.de (217.0.128.132) und do-epp-801.edns.t-ipnet.de (217.0.27.52) zuständig sind.
Aufgrund des niedrigeren "priority"-Wertes von "10" wird dabei der "do-epp-801"-Server bevorzugt. Dieser Server wiederum war aber für den Nutzer thomas069 bei seinen Tests nicht nutzbar. Viele SIP-Clients hätten dann als Ausweichlösung den anderen Server ("h2-epp-801..") verwendet, dies wird von der in diesem Fall verwendeten Asterisk-Software aber offenbar nicht unterstützt.
Die Frage ist also, warum do-epp-801.edns.t-ipnet.de (217.0.27.52) für thomas069 nicht nutzbar ist (der Server könnte für bestimmte Kunden/Produkte vorbehalten sein, es könnte eine vorübergehende Störung sein oder es wäre denkbar, daß es sich um einen alten DNS-Eintrag handelt, der unbemerkt geblieben ist, weil die meisten Telekom-Nutzer die Telekom-eigenen DNS-Server verwenden und von diesen je nach Quell-IP angepaßte SRV-Angaben bekommen) bzw. warum dieser Eintrag ggf. nicht gegen einen funktionierenden Server ausgetauscht wird.
Man könnte natürlich auch sagen, daß ein SIP-Client damit rechnen muß, daß ein Server nicht nutzbar ist und er deshalb ja auch noch einen anderen Server mitgeteilt bekommt, dies funktioniert aber bei Asterisk wohl nicht (was man aufgrund der im Markt vorhandenen Verbreitung von Asterisk nicht unbedingt ignorieren sollte).
cu talk
Hallo @Melanie B.,
danke fürs Dranbleiben an diesem Thema!
Damit hätten wir also immerhin festgestellt, daß man diejenigen SIP-Server, die man über fremde DNS-Server für tel.t-online.de mitgeteilt bekommt, auch "offiziell" nutzen kann.
Interessant ist auch die Aussage, daß man bei zu häufigen SIP-Anmeldungen offenbar (wenn ich das richtig verstehe) dahingehend ausgebremst wird, daß weitere SIP-Anfragen erstmal gar nicht mehr beantwortet werden. Ich hätte vermutet, daß man dann mit einer Fehlermeldung abgewiesen wird, die Antwort der Technik läßt aber eher vermuten, daß die Anfragen dann einfach komplett ins Nichts laufen. Das könnte zu dem von @thomas069 geschilderten Phänomen passen.
Daß für die hier im Thread diskutierten Server aktuell keine Fehlermeldungen vorliegen, ist auch ein klares Statement - da sich die ganze Anfrage aber über einige Tage hinzog, läßt sich damit nicht unbedingt sagen, wie die Situation am Testtag war. Es ist aber durchaus denkbar, daß das Problem einfach zuviele Anmeldeversuche in zu kurzer Zeit waren.
Übrigens zeigt aktuell der Google-DNS für tel.t-online.de beim A-Record auf die 217.0.128.133 und bei den SRV-Records auf die bereits besprochenen Einträge (do-epp... und h2-epp..) mit den IPs 217.0.27.52 und 217.0.128.132. Wenn @thomas069 Zeit und Lust hat, kann er ggf. ja testen, wie die Situation aktuell aussieht und ob Anmeldungen bei den verschiedenen Servern möglich sind. Es sollten halt nicht zu viele Versuche auf einmal sein...
cu talk
