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.
