Anmeldung der Internetrufnummer nicht erfolgreich. Ursache: DNS-Fehler

Fischers Freetz

Mitglied
Mitglied seit
16 Jun 2008
Beiträge
327
Punkte für Reaktionen
1
Punkte
18
Moin!

Auf meiner FB7390 ist u.a. eine Telefonnummer bei einem VoIP-Anbieter eingetragen. Ab und zu kommt es vor, daß an der FB die rote Lampe leuchtet und im Log die oben genannte Fehlermeldung auftaucht. Leider behebt sich dieser Fehler nicht von alleine, ich muss erst über die Web-Oberfläche der FB in die Telefonie-Einstellungen gehen, dort einmal in die Einzelheiten zu der Rufnummer und dieses Menü ohne Änderungen wieder verlassen, damit sich die Box wieder beim Registrar anmeldet.

Welche Möglichkeiten gibt es, diesen manuellen Eingriff überflüssig zu machen? Ich hätte die FB eigentlich für intelligent genug gehalten, daß sie die Verbindung nach einer gewissen Zeit selbstständig wiederherstellt.

Klar kann ich die Box auch einfach neu starten, dann behebt sich der Fehler auch, aber die Wiederanmeldung muss auch geschehen, wenn ich nicht zu Hause bin.
 
Zuletzt bearbeitet:
Die FB muss ja auch nicht intelligenter als der Benutzer sein. Ehrlich gesagt, würde mich das auch sehr beunruhigen...

Soso: Internettelefonie ist also ein untypisches Nutzungsverhalten? Aha... Diese Aussage hätte ich von AVM nicht erwartet. :(

Ich verstehe nur nicht, wieso ein kurzfristiger Ausfall eines Name-Servers die Verbindung zum Registrar stundenlang unterbrechen kann. Zum einen wird der Name des Registrars sehr wohl aufgelöst, während diese Fehlermeldung erscheint, zum anderen reicht ja ein Betreten des Menüs, um die Neuanmeldung zu initiieren.
 
wieso ein kurzfristiger Ausfall eines Name-Servers die Verbindung zum Registrar stundenlang unterbrechen kann.
Gibt es irgendwelche Belege für diese Vermutung, die sie in den Status einer Feststellung erheben könnten?

Erstens sollte es fast unmöglich sein, durch einen Ausfall eines einzelnen Name-Servers eine falsche Antwort zu erhalten. Normalerweise müssen (bei fast allen NICs) wenigstens zwei voneinander unabhängige "authoritative" Server für so eine Domain vorhanden sein, wobei diese Unabhängigkeit soweit geht, daß die IP-Adressen aus verschiedenen AS benutzen sollen (m.W. beim DeNIC sogar müssen), damit ein Ausfalls eines AS sich nicht auf die Auflösung auswirkt.

Wenn jetzt eine Antwort "unbekannter Name" zurückkommt, ist das sicherlich anders zu behandeln als ein Timeout bei der Auflösung eines Namens. Nach letzterem wird i.d.R. auch der zweite/ein anderer Server noch befragt ... hat man bereits die Auskunft "den Host gibt es nicht", macht es auch wenig Sinn, einen weiteren Server zu befragen.

Zum einen wird der Name des Registrars sehr wohl aufgelöst, während diese Fehlermeldung erscheint, zum anderen reicht ja ein Betreten des Menüs, um die Neuanmeldung zu initiieren.
Was ist denn "während diese Fehlermeldung erscheint" genau? Ist das der Zeitpunkt, zu dem die DNS-Abfrage nicht erfolgreich war oder ist es dann, wenn Du Deinerseits bemerkst, daß die SIP-Registrierung nicht erfolgt? Woher weißt Du (wenn das erste zutrifft), welche Antworten auf die DNS-Abfrage zum Zeitpunkt der letzten versuchten Registrierung bei der Box eintrafen?

Wenn nach dem Bestätigen der Einstellungen diese Daten neu übernommen werden (dabei spielt es in den seltensten Fällen eine Rolle, ob die sich tatsächlich von älteren Angaben unterscheiden), ist das ja auch etwas anderes (sieht man notfalls schon im Network-Debugger des Browsers), als wenn man das Formular über "Abbrechen" wieder verläßt. Was heißt denn "ohne Änderungen" hier genau?

Wenn da tatsächlich (aus welchem Grund auch immer, es soll ja sogar immer noch Provider geben, die über DNS-Round-Robin eine Art Lastverteilung versuchen) auf eine DNS-Abfrage hin die Antwort "NXDOMAIN" kommen sollte (also "gibt es als Adresse nicht"), dann finde ich es sogar ausgesprochen sinnvoll, wenn der SIP-Client nicht ständig aufs Neue nach dieser Adresse fragt. Wenn dann so eine Antwort noch eine entsprechende TTL hat (auch für negative Antworten gibt es die Möglichkeit des Cachens - RFC 2308), dann macht es nicht einmal Sinn, diese Abfragen innerhalb der TTL zu wiederholen (der voipd macht ja "eigenes DNS"), wenn ein davor liegender Resolver diese Anfrage aus seinem eigenen Cache beantworten würde.

Ein DNS-Fehler, der sich in einem Ausbleiben einer Antwort äußert, führt sicherlich (man müßte es systematisch testen, um tatsächlich sicher sein zu können, das ist also lediglich eine "Vermutung" auf der Basis bisheriger Beobachtungen) innerhalb angemessener Zeiten zu einer Wiederholung so einer Abfrage ... schon deshalb, weil so ein Problem mangels TTL in der Antwort (es gibt ja gar keine Antwort) wohl kaum sinnvoll zwischengespeichert werden kann. Bei einer tatsächlich negativen Antwort ist aber das gesamte DNS genau darauf ausgelegt, daß nicht ständig erneute Anfragen nach nicht existierenden Adressen auch bis zu den Root-Servern "durchschlagen" ... denn diesen Weg müssen viele Anfragen nehmen, wenn sie direkt an den zuständigen Name-Server (zumindest an einen von mehreren) für eine Domain gerichtet werden sollten.

Wenn jetzt jemand denken sollte: "Hey, dann frage ich doch einfach immer gleich einen Root-Server ab und stelle den bei mir direkt als DNS-Server ein.", dann wird er mit einiger Sicherheit aber enttäuscht werden, denn diese Server lösen in aller Regel nur die TLD auf (also die letzte "Stufe" eines Domainnamens) und weigern sich ansonsten, rekursive Abfragen zu beantworten. Damit macht das Befragen dieser Root-Server auch nur mit einer Software Sinn, die ihrerseits den hierarchischen Aufbau des DNS kennt und tatsächlich auch mehr als eine "A"- oder "AAAA"-Abfrage beherrscht ... denn dazu gehört dann die Auswertung von SOA- und NS-Records genauso und das machen clientseitige Resolver-Libraries in der Regel nicht selbst - es ist auch die "Aufgabe" eines DNS-Servers als "forwarder" oder "resolver".

Um es kurz zu machen ... ich glaube nicht, daß ein Ausfall eines DNS-Servers das Problem verursacht. Liefert irgendein DNS-Server die Antwort "unbekannte Adresse" zurück, halte ich es für vollkommen normal, wenn bis zur Überprüfung/Bestätigung durch den Benutzer diese Adresse nicht erneut verwendet wird ... denn es wäre eindeutig ein Fehler des verantwortlichen Domain-Servers, wenn so eine Antwort gegeben wird, obwohl sie falsch ist. Die Alternative wäre ein absichtlicher "Störer", der solche Abfragen gar nicht nach bestem Wissen und Gewissen beantwortet ... daher muß/sollte man so etwas auch genau untersuchen.

Ich will keinem Provider etwas unterstellen ... aber wenn ich jede dritte Abfrage nach dem SIP-Server eines alternativen Anbieters in meinem DNS-Server (den die meisten Kunden sicherlich als Forwarder verwenden) falsch beantworte (und die CPEs das nicht entsprechend protokollieren - viele Cache-Implementierungen speichern zwar das Ergebnis, aber nicht unbedingt den antwortenden Server auch noch) und einfach behaupte, ich hätte diese Information von einem anderen DNS-Server in der Hierarchie erhalten, dann wird das ohne meine Mithilfe (man müßte ja dazu überwachen, daß an meinen Gateways tatsächlich keine DNS-Abfragen durchlaufen, die von anderen Servern solche Antworten liefern könnten und das dürfte ausschließlich "extern" recht kompliziert werden) auch niemand so schnell aufdecken und trotzdem verleidet es dem Kunden die Benutzung solcher alternativer SIP-Anbieter gründlich. Ich wüßte jetzt auch kein Gerät "von der Stange", wo direkt für einen SIP-Account ein DNS-Server konfiguriert wird ... mag es aber auch geben.

Wobei ich gerade auch nicht mehr genau weiß, ob der voipd für die DNS-Abfrage (bei Existenz eines dedizierten Interfaces für "voip") die Einstellung "sipiface" auch zur Ermittlung des zuständigen DNS-Servers heranzieht oder ob da immer der DNS-Server für das zweite Interface befragt wird. Kriegt man aber leicht heraus, wenn man einfach mal "Anmeldung immer über eine Internet-Verbindung" umschaltet und sich dann ansieht, welche Auswirkungen das auf die DNS-Abfragen für den Namen des Registrars hat.

Um zum Schluß auch noch auf die Frage einzugehen, was man da machen könnte ... wenn das öfter auftritt, würde ich mir ein Skript bauen, was die Registrierung zyklisch abfragt und nach einer gewissen Karenzzeit (die falschen DNS-Antworten müssen ja auch erst einmal verdaut werden im Cache) den SIP-Account einmal kurz deaktiviert und anschließend wieder aktiviert. So ein Skript dürfte auch die einzige halbwegs realistische Möglichkeit sein, dem eigentlichen DNS-Problem (das andere ist ja nur ein Workaround) auf die Spur zu kommen ... wenn man unmittelbar nach dem Registrierungsproblem die Adresse noch einmal abfragt, sollte selbst bei einer TTL von einer Minute ja noch eine Antwort im Cache vorliegen und die muß man dann halt erst einmal protokollieren. Solange man das nicht getan hat, sind alle Mutmaßungen über die denkbaren DNS-Ursachen nur vertane Zeit ... selbst ein "SERVFAIL" darf theoretisch bis zu 5 Minuten gecacht werden, wenn man dem o.a. RFC folgt (aber auch das kommt dann von einem DNS-Server irgendwo in der Kette und ist nicht das Ergebnis einer ausbleibenden Antwort). Für eine halbwegs verläßliche Lösung, die erst dann das Deaktivieren/Aktivieren des SIP-Accounts ausführt, wenn die DNS-Abfrage nicht mehr aus dem Cache beantwortet wird, bräuchte man so eine zusätzliche DNS-Abfrage im erwähnten Skript ohnehin.
 
Zuletzt bearbeitet:
Falls die Fehlermeldung "DNS-Fehler" ernst zu nehmen ist und nicht irgend ein anderes Problem voraus geht, müsste doch die Lösung sein, den Registrar-Namen durch die IP-Adresse zu ersetzen, also z.B. "sipgate.de" durch "217.10.79.9" zu ersetzen.
 
Zuletzt bearbeitet:
Im Log der FB stehen zwischen 13 und 17 jeweils Dutzende dieser beiden Meldungen:

Code:
26.07.16 16:49:22 Anmeldung der Internetrufnummer xxxxx war nicht erfolgreich. Ursache: DNS-Fehler [151 Meldungen seit 26.07.16 16:24:18]
26.07.16 16:24:14 Die Rufnummer xxxxx ist seit mehr als einer Stunde nicht verfügbar.
Bevor Nachfragen kommen: da steht natürlich nicht "xxxx", sondern die Nummer der Anmeldung beim VoIP-Anbieter.

DNS-Fehler kann heißen: der Nameserver selber ist ausgefallen oder er ist nicht erreichbar. Beides wäre aus Sicht der FB aber derselbe Status, nämlich "ausgefallen". Ein solcher Ausfall kann natürlich jederzeit passieren, mögliche Ursachen gibt es genug. Die Frage ist nur, warum das System der FB bzw der SIP-Client nicht von sich aus nach einer gewissen Zeit versucht, die Verbindung wieder aufzubauen.

"Noch während dieser Fehlermeldung" heißt: noch während die rote Lampe leuchtet und die FB schreit, daß die Nummer nicht zur Verfügung steht und die Meldung "DNS-Fehler" weiter im Log auftaucht, kann ich auf der Konsole aber bereits ein nslookup auf durchführen, und erhalte sofort die IP des Registrar. Die Meldung über einen DNS-Fehler ist so nicht korrekt.

Falls die Fehlermeldung "DNS-Fehler" ernst zu nehmen ist und nicht irgend ein anderes Problem voraus geht, müsste doch die Lösung sein, den Registrar-Namen durch den FQDN zu ersetzen, also z.B. "sipgate.de" durch "217.10.79.9" zu ersetzen.

Das ist die beste Idee bisher zu diesem Problem. ;)
 
Da irrst Du meines Erachtens ... DNS-Fehler kann genauso gut heißen, daß der Name eben nicht gefunden wird (zumindest nicht vom Forwarder) und warum das ein anderes Problem ist als ein nicht antwortender DNS-Server, habe ich versucht zu erklären. Keine Antwort ist etwas anderes als eine negative Antwort - da beißt die Maus nun mal keinen Faden ab und ein nicht erreichbarer oder ausgefallener Server kann selbst auch keine negative Antwort erzeugen. Gebe ich einen ungültigen SIP-Server an, erhalte ich genauso einen "DNS-Fehler" beim Versuch der Anmeldung der Rufnummer. Da finde ich absolut keinen Fehlercode, der irgendwelche Rückschlüsse auf die Natur dieses Fehlers zuließe.

Wenn Du auch noch bei Deinem Test von der Konsole berücksichtigst, daß der voipd seine eigenen Abfragen macht (i.d.R. vom Port 7077) und diese sogar eigenen QoS-Regeln folgen, dann ist die Aussagekraft des eigenen Tests für den Zeitpunkt dieses Tests sogar vorhanden (ansonsten kann da eben noch alles mögliche schieflaufen) - zur tatsächlichen Validierung müßte man also sowohl vom Port 7077 aus fragen und dann definitiv auch noch den richtigen Name-Server. Wenn in #1 etwas steht, daß es "u.a. auch einen sipgate-Account" gibt, dann läge die Vermutung nahe, daß es andere Accounts vom Provider gibt und da kann schon die Telefonie ein gesondertes (virtuelles) Interface verwenden - das sind alles Unbekannte in dieser Gleichung.

Die Fehlermeldung wird jedenfalls über den (schon älteren, aber für diese Zwecke in der 06.5x aufgehübschten) "boxnotifyd" verwaltet und solange eine dort getriggerte Meldung (und der Ausfall einer SIP-Nummer ist ja nicht die einzige denkbare Meldung, die anderen habe ich irgendwann vor einem Jahr schon mal aufgedröselt) nicht quittiert ist (und das wird sie erst bei der Anzeige), bleibt die rote LED erhalten und es erscheint bereits in der Login-Seite die entsprechende Meldung. Das will Dir also gar nicht anzeigen, daß die DNS-Auflösung zum aktuellen Zeitpunkt nicht funktioniert - dafür ist dann wieder die Fehlermeldung im Eventlog zuständig, denn die Meldung und die rote LED erscheinen erst nach einiger Zeit, in der dieses Problem fortbestehen muß und nicht bei einem "temporären Problem".

Wobei die Anzeige im Eventlog dann ja deutlich zeigt (entgegen Deiner Vermutung, es würde gar nichts mehr passieren), daß die Box ständig aufs Neue versucht, die Nummer zu registrieren ... wenn innerhalb von 25 Minuten 151 Meldungen ausgegeben werden, dann ist das eine Meldung alle 10 Sekunden (über den Daumen).

Entweder da wird die DNS-Auflösung nicht erneut probiert und tatsächlich auf ein gecachtes Ergebnis zurückgegriffen (und sei es irgendwo beim Resolver-Server, während die Box noch ganz brav ihrerseits fragt) oder es kommt eben unentwegt ein Fehler zurück.

Wenn das tatsächlich ein Fehler innerhalb dieser 10 Sekunden ist, dann ist das mit einiger Wahrscheinlichkeit auch kein Timeout einer Abfrage ... selbst wenn DNS-Server heutzutage eher schnell sind, sind 10 Sekunden für ein Timeout doch etwas mager - aber auch das läßt sich ja durch Angabe der IP-Adresse eines beliebigen Servers ohne einen Name-Server anstelle eines DNS-Servers in den IP-Einstellungen der Box leicht feststellen, wie lange sie da auf eine ausbleibende Antwort wartet (der Server darf dann natürlich kein ICMP senden, daß der Port zu ist ... das ist dann sofort ein "SERVFAIL").

Wenn da ein Fehler als Antwort kommt, findet man das nun mal auch am ehesten in einem Mitschnitt ... fehlt da schon die Frage aus der Box, ist wohl intern etwas beim DNS-Abfragen durch den voipd im Argen. Solltest Du tatsächlich auf die Suche nach diesen DNS-Abfragen in einem Packet-Dump gehen, mußt Du trotzdem berücksichtigen, daß das keine "normalen Requests" sind und sie deshalb leicht zu finden sind. Selbst wenn sie an Port 53 gehen, sollten sie auch alle von Port 7077 kommen, solange die Standardeinstellungen nicht durch irgendwelche anderen SIP-Accounts geändert wurden, denn die gelten für alle Nummern - dnsport im Abschnitt voipcfg der voip.cfg.

Den Zusammenhang zwischen der Angabe einer IP-Adresse und eines FQDN (fully qualified domain name) verstehe ich aber auch nicht ... der Name des Servers beim Registrar ist doch gerade ein FQDN - wie sollte der sich selbst jetzt ersetzen? Was ist daran so eine gute Idee?

Sollte bei der sipgate-Nummer nicht die "Anmeldung immer über eine Internetverbindung" aktiviert sein, wäre das ggf. noch einen Test wert ... mit etwas Glück verwendet der voipd dann tatsächlich denselben DNS-Server wie eine Shell-Session (ich nehme mal an, daß damit eine solche auf der FRITZ!Box gemeint war) und wenn der die Adresse auflösen kann, dann könnte ja auch die Anmeldung wieder funktionieren, wenn die Box alle 10 Sekunden einen neuen Versuch startet.

Was man vielleicht auch noch beachten muß (deshalb ja mein Hinweis im letzten Beitrag) ... die DNS-Abfragen des voipd gehen an einen der vom Provider gesetzten DNS-Server - unabhängig davon, was man bei "DNS-Server" bei "Zugangsdaten" eingestellt haben mag. Da das bei den meisten Providern auch deren eigene Server sind, ist es gerade bei einem Provider mit einem virtuellen Interface für "voip" (was dann auch eigene DNS-Server haben kann) nicht gerade unüblich, daß die nicht jede x-beliebige Abfrage auch (korrekt) beantworten - es kann sich im Extremfall sogar um Server handeln (das war bei KDG bisher so), die nur die interne Telefonie des Providers unterstützen. Ob das hier der Fall sein könnte, kann man mangels Kenntnis des Providers (und so ziemlich jedes Details der Konfiguration) ja auch nur raten.
 
Wenn ich mich recht erinnere, ist die Fritzbox an einem Kabelrouter von unitymedia angeschlossen. Deshalb habe ich im zweiten Beitrag oben schon darauf hingewiesen, dass der Fehler vermutlich in der Anschlussart der Fritzbox begründet ist. Der Verdacht, dass der interne DNS des Providers nach dem Registrar von sipgate befragt wird, ist also nicht ganz von der Hand zu weisen.
 
Den Zusammenhang zwischen der Angabe einer IP-Adresse und eines FQDN (fully qualified domain name) verstehe ich aber auch nicht ... der Name des Servers beim Registrar ist doch gerade ein FQDN - wie sollte der sich selbst jetzt ersetzen? Was ist daran so eine gute Idee?
Wurde gestern bereits korrigiert. Muss "IP-Adresse" statt "FQDN" heißen.
Also:
Falls die Fehlermeldung "DNS-Fehler" ernst zu nehmen ist und nicht irgend ein anderes Problem voraus geht, müsste doch die Lösung sein, den Registrar-Namen durch die IP-Adresse zu ersetzen, also z.B. "sipgate.de" durch "217.10.79.9" zu ersetzen.
 
@henry90:
Dann stimmt es jetzt ja (ich bezog mich auch auf das Zitat von Fischers Freetz, weil ich mir schon darüber im Klaren war, daß es bei Dir nur ein Schreibfehler sein könnte - ich frage ja auch im Ergebnis mehr in die Richtung, warum das "die beste Idee" bis dort war) ... ich würde trotzdem einen solchen Workaround nicht empfehlen, weil die meisten Provider schon ab und an mal die Adressen wechseln oder einen weiteren SIP-Server einführen, wenn ausgebaut werden muß, usw.

Es ist ja auch nicht so, daß eine FRITZ!Box das bei passender Konfiguration so gar nicht mit dem FQDN auflösen kann ... dann hätte ja jeder sipgate.de-Kunde Probleme, die Registrierung seiner Nummer(n) in einer FRITZ!Box am Leben zu erhalten (und die wenigsten Telefonie-Kunden werden ihren DSL-Anschluß auch bei sipgate.de haben).


-Der FRITZ!Box-Daemon sucht nebenbei bemerkt bei der 113.06.60 in der folgenden Reihenfolge, falls das mal jemand als Referenz braucht (Provider Telekom Business mit fester IP, aber mit SIP-Account außerhalb der Telekom-Strukturen):

1. NAPTR-Record für den FQDN des angegebenen Registrars

2. SRV-Record für _sip._udp am FQDN des angegebenen Registrars (und auch nur "_udp")

3. A- und AAAA-Records für den FQDN des angegebenen Registrars

Führt eine der Aktionen vor 3. bereits zum Ergebnis, findet eine direkte Abfrage des A-Eintrags gar nicht statt. Da ja jede der beiden Abfragen davor auch einen vollkommen anderen FQDN für den endgültigen Host ergeben kann (dafür sind diese Einträge ja gedacht), ist also eine "händische" Abfrage über "nslookup" oder "dig" nur bedingt aussagekräftig, was die Erreichbarkeit und Funktionsfähigkeit von DNS-Einträgen angeht.

Wenn der Registrar z.B. nur als "sipgate.de" angegeben wird und es gibt den Eintrag "_sip._udp.sipgate.de", der auf einen konkreten Servernamen "sip030.sipgate.de" verweist, muß die Abfrage eines A-Records für "sipgate.de" noch lange kein sinnvolles (und schon gar nicht dasselbe) Ergebnis erbringen.
 
Lieber Bauern-Peter, danke für die ausführlichen Erläuterungen!

Mir war zum einen nicht bewusst, daß die SIP-Anwendung (oder VoIPd) einen eigenen Port für DNS-Anfragen benutzt. Ich habe einfach auf meinen Arbeitsrechner, im selben Netz wie die FB und den selben DNS benutzend, die Namensanfrage natürlich ohne Port-Angabe gestellt, und war überrascht, daß ich einen FQDN zurückbekomme, während die FB noch Mord und Zeter schreit.

Da weder mein eigener DNS, den die FB und mein Rechner benutzen, noch dessen Forwarder, noch der DNs des Kabelanbieters auf Port 7077 antworten, muss es sich also Deiner Erklärung nach um einen externen Server handeln, der wahrscheinlich fest vorgegeben ist.

KunterBunter: Ja, die Box ist als einfacher IP-Client in meinem Netz eingerichtet, sie stellt selber keine Internetverbindung her. Das sollte aber für die VoIP-Verbindung keinen Unterschied machen.

Die Option "Anmeldung immer über eine Internetverbindung" ist übrigens aktiviert.
 
Das Mißverständnis ist hier, daß die DNS-Abfragen natürlich an den ganz normalen DNS-Port (UDP/53) gehen ... sie kommen nur von einem festen Port, sind somit "identifizierbar" und es gibt eben sogar eigene QoS-Regeln für diesen Traffic.

Trotzdem kann es natürlich sein, daß unterschiedliche DNS-Server für das "normale Interface" (internet) und für ein gesondertes SIP-Interface (heißt dann i.d.R. "voip") existieren ... aber das steht wieder in den Support-Daten.
 
Zuletzt bearbeitet:
In Ordnung, Missverständnis geklärt.

Habe gerade noch mal nachgesehen: es gibt auf dem DNS keine Regel, die den Zugriff von Port 7077 eines Client ablehnt oder verbietet. Kann auch nicht wirklich sein, denn dann müsste der DNS-Fehler permanent auftreten.
 
Wenn die Box IP-Client ist, kann sie ja auch schlecht den DNS-Server aus einer PPPoE-Sitzung vom Provider verwenden ... damit müßte es ja nun eigentlich noch viel leichter sein, die DNS-Abfragen der FRITZ!Box abzufangen und zu untersuchen. Sie wird ja sicherlich nicht direkt einen DNS-Server beim Provider befragen ... ein lokaler DNS-Forwarder oder -Proxy wäre die näherliegende Variante hier. Auf dem müßte man doch aber problemlos feststellen können, wann da welche DNS-Abfragen stattfinden und - viel wichtiger - was deren Ergebnis ist.

Die wiederholten Registrierungsversuche im Abstand von 10 Sekunden werden sich ja sicherlich nicht geändert haben ... hier hat AVM m.E. ohnehin noch Nachholbedarf, weil es ziemlich sinnlos ist, bei nicht erfolgreicher Auflösung des SIP-Registrars alle 10 Sekunden einen neuen Versuch des voipd zu starten.

So stellt sich das jedenfalls bei mir dar, wenn ich absichtlich einen falschen Registrar angebe, der nicht existiert. Eine solche DNS-Abfrage wird offensichtlich innerhalb der "minimum TTL" der negativen Antwort gar nicht erneut ausgeführt (das sind bei mir schon ungewöhnlich kurze 900 Sekunden), das hindert den voipd aber nicht daran, schön brav im 10 Sekunden-Rhythmus weiterhin seine Fehler zu protokollieren. Zwar wird nicht jede einzelne Zeile auch im Eventlog angezeigt, aber die Zahl der durchlaufenden Nachrichten wird trotzdem verdoppelt, weil nach jeder anderen Nachricht die Zählung und Zusammenfassung erneut beginnt.

Wenn aber schon bekannt ist, daß der Registrar nicht existiert, muß man sicherlich auch nicht ständig neue Anläufe unternehmen, die betreffende Nummer zu registrieren, solange sich die Einstellungen nicht geändert haben bzw. der Name nicht erneut abgefragt wurde (und nicht aus irgendeinem Cache kommt, was man anhand der verbleibenden TTL ja leicht feststellen kann). Dieses Verhalten hatte ich tatsächlich erwartet, weil das andere (zumindest in meinen Augen) einfach nur Unfug ist. Wenn die Eingangsbedingungen stabil sind, kann man kaum ein abweichendes Ergebnis erwarten.
 
Sie wird ja sicherlich nicht direkt einen DNS-Server beim Provider befragen ...

Könnte sie auch gar nicht, weil sie den eigentlich gar nicht kennen kann. Es sei denn, die Programmierer der VoIP-Anwendung sprechen immer die IP x.x.x.1 zur Namensauflösung an, weil das in den *meisten* Netzwerken das Gateway ist und auch als lokaler DNS-Forwarder dient. Obwohl auf der FB ein anderen primärer DNS im internen Netzwerk eingetragen ist, würde das auch in meinem Fall funktionieren, da das Gateway/Modem des Anbieter die "Nummer 1" im Netzwerk darstellt.

ein lokaler DNS-Forwarder oder -Proxy wäre die näherliegende Variante hier. Auf dem müßte man doch aber problemlos feststellen können, wann da welche DNS-Abfragen stattfinden und - viel wichtiger - was deren Ergebnis ist.

Prinzipiell richtig, aber der Router, auf dem der DNS läuft, hat leider zu wenig Speicher, um Logs zu führen. :(

Wenn aber schon bekannt ist, daß der Registrar nicht existiert, muß man sicherlich auch nicht ständig neue Anläufe unternehmen, die betreffende Nummer zu registrieren,

So, wie ich das sehe, ist der Registrar aber existent, wenn die FB sagt, er sei es nicht, denn ich kann ihn während die FB rot leuchtet, namentlich auflösen und anpingen.

So ganz habe ich Deine Ausführungen noch nicht verstanden, denn für mich ergibt es immer noch keinen Sinn, daß die FB beim (angeblichen) DNS-Fehler diese "Krise" nicht alleine bewältigen kann, sondern daß sie es erst dann tut, wenn ich das Menü der SIP-Verbindung aufrufe und ohne Änderung wieder verlasse. Wenn das Verlassen dieses Menüs einen Trigger auslöst, warum kann das OS diesen Trigger nicht einfach ein paar Minuten nach dem ersten DNS-Fehler selbstständig aufrufen?

Ich werde jetzt einfach erstmal das nächste Auftreten des Fehlers abwarten und dann auf der Leitung schnüffeln, was die FB da so anstellt, mit welchem Server sie in Kontakt tritt oder es versucht. Mal schauen, ob ich etwas herausfinden kann.
 
Ich wollte gestern den Nachtrag nicht noch zusätzlich anbringen, daß der "voipd" sich offenbar doch nur "am Rande" um die TTL-Angaben schert - die Abfrage des Name-Servers wurde in meinem Trace dann doch alle 300 Sekunden wiederholt.

Das ändert zwar an meiner Feststellung/Behauptung bzgl. der Sinnlosigkeit des Tuns des "voipd" bei einem offensichtlichen Fehler in der Angabe des SIP-Registrars wenig, aber wenn sich ein vorgelagerter DNS-Server im Cache die negative Antwort (wenn es bei Dir überhaupt ein NXDOMAIN ist, bei meinem Testaufbau ist es definitiv (absichtlich) eine solche Antwort) nach den geltenden Regeln (in Gestalt von RFCs) merken sollte, dann hilft natürlich auch ein 300 Sekunden-Intervall bei der DNS-Abfrage nicht wirklich.

Zumindest könnte man anhand der TTL-Angabe in der Antwort ja feststellen, wann die nächste Abfrage wieder Sinn machen könnte - solange man keinen Neustart des Resolvers "unterstellt", wird die ständige Nachfrage auch immer dasselbe Ergebnis erbringen (und das auch ohne eine erneute Abfrage eines NS für die Domain).
 
Und der fragt sich dann selbst rekursiv von den Root-Servern aus durch?
 
Nein, natürlich nicht. Es wird OpenDNS benutzt. In der Zwischenzeit habe ich erstmal die nötigen IP (Plural) und Rechnernamen des VoIP-Anbieters im DNS selber direkt eingetragen. Damit sollten negative Antworten auf alle Fälle vermieden werden.

- - - Aktualisiert - - -

Heute ist es wieder passiert. :(

Aber jetzt bin ich mir sicher, daß der Fehler, den die FB moniert, gar nichts mit DNS zu tun haben kann, denn ich habe die Server (2) des VoIP-Anbieters in /etc/hosts des internen Nameserver eingetragen, er löst sie also jetzt selber auf, anstatt weiterzuleiten, und ich habe trotz des knappen Speichers das Log aktiviert und darin steht, daß der Nameserver die Anfragen der FB direkt aus der Datei /etc/hosts beantwortet.

Gleichzeitig kann es auch nichts mit der Erreichbarkeit der SIP-Server zu tun haben, denn, wie schon mehrfach gesagt, reicht ein einfaches Betreten und Verlassen des Menüs in den Einstellungen der FB, und die VoIP-Nummer wird wieder aktiviert.

Als nächste Änderung habe ich jetzt für alle Anfragen nach Rechnern aus der Domäne des VoIP-Anbieters eine Weiterleitung direkt an den Nameserver meines Kabelanbieters geschaltet, so daß auch Anfragen nach Rechnernamen mit "_sip._udp." am Anfang nicht mehr von meinem Nameserver bearbeitet werden. Mal sehen, was jetzt passiert.

Mich beschleicht das Gefühl, daß der auftretende Fehler von der FB an ganz anderer Stelle zu suchen ist, und die FB nur fälschlicherweise etwas mit "DNS-Fehler" ausgibt.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.