Sammelthread: Telekom Schreiben/Brief zu SRV-Diensteauflösung und veraltetem DNS-Konfigurationseintrag über A-Record

[#1]

Hallo Telekom Hilft Community,

ich hoffe Ihr könnt mir weiterhelfen. Wir haben ein Schreiben der Telekom vom 01.09.2020 erhalten, in dem es heißt:

"... haben wir festgestellt, dass Ihre Router statt einer SRV-Diensteauflösung einen veralteten DNS-Konfigurationseintrag über A-Record nutzen, den die aktuelle Plattform ab Herbst nicht mehr unterstützt.

Um auch künftig telefonieren zu können, müssen Sie die aktuellste Firmware auf Ihren umseitig aufgeführten Routern installieren. Dafür genügt in der Regel ein einfaches Update..."

Das betrifft insgesamt 3 All-IP Anschlüsse (jeweils Mehrgeräteanschlüsse - falls die noch so heißen), von denen nur zwei für Telefonie verwendet werden.

Nun befürchte ich, dass es mit einem Router-Update nicht getan ist, da wir die SIP-Accounts nicht direkt im jeweiligen Router konfiguriert haben. Statt dessen ist am ersten Anschluss hinter dem Router eine IP-Telefonanalage "Tiptel / Yeastar MyPBX SOHO" installiert, und am zweiten Anschluß sind hinter dem Router zwei ATA-Adapter "Linksys PAP2T" installiert.

Meine Vermutung ist, dass sowohl in der IP-Telefonanlage, als auch in den ATA-Adaptern etwas eingestellt werden muss, was mit dem Eintrag "tel.t-online.de" zu tun hat.

Bei der Telekom Störungshotline konnte man mir keine Details nennen, außer immer wieder den Hinweis "bitte alle Router und Geräte updaten". Das hilft mir so aber nicht weiter, wenn ich nicht weiß, ob es damit wirklich getan ist.

Im Internet habe ich dazu bislang nur wenig gefunden. Ich habe aber bereits gelesen, dass man jetzt bei der Telekom anscheinend hinter dem Eintrag "tel.t-online.de" den Port "0" angeben muß, und dass der Service "NAPTR" aktiviert werden muss.

Kann mir jemand evtl. auf die richtige Spur helfen?

Vielen Dank im Voraus

BTG

[#2 · Accepted solution]

Hallo @btg, halllo @Telefisch,

Sie haben ja bereits viele Tipps und Unterstützung von den anderen Usern erhalten. Vielen Dank dafür an dieser Stelle.

Hier erhalten Sie noch ein paar Infos zu dem Thema.

Der Hintergrund ist, dass die Telefonie über tel.t-online.de registriert wird. Momentan wird die Auflösung von tel.t-online.de noch über A-Record erlaubt. Dabei fragt das registrierende Gerät wer tel.t-online.de ist und bekommt über den A-Record eine IP-Adresse von unserem Telefonie-Server zurück. Zukünftig wollen wir, dass das registrierende Gerät tel.t-online.de über SRV (so wie bei SIP-Trunk) auflöst, dann gibt’s als Antwort 3 mögliche IP-Adressen von unserem Telefonie-Server. Im Falle eines Ausfalls etc. vom Server wird die Telefonie sichergestellt.

Der Kunde sollte bei dem Endgerät, welches die Telefonie-Registrierung durchführt, auf die aktuellste Firmware aktualisieren und überprüfen, ob als SIP-Proxy und Registrar „tel.t-online.de“ eingetragen ist.

Wichtig ist dabei, sollte das betroffene Endgerät den SRV-Record nicht unterstützen, kann das Gerät ab Abschaltung des A-Record, keine Telefonie registrieren.

Eine Besonderheit ist die Digitalisierungsbox. Diese Kunden nutzen ein Universelles Basisprofil der CloudPBX, z.B. zur Nutzung eines Fax-Gerätes, an der Digitalisierungsbox. Dabei ist die Firmware der Digitalisierungsbox aktuell bzw. unterstützt die SRV-Auflösung, nur die Konfiguration ist nicht korrekt.

Die Konfiguration der Digitalisierungsbox muss dem Screenshot im Anhang entsprechen.

Auch bei Fremdgeräten muss geprüft werden, ob die Firmware auf dem aktuellen Stand ist und, ob dieses Endgerät die DNS-Auflösung über SRV unterstützt. Wenn ja, sollte in der Konfiguration des registrierendes EG geprüft werden, wie die DNS-Auflösung konfiguriert ist und ob der "DNS-Typ" auf "SRV" eingestellt ist.

In der Konfiguration, im SIP-Server-Feld muss immer die Domäne tel.t-online.de eingetragen sein, nicht die IP-Adresse.

Im Anhang finden Sie noch ein paar Beispiele von der Konfiguration der DNS-Einstellungen in einer Fremd-Anlage und im IP-Telefon.

Sollte noch weitere Unterstützung benötigt werden, melden Sie sich gern wieder hier bei uns.

Beste Grüße
Tanja R.

[#3]

Das ist einer der Vorteile des Systems: Durch den SRV - Record kann die Telekom die Last besser verteilen und beim Ausfall eines Servers schneller reagieren, und sie hat ja ganz sicher nicht nur einen DNS - Server für die IP-Telefonie.

[#4]

@dl8dtl 

- ... in den Netzbereichen 217.0.25/24, 217.0.28/24 und 217.0.29/24.

Das ist bei mir auch so.

[#5]

Kann man dieses Problem nicht einfach dadurch lösen, daß man die IP Adresse von einem der SIP-Server der Telekom als Registrar in die Telefonanlage einträgt ?

Im Übrigen: Das Vorgehen der Telekom in dieser Sache halte ich für eine Unverschämtheit gegenüber denjenigen, die eine Telefonanlage betreiben, für die der Hersteller keine Updates mehr anbietet. Es ist nichts dagegen einzuwenden, daß die Telekom nun eine Auflösung über srv anbietet, aber die alte Variante hätte man doch zusätzlich beibehalten können, von mir aus unter einer anderen Domain.

[#6]

Hallo @fs007 

kannst Du denn mal bitte konkretisieren was genau Dein Problem ist ?

Was wird genutzt (Hersteller, Modell, Firmwarestand) ?

Gruß
Waage1969

[#7]

Ich denke, das "Problem" oder besser die Frage hatte ich klar formuliert: Es gibt nunmal Telefonanlagen, die die Auflösung nur über den A-record "können" und für die der Hersteller kein Update mehr zur Verfügung stellt.
z.B. Auerswald compact 3000

Also: Wie wäre es dann mit der Idee, einfach die IP-Adresse eines der Telekom Sip-Server als Registrar einzutragen ?

[#8]

> Kann man dieses Problem nicht einfach dadurch lösen, daß man die IP Adresse von einem der SIP-Server der Telekom als Registrar in die Telefonanlage einträgt ?

Du kannst natürlich das ganze Internet nur mit IP-Adressen betreiben.

Nur: sinnvoll ist das nicht.

Würde im konkreten Fall vermutlich sogar funktionieren, weil die SIP-Server sich nicht dafür interessieren, welcher Hostname beim REGISTER mitgegeben wird. Würde ich persönlich aber nur als allerletzte Notlösung machen.

> Im Übrigen: Das Vorgehen der Telekom in dieser Sache halte ich für eine Unverschämtheit …

Ganz schön große Bögen, die du da spuckst.

Die Auflösung der Dienste via SRV-RRs dürfte auch schon vor 10 Jahren Stand der Technik gewesen sein. Dass viele sowas in der Software nicht implementiert haben, liegt wohl eher an Faulheit / Termindruck / … beim Erstellen der Software: bei SRV RRs muss man halt zwei Abfragen machen: zuersten den SRV, dann bekommt man eine priorisierte Liste von Hostnamen, die man anschließend abfragen muss. Dafür hat man von vornherein durch die Priorisierung auch Fallback-Möglichkeiten, da der Client sich bei Bedarf (der höchstpriorisierte Server reagiert nicht [schnell genug]) eine Alternative suchen kann.

Außerdem: auch, wenn die Telekom mit einer Abschaltung gedroht hat, das war wohl eher mittel zum Zweck, dass die Leute ihren Hintern heben und mal einen Softwareupdate überhaupt durchführen. (Hat ja auch funktioniert. :-)) Wirklich abgeschaltet worden sind die bisherigen Server ja ganz offensichtlich auch ein halbes Jahr später noch nicht.

[#9]

@dl8dtl 

Mein Problem ist leider: ich betreibe mehrere Voip Telefonanlagen an verschiedenen Standorten, die völlig einwandfrei funktionieren. Der Hersteller stellt zwar keine Updates mehr zur Verfügung, ich brauche aber auch keine. Würde ich nun neue Anlagen beschaffen müssen, würde mich das einen vierstelligen Betrag kosten (letztlich für nichts, außer den Spieltrieb einiger Telekom Angestellter zu befriedigen).

Meine Vermutung ist allerdings: Die Telekom wird die alte a-record Variante nicht abschalten, denn das würde einen "Supportaufwand" bei hunderttausenden von Nutzern erfordern, den sich die Telekom wohl nicht zumuten wird (aber bei der Telekom weißman nie ....)

[#10]

> Der Hersteller stellt zwar keine Updates mehr zur Verfügung, ich brauche aber auch keine.

Offenbar halt schon … der Hersteller hätte es ja auch gleich richtig machen können – oder sich dann wenigstens nicht aus den Updates raushalten.

Der Telekom hier einen „Spieltrieb“ zu unterstellen, finde ich schon ziemlich heftig.

[#11]

Mit "Spieltrieb" hat das nichts zu tun, sondern der Grund ist ganz einfach: Durch den SRV - Record kann man die Ausfallsicherheit erhöhen.

Das Problem lässt sich durch einen Session Border Controller lösen, und dazu kann man eine Digitalisierungsbox Smart verwenden.

[#12]

Hallo Zusammen,

wir haben jetzt auch ein Brief erhalten, mit der Bitte unsere DNS Einstellungen anzupassen. 

@Micknik ... heißt das, ich muss in der Firewall nach außen alle Ports aufmachen, weil niemand weiß, welche Ports benutzt werden?

Nachtrag:

- Yealink T41S funktioniert mit DNS-NAPTR,  jedoch zunächst nur mit "einer any to any" Regel in der Firewall. (Nicht sehr Professionell!) Es wäre schön wenn es hierzu mehr Infos von der Telekom gäbe...Danke!

- GigaSet C430IP funktioniert nach einmaliger Umstellung entsprechend der Empfehlungen nicht mehr. Selbst wenn ich auf die alten Einstellungen zurückschalte, erhalte ich "Anmeldung fehlgeschlagen". (Firmware aktualisiert, Neustart usw. ist natürlich alles durch)

@Telekom: Toll gemacht!

Beste Grüße

denkis

[#13]

Hallo @denkis 

---

@denkis  schrieb:

...

- GigaSet C430IP funktioniert nach einmaliger Umstellung entsprechend der Empfehlungen nicht mehr. Selbst wenn ich auf die alten Einstellungen zurückschalte, erhalte ich "Anmeldung fehlgeschlagen". (Firmware aktualisiert, Neustart usw. ist natürlich alles durch)

...

nutzt Du das an einer Gigaset Go Box oder womit ?

Was hast Du eingestellt ?

Ggf. ist es sinniger einen eigenen Thread dafür zu erstellen 👍
Gruß

Waage1969

[#14]

> heißt das, ich muss in der Firewall nach außen alle Ports aufmachen, weil niemand weiß, welche Ports benutzt werden?

Nach draußen brauchst du die "high ports", also oberhalb 10000. Kannst das aber auf 217.0/16 einschränken, wenn du willst, alle Kommunikation scheint über in diesem Block enthaltene Netze der Telekom zu arbeiten.

Hier mal ein (leicht anonymisiertes) Stück tcpdump; habe mich dabei selbst angerufen. Man sieht die initiale SIP-Kommunikation und danach die beiden Datenverbindungen.

10:43:35.151461 IP myaddr.59767 > 217.0.25.32.5060: SIP: OPTIONS sip:+49351xxx@tel.t-online.de SIP/2.0
10:43:35.168237 IP 217.0.25.32.5060 > myaddr.59767: SIP: SIP/2.0 200 In Ordnung
10:43:39.610385 IP myaddr.59767 > 217.0.25.32.5060: SIP: INVITE sip:yyyy@tel.t-online.de SIP/2.0
10:43:39.665665 IP 217.0.25.32.5060 > myaddr.59767: SIP: SIP/2.0 407 Proxy Authentication Required 02035034C
10:43:39.666298 IP myaddr.59767 > 217.0.25.32.5060: SIP: ACK sip:yyyy@tel.t-online.de SIP/2.0
10:43:39.666737 IP myaddr.59767 > 217.0.25.32.5060: SIP: INVITE sip:yyyy@tel.t-online.de SIP/2.0
10:43:39.880619 IP 217.0.25.32.5060 > myaddr.59767: SIP: SIP/2.0 100 Trying
10:43:39.894755 IP 217.0.25.32.5060 > myaddr.59767: SIP: INVITE sip:0351yyyy@192.168.0.24:5060 SIP/2.0
10:43:39.895763 IP myaddr.59767 > 217.0.25.32.5060: SIP: SIP/2.0 100 Trying
10:43:40.067357 IP myaddr.59767 > 217.0.25.32.5060: SIP: SIP/2.0 200 OK
10:43:40.181733 IP 217.0.25.32.5060 > myaddr.59767: SIP: SIP/2.0 200 OK
10:43:40.183249 IP myaddr.59767 > 217.0.25.32.5060: SIP: ACK sip:sgc_c@217.0.25.32;transport=udp SIP/2.0
10:43:40.241912 IP 217.0.25.32.5060 > myaddr.59767: SIP: ACK sip:192.168.0.24:5060 SIP/2.0
10:43:40.858423 IP myaddr.60731 > 217.0.6.20.51932: UDP, length 172
10:43:40.878857 IP myaddr.60731 > 217.0.6.20.51932: UDP, length 172
10:43:40.884809 IP myaddr.51565 > 217.0.6.20.12494: UDP, length 172
10:43:40.892942 IP myaddr.51565 > 217.0.6.20.12494: UDP, length 172
10:43:40.892973 IP myaddr.51565 > 217.0.6.20.12494: UDP, length 172
10:43:40.897946 IP 217.0.6.20.12494 > myaddr.51565: UDP, length 172
10:43:40.900011 IP myaddr.60731 > 217.0.6.20.51932: UDP, length 172

[#15]

Hi,
Danke für die Schnelle Antwort. Wenn Go Box die kombinierte mit Analoganschluss ist, dann habe ich keine.
Eingestellt habe ich
Telefonie - Verbindungen - "Verbindung" - Weitere Einstellungen - "DNS SRV Lookup - ja"

Danach ging nichts mehr auf dem Gigaset. Zurückschalten ging, aber Provideranmeldung bleibt "fehlgeschlagen"
Da ich im Moment im Telefonsegment noch alle Ports offen habe, weiß ich nicht warum.
Wenn ich selbst keine Lösung finde, werde ich Deiner Empfehlung folgen und einen eigenen Thread eröffnen.

@dl8dtl

Vielen Dank für den Trace.

Das Probiere ich aus, wenn das Gigaset läuft. 

Beste Grüße

Denkis

[#16]

Hallo @denkis 

an / mit welcher Basis nutzt Du das Gigaset ?

siehe ggf. auch:

https://gse.gigaset.com/fileadmin/legacy-assets/CustomerCare/Manuals/C4x/C430IP-C430AIP/A31008-M2506...

Gruß
Waage1969

[#17]

Hallo @Waage1969 

genau Das aus Deinem Link. 

https://gse.gigaset.com/fileadmin/legacy-assets/CustomerCare/Manuals/C4x/C430IP-C430AIP/A31008-M2506...

Habe jetzt auch die Lösung.

Basis zurücksetzen auf Werkseinstellungen. Dann die Provideranmeldung mit dem Handgerät vornehmen. Danach steht jedoch die alte DNS Variante drin. Also per Webkonsole auf die Basis verbinden - "DNS SRV Lookup" setzen + übernehmen + 3-4 Minuten warten. Danach erfolgt die Anmeldung fehlerfrei. Wahrscheinlich hatte ich zu viele Profile.

Zur Firewall (bei mir separates Netz für Telefon):

UDP von Telefon nach any alle Dienste

TCP von Telefon nach any DNS (53), Web(80,443)

SIP wird automatisch vom ALG geroutet

Vielen Dank.

Beste Grüße

denkis

[#18]

Schon eine ziemliche Frechheit, was die Telekom da mal wieder veranstaltet: Man hätte dasselbe auch durch mehrere A-records erreichen können, und das wäre abwärtskompatibel gewesen.

Mit der Abschaltung des A-records wird nun bundesweit Hardware im Millionenwert in die Tonne gekickt werden müssen.

Bei einem ehemaligen Staatskonzern wie der Telekom kann man Kundenorientiertheit wohl nicht erwarten, da ist scheinbar der Spieltrieb einzelner Angestellter das Maß der Dinge.

[#19]

> Schon eine ziemliche Frechheit, was die Telekom da mal wieder veranstaltet: Man hätte dasselbe auch durch mehrere A-records erreichen können, und das wäre abwärtskompatibel gewesen.

Nein, das ist nicht dasselbe. Es bleibt dann völlig dem Zufall überlassen, welcher Client sich welchen Server krallt.

Die SRV-RRs erlauben nicht nur eine Wichtung, sondern sie erlauben es auch, die verschiedenen Protokolle auf mehrere Server zu verteilen (UDP, TCP, TLS).

SRV-RRs sind für diverse Dienste schon lange gang und gäbe. Die Faulheit einzelner Implementierer der Telekom in die Schuhe zu schieben, verteidigt eindeutig die falschen Leute. Warum die Hersteller keine Updates mehr liefern wollen, bleibt dann sowieso noch zu fragen. Diese Art von "Produkt[nicht]pflege" hat in der Vergangenheit schon mehr als ein Sicherheitsloch begünstigt. Schließlich sind derartige Geräte von ihrer Bestimmung her am offenen Internet und damit immer in Punkto Sicherheit in vorderster Linie.

[#20]

@dl8dtl"Es bleibt dann völlig dem Zufall überlassen, welcher Client sich welchen Server krallt".
Der Client nimmt sich den ersten A-record, dann den 2ten, .... Wenn die Telekom die A-records sinnvoll befüllt und Anmeldungen am Registrar entsprechend zuläßt oder nicht, hat sie so ziemlich denselben Effekt, wie mit SRV Records, nur eben abwärtskompatibel für den Nutzer.
(es spricht nichts dagegen, ZUSÄTZLICH von den SRV records Gebrauch zu machen).

"Warum die Hersteller keine Updates mehr liefern wollen, bleibt dann sowieso noch zu fragen".
Einfache Antwort: Weil niemand dafür etwas zahlt und weil es auch nicht nötig wäre, wenn die Telekom mal bei einmal eingeführten Standards bliebe oder zumindest ihre Neuerungen abwärtskompatibel gestalten würde, was hier kein Problem wäre.

[#21]

---

@fs007  schrieb:

@dl8dtl"Es bleibt dann völlig dem Zufall überlassen, welcher Client sich welchen Server krallt".
Der Client nimmt sich den ersten A-record, dann den 2ten, .... Wenn die Telekom die A-records sinnvoll befüllt und Anmeldungen am Registrar entsprechend zuläßt oder nicht, hat sie so ziemlich denselben Effekt, wie mit SRV Records, nur eben abwärtskompatibel für den Nutzer.
(es spricht nichts dagegen, ZUSÄTZLICH von den SRV records Gebrauch zu machen).

"Warum die Hersteller keine Updates mehr liefern wollen, bleibt dann sowieso noch zu fragen".
Einfache Antwort: Weil niemand dafür etwas zahlt und weil es auch nicht nötig wäre, wenn die Telekom mal bei einmal eingeführten Standards bliebe oder zumindest ihre Neuerungen abwärtskompatibel gestalten würde, was hier kein Problem wäre.

---

Du erzählst nur Nonsense, die Reihenfolge von A-Records ist in keinster Weise definiert. Drei Abfragen, drei verschiedene Reihenfolgen:

dig microsoft.com @217.237.151.115 +short
40.76.4.15
13.77.161.179
104.215.148.63
40.112.72.205
40.113.200.201

dig microsoft.com @217.237.151.115 +short
40.76.4.15
40.113.200.201
40.112.72.205
104.215.148.63
13.77.161.179

dig microsoft.com @217.237.151.115 +short
40.112.72.205
104.215.148.63
13.77.161.179
40.76.4.15
40.113.200.201

[#22]

"Drei Abfragen, drei verschiedene Reihenfolgen"

Es sollte für die Telekom doch wirklich kein Problem sein, ihre DNS Server so zu konfigurieren, daß die Adressen nicht in zufälliger Reihenfolge ausgeliefert werden.

Wo ein Wille ist, ist immer auch ein Weg. Die Telekom hätte hier wirklich kundenfreundlicher vorgehen können, wenn sie gewollt hätte. Das Problem bei diesem ehemaligen Staatskonzern ist halt: Es wird nicht aus Sicht des Kunden gedacht. 

[#23]

Es sollte für die Telekom doch wirklich kein Problem sein, ihre DNS Server so zu konfigurieren, daß die Adressen nicht in zufälliger Reihenfolge ausgeliefert werden.

Sorry, die Funktionsweise des DNS wird nicht von der Telekom definiert.

Auf das Thema fehlender Sicherheitsupdates bist du auch nicht eingegangen. Lassen wir das. Du hast Frust auf die Telekom, den kann man dir nicht abnehmen.

[#24]

Kann man die nervige  Erinnerungs SMS irgendwie abstellen?

Meine Endgeräte (Yealink) sind umgestellt, dennoch kommt alle paar Tage die SMS (an die Festnetznummer) das man seine Endgeräte doch bitte umstellen möchte.

[#25]

---

@fs007  schrieb:

z.B. Auerswald compact 3000

Also: Wie wäre es dann mit der Idee, einfach die IP-Adresse eines der Telekom Sip-Server als Registrar einzutragen ?

Ja. Wie das genau in der 3000 aussieht, weiß ich nicht, aber in der 5020 lässt man bei "Domain" einfach "tel.t-online.de" stehen und trägt bei "Registrar" und "Outbound Proxy" einen Hostnamen auf einem SRV-Record ein. Also beispielsweise "f-epp-100.edns.t-ipnet.de", der spuckt der Telekom-DNS-Sever gerade bevorzugt aus.

Man hat natürlich so keinen failover auf Kundenseite, wie bei "richtigem SRV", aber hatte man bisher ja auch nicht. Und dass serverseitig ein Hochverfügbarkeitscluster verbaut wurde, könnte man der Telekom schon zutrauen.

Und natürlich könnte die Telekom ja auch, aus reiner Boshaftigkeit, ihren SIP-Server laufend neue Namen geben. Dann bleibt man mit dem statischen Eintrag auf der Strecke.

Als "etwas intelligentere" Bastellösung könnte man natürlich auch einen DNS resolver schreiben, der sich speziell um eine Phantasie-domain kümmert (die man bei "Registrar" und "Outbound Proxy" einträgt). Wenn der resolver eine A-Anfrage für die Phantasie-domain empfängt, holt er sich die aktuellen SRV records von tel.t-online.de, nimmt den mit der höchsten Priorität, holt sich dann dazu die passende IP-Adresse und liefert die als A-Antwort an die Telefonanlage zurück. Ich vermute mal, dass 200 Zeilen Python dazu reichen. Wenn man auf dem Router zufällig (oder absichtlich) Unbound als resolver laufen hat, kann man Unbound so konfigurieren, dass der selbst gebastelte DNS resolver nur bei der Phantasie-domain angesprochen wird.

[#26]

Guten Abend @techffm,

ich verstehe, dass Sie sich von dieser Erinnerungs-SMS gestört fühlen. Vor allem, da Sie Ihre Endgeräte (Yealink) bereits umgestellt haben. Es tut mir leid und es ist sicher nicht unser Anspruch, unsere Kunden zu nerven.

Nach meinen Informationen sollten die SMS erst einmal nur in der 17. Kalenderwoche an die Kunden versendet werden. Ab 26. April 2021 wurde die erste SMS mit dem Hinweis auf die Anpassung der Konfiguration der Endgeräte versendet und ca. 2 Tage später die Erinnerungs-SMS dazu.

Ich hoffe, dass Sie keine weitere SMS mehr zu dieser Thematik erhalten haben. Sollte dies dennoch der Fall sein, melden Sie sich gern noch einmal hier.

Viele Grüße
Tanja R.