All-IP-Option: DNS-Auflösung des Registrars erfolgt nicht

[Jirka]

Hallo,

eine VoIP-Leitung ist mit SIP-Domäne konfiguriert, die aber nicht DNS-aufgelöst werden kann, und mit Registrar. Beim Registrar erfolgt (bei nicht registrierter Leitung?) vor einem Registrierungsversuch keine DNS-Auflösung mehr. Ändert sich die Zuordnung der IP-Adresse zu dem im Registrar angegebenen Namen, so wird die Leitung nicht mehr registriert, bis man den LANCOM neu startet oder den VCM.

Konkretes Beispiel:
SIP-Domäne: fritz.box
Registrar: DynDNS-Adresse der FRITZ!Box, z. B. meinebox.dyndns.org (TTL von 60 Sekunden)
SIP-ID: 620
-> Registrierung an FRITZ!Box

Ändert sich die IP-Adresse der FRITZ!Box deregistriert sich die SIP-Leitung im LANCOM und verbleibt auf ewig in diesem Zustand.
Ein DNS-Trace liefert keine Abfrage vom VCM (für diesen Namen). Ein SIP-Trace zeigt den Registrierungsversuch an der alten IP-Adresse, die die FRITZ!Box früher mal hatte.

Firmware 9.10.0486

Vielen Dank und viele Grüße,
Jirka

[Jirka]

Hallo zusammen,

das Problem besteht mit der 9.10.0591 nach wie vor.

Oben schrieb ich VCM neu starten (= aus- und wieder einschalten) als Workaround, das hat jetzt nicht mehr geholfen. Eine Konfig-Änderung an der SIP-Leitung hat geholfen, wenn man denn den LANCOM nicht neu starten kann/darf.

Vielen Dank und viele Grüße,
Jirka

[Jirka]

Hallo,

dass die DNS-Auflösung des VCM schon immer nicht optimal war, ist bekannt. So habe ich bereits 2009 im LCS-Forum moniert, dass
a) bei mehreren SIP-Leitungen mit gleicher SIP-Domain auch mehrmals DNS-Anfragen generiert werden, auch wenn eine DNS-Auflösung reichen würde (völlig ineffizient)
und
b) je SIP-Leitung sich die DNS-Anfrage im LANCOM intern noch verdoppelt, d. h. der VCM fragt im LANCOM einmal nach, raus aus dem LANCOM kommen aber zwei Anfragen unmittelbar hintereinander (egal ob die erste Anfrage erfolgreich beantwortet wurde, oder nicht; ebenfalls völlig ineffizient).
(Zum Verständnis: 8 SIP-Leitungen beim selben Provider generieren also 16 DNS-Anfragen - und das regelmäßig. Und dabei ist noch nicht mal berücksichtigt, dass es noch mehr werden, wenn keine DNS-Service-Records (SRV) verwendet werden.)

Allerdings habe ich langsam den Eindruck, dass die DNS-Auflösung im VCM noch mehrere Fehler hat. Nachdem ich jetzt seit über einem Jahr darauf warte, dass dieses Problem hier (siehe die oberen beiden Postings) gefixt wird, und ich regelmäßig durch auftretende Fehler daran erinnert werde, habe ich jetzt festgestellt, dass zwar das Problem nicht gelöst ist, aber es inzwischen möglich ist, das Problem genauer zu analysieren, es gibt jetzt nämlich zur Analyse der VCM-DNS-Probleme einen VCM-DNS-Trace! Keine schlechte Idee, wobei, wenn es die Probleme nicht gäbe, bräuchte man den Trace auch nicht...

Schaut man sich also dieses Problem mit dem VCM-DNS-Trace genauer an, stellt man fest, dass da wirklich was nicht stimmt! Die DNS-Auflösung kommt mit den TTL-Zeiten nicht klar, im Ergebnis entstehen für einen gewissen Zeitraum tausende DNS-Anfragen. So viele, dass ein ansonsten nicht belasteter 1781EF+ mit VCM-DNS-Trace und DNS-Trace auf eine CPU-Last von 17 % kommt. Jede Sekunde werden (für eine SIP-Leitung) bis zu 55 DNS-Abfragen (im LANCOM-Router) generiert, und das geschieht wie folgt:

Der VCM macht eine DNS-Abfrage und trägt sich die TTL in eine nicht sichtbare Status-Tabelle ein, im Beispielfall beträgt diese für eine DynDNS-Adresse 60 Sek. Anschließend macht der VCM nach ca. 9 Sek. noch einmal eine Abfrage (ich glaube das hängt mit dem vorangegangenen DE-REGISTER zusammen). Logischerweise, da der DNS-Server, den der LANCOM-Router befragt, ja den Namen cacht, wird dann also eine TTL von 51 Sek. mitgegeben. Die trägt sich der VCM wieder in seine nicht sichtbare Status-Tabelle ein, um die nächste DNS-Abfrage zu planen. Bis hierhin ist noch alles ok. Bei der nächsten Abfrage jedoch, die 51 Sek. nach der letzten stattfindet, müsste der VCM seine TTL wieder höher setzen, macht er aber nicht, eine TTL kann fälschlicherweise nie durch eine höhere TTL ersetzt werden, immer nur durch eine niedrigere:

Zeit ..... TTL
17:23:25 60
17:23:34 51
17:24:25 51 (DNS-Server liefert TTL von 60, VCM behält jedoch fälschlicherweise seinen geringeren Wert von 51 und arbeitet damit weiter)
17:25:16 9 (DNS-Server liefert TTL von 9, VCM übernimmt die TTL)
17:25:25 9 (DNS-Server liefert TTL von 60, VCM behält jedoch fälschlicherweise seinen geringeren Wert von 9 und arbeitet damit weiter)
17:25:34 9 (DNS-Server liefert TTL von 51, VCM behält jedoch fälschlicherweise seinen geringeren Wert von 9 und arbeitet damit weiter)
17:25:43 9 (DNS-Server liefert TTL von 42, VCM behält jedoch fälschlicherweise seinen geringeren Wert von 9 und arbeitet damit weiter)
17:25:52 9 ...
17:26:01 9 ...
17:26:10 9 ...
17:26:19 6 ...
17:26:25 6 ...
...
17:31:xx 1
...
17:47:xx 0 (ca. 31 DNS-Abfragen pro Sekunde (im VCM-DNS))
...
18:40:xx 0 VCM-DNS hängt sich nach 99.999 DNS-Abfragen auf oder quittiert seinen Dienst (der LANCOM-Router hat nicht ganz doppelt so viele DNS-Anfragen an den DNS-Server geschickt)

Ich bitte nun um zügige Bugbeseitigung. Am besten eine komplette Überarbeitung des VCM-DNS (siehe a und b oben).

Vielen Dank und viele Grüße,
Jirka

[cpuprofi]

Hallo an Alle,

gibt es inzwischen seitens LANCOM eine Lösung für diesen Fehler?

Grüße
Cpuprofi

[Jirka]

Hallo,

wurde hier was geändert? Das Verhalten ist mit der 9.24.0187 definitiv anders/geändert worden. Die TTL wird jetzt anscheinend so übernommen, wie sie von der DNS-Abfrage geliefert wurde.
Der VCM-DNS-Trace ist übrigens auch verbesserungswürdig. Dieser zeigt, insbesondere bei Providern mit vielen SIP-Servern, zeilenweile Adressauflösungen an, wenn sie gerade verfallen. Anstatt die anzuzeigen, wenn sie gerade neu reinkommen, wird in großen Teilen des Traces der alte Kram von der letzten Auflösung präsentiert. Wer das nicht weiß, sucht sich in Verbindung mit dem SIP-Packet-Trace einen Wolf.

Vielen Dank und viele Grüße,
Jirka

[beki]

wurde hier was geändert?

Ja. Es ist ein Fehler in der Behandlung der TTL von DNS Antwortpaketen aufgefallen (falscher Vergleichsoperator), der genau zum beschriebenen Verhalten passt.

Ansonsten darf ich ankündigen, dass der DNS Teil im VCM für die 10.00 komplett neu entwickelt wurde (VCM DNS Cache). Die meisten von Jirkas Anmerkungen, auch ohne sie konkret gekannt zu haben, wurden dabei berücksichtigt.

Anstatt die anzuzeigen, wenn sie gerade neu reinkommen

Der überarbeitete Trace zeigt sowohl sterbende als auch neue Address-Records.

bei mehreren SIP-Leitungen mit gleicher SIP-Domain auch mehrmals DNS-Anfragen generiert werden, auch wenn eine DNS-Auflösung reichen würde

Alle SIP-Leitungen mit dem gleichen effektiven Registrar bedienen sich des selben Caches, und wenn der diese Domain kennt, dann wird die SIP-Leitung daraus bedient. Ausnahme: Die Leitungen werden über verschiedene Routing-Tags aufgebaut.

je SIP-Leitung sich die DNS-Anfrage im LANCOM intern noch verdoppelt

In der Tat, das passiert auch in der 10.00, ich formuliere dazu einen Bugeintrag (der allerdings eine niedrige Priorität haben wird).

Ändert sich die IP-Adresse der FRITZ!Box deregistriert sich die SIP-Leitung im LANCOM und verbleibt auf ewig in diesem Zustand.

Spätestens wenn die Registrierung erneuert werden muss wird festgestellt werden, dass der Registrar nicht mehr unter der alten Adresse erreichbar ist. Der Transportweg wird dann unbrauchbar. In einem solchen Fall wird sich einer neuen Adresse auf dem DNS Cache bedient. Diese wird, weil inzwischen die TTL aufgelaufen ist, aktuell sein -- der VCM DNS Cache Maintenance Job sorgt dafür dass alternde Records frühzeitig ersetzt werden.

Im Übrigen gibt es neben dem überarbeiteten VCM DNS Trace auch einen passenden show-Befehl ab der 10.00:

Code: Alles auswählen

[VCM-DNS] 2017/02/01 11:24:44,390 [SIP DNS Cache]: Register: Adding <_sip._udp.1und1.de, Tag 0> to cache
[VCM-DNS] 2017/02/01 11:24:44,390 [SIP DNS Cache]: Register: Starting maintenance timer
[VCM-DNS] 2017/02/01 11:24:44,390 [SIP DNS Cache]: Started SRV resolve for <_sip._udp.1und1.de, Tag 0> with transaction ID 38594
[VCM-DNS] 2017/02/01 11:24:44,419 [SIP DNS Cache]: Processing DNS client response for transaction ID 38594
[VCM-DNS] 2017/02/01 11:24:44,419 [SIP DNS Cache]: Inserted new SRV record for "_sip._udp.1und1.de", priority 0, weight 0 with TTL 16089 and port 5060 and target "1und1-1.sip.1und1.de"
[VCM-DNS] 2017/02/01 11:24:44,419 [SIP DNS Cache]: Updated SRV record for "_sip._udp.1und1.de", priority 0, weight 0 to TTL 16089 and port 5060 and target "1und1-2.sip.1und1.de"
[VCM-DNS] 2017/02/01 11:24:44,419 [SIP DNS Cache]: Queried resolving of host name "1und1-2.sip.1und1.de" (Tag 0) with transaction ID 19297
[VCM-DNS] 2017/02/01 11:24:44,491 [SIP DNS Cache]: Processing DNS client response for transaction ID 19297
[VCM-DNS] 2017/02/01 11:24:44,491 [SIP DNS Cache]: Inserted new address record for "1und1-2.sip.1und1.de" with IP address 212.227.18.204 and TTL 3747
[VCM-DNS] 2017/02/01 11:24:44,491 [SIP DNS Cache]: Inserted new address record for "1und1-2.sip.1und1.de" with IP address 212.227.67.137 and TTL 3747
[VCM-DNS] 2017/02/01 11:24:44,491 [SIP DNS Cache]: Inserted new address record for "1und1-2.sip.1und1.de" with IP address 212.227.18.202 and TTL 3747
[VCM-DNS] 2017/02/01 11:24:44,491 [SIP DNS Cache]: Inserted new address record for "1und1-2.sip.1und1.de" with IP address 212.227.18.131 and TTL 3747
[VCM-DNS] 2017/02/01 11:24:44,491 [SIP DNS Cache]: Inserted new address record for "1und1-2.sip.1und1.de" with IP address 212.227.18.132 and TTL 3747
[VCM-DNS] 2017/02/01 11:24:44,491 [SIP DNS Cache]: Inserted new address record for "1und1-2.sip.1und1.de" with IP address 212.227.18.201 and TTL 3747
[VCM-DNS] 2017/02/01 11:24:44,491 [SIP DNS Cache]: Inserted new address record for "1und1-2.sip.1und1.de" with IP address 212.227.18.134 and TTL 3747
[VCM-DNS] 2017/02/01 11:24:44,491 [SIP DNS Cache]: Inserted new address record for "1und1-2.sip.1und1.de" with IP address 212.227.67.205 and TTL 3747
[VCM-DNS] 2017/02/01 11:24:44,491 [SIP DNS Cache]: Inserted new address record for "1und1-2.sip.1und1.de" with IP address 212.227.67.136 and TTL 3747
[VCM-DNS] 2017/02/01 11:24:44,492 [SIP DNS Cache]: Inserted new address record for "1und1-2.sip.1und1.de" with IP address 212.227.67.206 and TTL 3747
[VCM-DNS] 2017/02/01 11:24:44,492 [SIP DNS Cache]: Inserted new address record for "1und1-2.sip.1und1.de" with IP address 212.227.67.135 and TTL 3747
[VCM-DNS] 2017/02/01 11:24:44,492 [SIP DNS Cache]: Inserted new address record for "1und1-2.sip.1und1.de" with IP address 212.227.67.197 and TTL 3747
[VCM-DNS] 2017/02/01 11:24:44,492 [SIP DNS Cache]: Searching 1. most preferred IP address for key <_sip._udp.1und1.de, Tag 0>
[VCM-DNS] 2017/02/01 11:24:44,492 [SIP DNS Cache]: Found IP address 212.227.18.204 for DNS name "1und1-2.sip.1und1.de", which is target for SRV record "_sip._udp.1und1.de" with priority 0 and weight 0
[VCM-DNS] 2017/02/01 11:24:48,678 [SIP DNS Cache]: Register: New use count for <_sip._udp.1und1.de, Tag 0> is 2

> show vcm-dns-cache

1. Cache Entry:
    SRV string:  _sip._udp.1und1.de
    Routing Tag: 0
    Use Count:   2 SIP registrar lines depend on this cache entry

    Pending DNS queries:
        None.

    Cached SRV records for this key (sorted by preference):
          Priority |     Weight |        TTL |  Port | Target
                 0 |          0 |      15919 |  5060 | 1und1-2.sip.1und1.de

    No CNAME records cached for this key.

    Cached address records for this key (sorted by DNS name, then IPv6 first):
        Address                                 |        TTL | DNS name
        212.227.18.204                          |       3577 | 1und1-2.sip.1und1.de
        212.227.67.137                          |       3577 | 1und1-2.sip.1und1.de
        212.227.18.202                          |       3577 | 1und1-2.sip.1und1.de
        212.227.18.131                          |       3577 | 1und1-2.sip.1und1.de
        212.227.18.132                          |       3577 | 1und1-2.sip.1und1.de
        212.227.18.201                          |       3577 | 1und1-2.sip.1und1.de
        212.227.18.134                          |       3577 | 1und1-2.sip.1und1.de
        212.227.67.205                          |       3577 | 1und1-2.sip.1und1.de
        212.227.67.136                          |       3577 | 1und1-2.sip.1und1.de
        212.227.67.206                          |       3577 | 1und1-2.sip.1und1.de
        212.227.67.135                          |       3577 | 1und1-2.sip.1und1.de
        212.227.67.197                          |       3577 | 1und1-2.sip.1und1.de

2. Cache Entry:
    SRV string:  _sip._udp.tel.t-online.de
    Routing Tag: 0
    Use Count:   1 SIP registrar line depends on this cache entry

    Pending DNS queries:
        None.

    Cached SRV records for this key (sorted by preference):
          Priority |     Weight |        TTL |  Port | Target
                 0 |          5 |        157 |  5060 | ims001.voip.t-ipnet.de
                 1 |          5 |        157 |  5060 | ims002.voip.t-ipnet.de

    Cached CNAME records for this key (sorted by DNS name):
        Host Name                                                        |        TTL | Canonical Name (CNAME)
        ims001.voip.t-ipnet.de                                           |      86194 | b-epp-001.isp.t-ipnet.de
        ims002.voip.t-ipnet.de                                           |       8619 | h-epp-001.isp.t-ipnet.de

    Cached address records for this key (sorted by DNS name, then IPv6 first):
        Address                                 |        TTL | DNS name
        217.0.18.36                             |        394 | b-epp-001.isp.t-ipnet.de
        217.0.23.36                             |        287 | h-epp-001.isp.t-ipnet.de

[Koppelfeld]

wurde hier was geändert?

Ja. Es ist ein Fehler in der Behandlung der TTL von DNS Antwortpaketen aufgefallen (falscher Vergleichsoperator), der genau zum beschriebenen Verhalten passt.

Ansonsten darf ich ankündigen, dass der DNS Teil im VCM für die 10.00 komplett neu entwickelt wurde (VCM DNS Cache). Die meisten von Jirkas Anmerkungen, auch ohne sie konkret gekannt zu haben, wurden dabei berücksichtigt.

Vielen lieben Dank an Euch, Jirka und beki.

Die Arbeit an DNS SRV ist sehr wichtig, denn typischerweise soll ja eine Firewall eine TK-Anlage schützen. Das kann auch dadurch erreicht werden, daß man die Konfiguration auf die Provider - IP-Ranges beschränkt. Und genau das kann nicht funktionieren mit einer "normalen" Firewall im Zusammenspiel mit "1und1".

Hier kann der VCM erstklassig genutzt werden, um gegen eine "SIP-Farm" zu registrieren und via Call-Router eingehende und ausgehende Rufe an die TK-Anlage weiterleiten. Klappt prima. Gleichzeitig wird das SIP/NAT - Problem an der Wurzel eliminiert. Eine überzeugende Lösung.

Für Niederlassungen besonders nützlich: Mit dem VCM kann man die analogen Interfaces auch direkt gegen eine entfernte SIP - TK-Anlage konfigurieren.

Im Übrigen gibt es neben dem überarbeiteten VCM DNS Trace auch einen passenden show-Befehl ab der 10.00:

Vor der 10.x habe ich große Angst, weil mir das Ziel sehr "ambitioniert" erscheint. In der Praxis sehe ich viele Produkte ("UTM"), bei denen der Einsatz kläglich scheitert, "Securepoint", "Watchguard", "Sophos" etc.. Dabei findet das Versagen häufig auf Layer 8 statt.

Lieber stabil und schnell als "universell" und langsam.

[Jirka]

Hallo beki,

ich bin schwer beeindruckt, dass LANCOM im VoIP-Bereich endlich mal Nägel mit Köpfen macht. Es freut mich ebenso sehr, dass der Fehler in der Behandlung der TTL gefunden wurde, die positiven Auswirkungen habe ich ja bereits bemerkt, sonst hätte ich hier ja gar nicht gepostet. Nach meinen jetzigen Erkenntnissen (bin mir nicht 100 %-ig sicher, habe derzeit keine Zeit das nachzuweisen) hat dies selbst Auswirkungen auf die extremen Probleme in Verbindung mit dem Provider 1&1 (http://www.lancom-forum.de/post85376.html und andere Stellen im Forum), jedenfalls geht das plötzlich auch (wieder) einwandfrei.
Auch freut es mich, dass Du hier so nett und ausführlich und kompetent geantwortet hast - sehr schön - danke!

Ansonsten darf ich ankündigen, dass der DNS Teil im VCM für die 10.00 komplett neu entwickelt wurde (VCM DNS Cache). Die meisten von Jirkas Anmerkungen, auch ohne sie konkret gekannt zu haben, wurden dabei berücksichtigt.

Davon habe ich ehrlich gesagt nur geträumt, als ich im vorletzten Posting schrieb "Am besten eine komplette Überarbeitung des VCM-DNS.".

Der überarbeitete Trace zeigt sowohl sterbende als auch neue Address-Records.

Schön. So kann man mit dem Trace was anfangen und auch als Außenstehender damit arbeiten.

Alle SIP-Leitungen mit dem gleichen effektiven Registrar bedienen sich des selben Caches, und wenn der diese Domain kennt, dann wird die SIP-Leitung daraus bedient. Ausnahme: Die Leitungen werden über verschiedene Routing-Tags aufgebaut.

Klasse.

In der Tat, das passiert auch in der 10.00, ich formuliere dazu einen Bugeintrag (der allerdings eine niedrige Priorität haben wird).

Hmm, mit dem Nachsatz bin ich jetzt wieder auf dem Boden der Realität angekommen. Aber vielleicht wird's ja trotzdem noch was, wenn die Prio nicht ganz so gering ist wie vor 8 Jahren...

Spätestens wenn die Registrierung erneuert werden muss wird festgestellt werden, dass der Registrar nicht mehr unter der alten Adresse erreichbar ist. Der Transportweg wird dann unbrauchbar. In einem solchen Fall wird sich einer neuen Adresse auf dem DNS Cache bedient. Diese wird, weil inzwischen die TTL aufgelaufen ist, aktuell sein -- der VCM DNS Cache Maintenance Job sorgt dafür dass alternde Records frühzeitig ersetzt werden.

Das hört sich auch alles sehr gut an. (Bisher war es aber ähnlich. Dass sich der LANCOM nicht mehr registrierte, lag ja daran, dass der DNS-Teil nach 99.999 Abfragen den Dienst für diesen Namen quittiert hatte.)
Aber wieso wird ein Re-REGISTER noch mit der alten IP versucht? Es könnte doch sofort auf den aktuellen Stand im DNS-Cache zurückgegriffen werden. Vielleicht weil bei SIP-Providern mit mehreren IP-Adressen für die SIP-Server ansonsten die Registrierung jedesmal an einem anderen Server durchgeführt werden würde? Hmm. Da könnte ja geschaut werden, ob die zuletzt verwendete/ausgewählte IP noch aktuell im DNS-Cache drin ist. Denn wenn man sich den hier oben dargestellten Fall mit der SIP-Leitung überlegt, die über eine DynDNS-Adresse an einer FRITZ!Box registriert, dann würde der LANCOM-Router ja erst mal ein REGISTER an der alten IP-Adresse versuchen und man stelle sich vor, da ist inzwischen ein anderer SIP-Server, der sagt "Passwort falsch" - dann schaut der LANCOM-Router im DNS-Cache ob die IP auch stimmt? Oder probiert er es dann später mit einem weiteren REGISTER? (auf die alte IP) Im Detail müssen solche Fragen ja geklärt sein, sonst geht das schief.

Im Übrigen gibt es neben dem überarbeiteten VCM DNS Trace auch einen passenden show-Befehl ab der 10.00

Es ist ja der pure Luxus.

Vielen Dank und viele Grüße,
Jirka

P.S.: Sorry für die späte Antwort, zwei Drittel hatte ich schon vor 6 Tagen geschrieben, dann war ich nicht mehr dazu gekommen, das zu Ende zu schreiben.

[beki]

Auch freut es mich, dass Du hier so nett und ausführlich und kompetent geantwortet hast - sehr schön - danke!

Gern. Freut mich, dass es gut ankommt!

Davon habe ich ehrlich gesagt nur geträumt, als ich im vorletzten Posting schrieb "Am besten eine komplette Überarbeitung des VCM-DNS.".

Manchmal werden Träume eben wahr... Und im Ernst: IPv6 Support (insbesondere in der Art, wie das gewünscht war) einzubauen, hätte das Ding sowieso auf Links gedreht. Ich entschied dann dass eine Neuimplementierung sinnvoller wäre als den alten Code umzupflügen.

Hmm, mit dem Nachsatz bin ich jetzt wieder auf dem Boden der Realität angekommen. Aber vielleicht wird's ja trotzdem noch was, wenn die Prio nicht ganz so gering ist wie vor 8 Jahren...

Sicherlich siehst du aber auch, dass diese doppelte DNS Anfrage nur (noch) selten vorkommt und geradezu ein kosmetisches Problem ist, da die erwartete Funktionalität ja gegeben ist.

Vielleicht weil bei SIP-Providern mit mehreren IP-Adressen für die SIP-Server ansonsten die Registrierung jedesmal an einem anderen Server durchgeführt werden würde?

Das ist ein Grund, korrekt.

man stelle sich vor, da ist inzwischen ein anderer SIP-Server, der sagt "Passwort falsch" - dann schaut der LANCOM-Router im DNS-Cache ob die IP auch stimmt?

Guter Punkt, den notiere ich mir! Nach einer fehlgeschlagenen Authentifizierung wäre es durchaus sinnvoll den VCM DNS Cache zu fragen, ob die benutzte IP-Adresse noch zur konfigurierten Domäne gehört.

Gruß

[Jirka]

Hallo beki,

ich habe mit der 9.24.0191 unter gewissen Umständen schon wieder das Problem, dass sich die am Eingang des Threads erwähnte SIP-Leitung nicht mehr registriert.
In der SIP-Leitung ist unter SIP-Domäne name.domain.de (als DynDNS-Adresse mit einer TTL von 60 Sek.) eingetragen. Registrar und Proxy ist nicht angegeben. Die Registrierung erfolgt an einer FRITZ!Box mit dynamischer IP (All-IP-Anschluss, IP wechselt nur bei DSL-Trennung). Das funktionierte 18 Tage erfolgreich (Betriebszeit des LANCOM-Routers; in der Zeit wurden vermutlich 26.000 DNS-Anfragen vom VCM-DNS generiert). Heute Nacht gab es an dem Internetanschluss des LANCOM-Routers (DHCPoE, Kabel Deutschland) einen Internetausfall über 5 Stunden. Nach einer Verbindungstrennung der FRITZ!Box heute Mittag geht die SIP-Leitung nicht mehr online. Ein SIP-Trace zeigt, dass der LANCOM-Router ein REGISTER an die ehemalige IP-Adresse von name.domain.de schickt. Ein VCM-DNS-Trace zeigt, dass keinerlei Namensauflösung des Namens name.domain.de erfolgt. Der VCM-DNS hat für diesen Namen seinen Dienst quittiert. Ich vermute, dass aufgrund des Internetausfalls eine hohe Zahl an DNS-Anfragen generiert wurde, womit der VCM-DNS nicht klar kommt. Weiter oben hatte ich diese Beobachtung auch schon gemacht:

18:40:xx 0 VCM-DNS hängt sich nach 99.999 DNS-Abfragen auf oder quittiert seinen Dienst (der LANCOM-Router hat nicht ganz doppelt so viele DNS-Anfragen an den DNS-Server geschickt)

Fakt ist auf alle Fälle, dass der VCM-DNS keine Anstalten macht, die Adresse korrekt aufzulösen. Ich würde die Sache hier jetzt auf sich beruhen lassen, denn man kann ja davon ausgehen, dass das Problem mit dem neuen VCM-DNS sowieso gefixt ist, allerdings gibt es ja Geräte, die den neuen VCM-DNS leider nicht mehr erleben werden, und wo daher anderweitig eine Lösung gefunden werden muss (die Arbeit könnte man sich sparen, wenn es für die Geräte noch LCOS-Support geben würde; viele Grüße an die entsprechenden Entscheider, hoffentlich haben sie das auch einkalkuliert).

Vielen Dank und viele Grüße,
Jirka

[COMCARGRU]

allerdings gibt es ja Geräte, die den neuen VCM-DNS leider nicht mehr erleben werden, und wo daher anderweitig eine Lösung gefunden werden muss (die Arbeit könnte man sich sparen, wenn es für die Geräte noch LCOS-Support geben würde; viele Grüße an die entsprechenden Entscheider, hoffentlich haben sie das auch einkalkuliert).

Ich habe den Mist mit dieser Entscheidung auch direkt an Lancom kommuniziert - Antwort darauf gab es keine! - Aber das ist denke ich trotzdem nötig. Nur wenn es direkt bei Lancom landet und nicht nur hier im Forum bekommt man bei der GF vielleicht etwas mit...

Kann also jedem nur Raten nicht nur hier sondern auch direkt bei Lancom eine Beschwerde deswegen abzugeben

[Jirka]

Hallo beki,

bist Du noch da? Lange nichts mehr von Dir gehört...

Ich habe ein Problem. Vor einer guten Woche registrierten sich bei mir an 3 Stellen die Kabel Deutschland SIP-Leitungen nicht mehr. Man konnte machen, was man wollte, es führte kein Weg zu registrierten Leitungen. FRITZ!Boxen hingegen funktionierten einwandfrei. Nach mehreren Stunden hatte ich dann rausgefunden, dass ein DNS-Problem die Ursache des Übels war.
Die SIP-Leitungen haben in der SIP-Domäne z. B. reg174.kabelphone.de stehen. Bei Registrar steht proxy.kabelphone.de.
Als ich irgendwann mal merkte, dass die Fehlerursache in Richtung DNS geht, dachte ich zuerst, der LANCOM würde beim Registrar kein Abfrage der Service Records machen (wie er es bei der SIP-Domäne macht). Aber das macht er laut Trace schon. Unter Windows sieht das dann ungefähr so aus:

Code: Alles auswählen

C:\Users\Jirka>nslookup -type=srv _sip._udp.proxy.kabelphone.de 83.169.184.34
Server:  83-169-184-34-isp.superkabel.de
Address:  83.169.184.34

Nicht autorisierende Antwort:
_sip._udp.proxy.kabelphone.de   SRV service location:
          priority       = 20
          weight         = 33
          port           = 5060
          svr hostname   = prox03.kabelphone.de
_sip._udp.proxy.kabelphone.de   SRV service location:
          priority       = 10
          weight         = 100
          port           = 5060
          svr hostname   = prox01.kabelphone.de
_sip._udp.proxy.kabelphone.de   SRV service location:
          priority       = 20
          weight         = 33
          port           = 5060
          svr hostname   = prox04.kabelphone.de
_sip._udp.proxy.kabelphone.de   SRV service location:
          priority       = 20
          weight         = 33
          port           = 5060
          svr hostname   = prox02.kabelphone.de

Nun muss der LANCOM aber aus diesen 4 Ergebnissen einen rausgegriffen haben, und auf dem blieb er immer und ewig hängen. Der SIP-Trace zeigte, dass der LANCOM ständig REGISTER an immer die gleiche IP schickte, aber nie auch nur eine Antwort kam. Dieser SIP-Server war vermutlich ausgefallen. Die Störung dauerte 6 Tage an, ich hatte eine SIP-Leitung, die nicht so wichtig ist, auf dem bestehenden Registrar gelassen, alle anderen habe ich geändert auf prox04.kabelphone.de. Die FRITZ!Box hatte damit kein Problem und wechselte einfach auf einen der anderen drei Registrars.
Kannst Du Dir das Verhalten erklären? Laut VCM-DNS-Trace macht der LANCOM auch Äuflösungen von prox01.kabelphone.de, prox02.kabelphone.de, prox03.kabelphone.de und prox04.kabelphone.de. Aber er hat dann immer nur die eine der 4 IPs verwendet. Auch wenn er damit überhaupt nicht weiter kam. Warum? Firmware war die 9.24.0231.

Vielen Dank und viele Grüße,
Jirka

[beki]

Hallo Jirka!

> bist Du noch da? Lange nichts mehr von Dir gehört...
Ich bin noch "da", aber nicht wie zuvor. Nachdem ich auf eigenen Wunsch meinen Standort verlagert habe bin ich jetzt nur noch ein gewöhnlicher LANCOM-Fan...

Deinen Post habe ich aufmerksam durchgelesen und war schwer enttäuscht bzw. verwirrt, dass das passieren solle. Dein letzter inhaltlicher Satz "Firmware war die 9.24.0231." hat mich dann schwer aufatmen und grinsen lassen. Wie du inzwischen weißt ist der neue VCM DNS Resolver ab der 10.00 drin. Was in der 9.24 passiert konnte ich kaum durchblicken, auch deshalb ja der Umstutz im VCM DNS Resolver. Also insofern: Ich bin fein raus

Tut mir leid, dass die damit Probleme hattest. Auf Besserung in der 9.24 bzgl. dieses Verhalten würde ich mir an deiner Stelle allerdings nicht machen... Kannst du nicht inzwischen die 10.00 einsetzen?

Gruß,
Bernhard

[Jirka]

Hallo Bernhard,

Ich bin noch "da", aber nicht wie zuvor.

das ist zwar schön, also dass Du noch "da" bist, aber das nicht mehr wie zuvor macht mich traurig. Du verschwindest so schnell (ok, nicht ganz), wie Du gekommen bist. Hättest Du nicht noch ein Jahr bleiben können? Dann wäre der VCM bei LANCOM komplett saniert gewesen. Ich werde Dich vermissen, auch wenn ich erst seit heute Deinen Namen weiß, vorher warst Du nur "Beki". Im anderen Thread steht im Konfigauszug sogar Dein Nachname, ok, ein Buchstabe fehlt. Eh ehrlich, Du gehörst, falsch, gehörtest zu den großen Programmierern bei LANCOM, nämlich denen, die auch mal ins Forum schauen, wie Alfred, Backslash, Georg, Marius, Pothos und die wirklich versuchen zu helfen. Die was auf dem Kasten haben und trotzdem nicht abgehoben sind. Nett fand ich auch Deine Aussage "Guter Punkt, den notiere ich mir!" hier oben im Thread...

Ich habe von Dir nicht tausende Postings gelesen wie von Alfred, Backslash und Georg. Aber die wenigen, die Du hier geschrieben hattest, hatten es in sich. Man hat gemerkt, da ist jemand, der steht hinter der Sache und engagiert sich. Ich möchte an dieser Stelle DANKE sagen. Schade, dass ich meine SIP-Probleme nun nicht mehr bei Dir abladen kann.

Meine Schwester sagt immer wenn sie etwas sucht: Es ist ja nicht weg, es ist nur nicht mehr da. Irgendwo trifft das jetzt auch auf Dich zu...

Auf Besserung in der 9.24 bzgl. dieses Verhalten würde ich mir an deiner Stelle allerdings nicht machen... Kannst du nicht inzwischen die 10.00 einsetzen?

Zunächst mal bin ich mit der 10.00 etwas abwartend. Wie Du vielleicht im Forum gesehen hast, reichen mir vorerst auch die Bugs aus der 9.24 für ausreichend Beschäftigung, da brauche ich nicht noch mehr... Der VCM wäre bisher das einzige echte Argument.
Aber selbst wenn ich wollte, geht das mit der 10.00 nicht. Jedenfalls nicht bei allen Geräten. 1781EF und 1781EW, 1681V - alles noch gute Router für einen Kabel Deutschland Anschluss - bekommen kein LCOS 10.00. Oder sagen wir besser wir bekommen es nicht. Und da sind wir an dem Punkt, den viele vor 2..3 Monaten kommen sahen. Man kann die Geräte entsorgen. Das VoIP-Problem, was ich hier habe und was nachvollziehbar war und ist, wird nicht gelöst werden, auch wenn LANCOM sagt, dass Bugs noch gefixt werden. Na ja, mir war das eigentlich vorher klar, weil ich weiß ja, wie es läuft.

Vielen Dank und viele Grüße,
Jirka

[beki]

Dann wäre der VCM bei LANCOM komplett saniert gewesen.

Nein. In einem weiteren Jahr hätte man viel schaffen können, aber es gab definitiv noch mehr Arbeit als ein Arbeitsjahr...

Aber die wenigen, die Du hier geschrieben hattest, hatten es in sich.

Danke, das freut mich dass jemand schätzt wenn ich versuche gehaltvoll zu posten.

Und danke insgesamt für deine Lobeshymne

Jedenfalls nicht bei allen Geräten.

Ich war auch überrascht von dem Abkündigungsausmaß. Aber gut. Es gibt Gründe. Und LANCOM ist ein eben auch "nur" Business.

Guter Punkt, den notiere ich mir!

Daraus ist wegen Zeitmangels übrigens nichts mehr draus geworden

Was war eigentlich Topic dieses Threads? Achja, DNS-Auflösung Registrar:

Ist jemandem außer mir aufgefallen dass man sip.1und1.de nur noch zu je zwei IP Adressen (zwei für IPv4 und zwei für IPv6) auflösen kann? Da hat sich scheinbar schwer etwas getan. Früher waren das mehr Adressen als in eine DNS Antwort passte, was dem Strict-Mode im VCM zu schaffen machte. Jetzt ist das ganze recht übersichtlich, was auch die Erstellung von SIP Ausnahmeregeln in der IPv6-Firewall erleichtert.