[Problem] DNS-Probleme bei SIP-Anmeldung an fritz.box

koyaanisqatsi

IPPF-Urgestein
Mitglied seit
24 Jan 2013
Beiträge
12,504
Punkte für Reaktionen
323
Punkte
83
Jetzt wird mir auch klar, warum im Softphone auf Android der Registrar/Proxy...
Screenshot_2016-11-18-11-01-50.png
fritz.box
...keine gute Idee ist und fehlschlagen kann/muss.
 

Theo Tintensich

Aktives Mitglied
Mitglied seit
10 Mrz 2008
Beiträge
1,739
Punkte für Reaktionen
47
Punkte
48
Die FritzBox liefert für "*.fritz.box.fritz.box" nicht "not found: 3(NXDOMAIN)", sondern "* has address 127.0.53.53":
Die F!B kommen wohl durcheinander, wenn kein Punkt am Ende hängt.
Dann leiten sie das zum DNS von dot.box, und das Ergebnis wird dann mit "127.0.53.53 doppelte Verwendung der TLD" beantwortet.

Wenn man "fritz.box.", mit schließendem Punkt angibt, weiß der DNS-Clinet und der Server, dass der Name vollständig ist, und nicht noch die unter "Search" in der "resolve.conf" oder beim Windows unter "Netzwerkinterface => IPv4 => Erweitert => DNS => die DNS-Suffixe anhängen" anhängen soll.
(Bzw die per DHCP knfigurierten)
 

sf3978

IPPF-Promi
Mitglied seit
2 Dez 2007
Beiträge
7,845
Punkte für Reaktionen
14
Punkte
38
Die F!B kommen wohl durcheinander, wenn kein Punkt am Ende hängt.
Naja, ich denke es sind eher die Clients (... wie Du bereits gschrieben hast), die "durcheinander kommen" und nicht die FritzBox:
Code:
:~ $ nslookup fritz.box 192.168.178.1
Server:		192.168.178.1
Address:	192.168.178.1#53

Name:	fritz.box
Address: 192.168.178.1
Code:
:~ $ nslookup fritz.box.fritz.box 192.168.178.1
Server:		192.168.178.1
Address:	192.168.178.1#53

Non-authoritative answer:
Name:	fritz.box.fritz.box
Address: 127.0.53.53
Die Frage ist m. E. doch die, warum wird "fritz.box.fritz.box" von der FritzBox so aufgelöst (siehe oben)?
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,090
Punkte für Reaktionen
997
Punkte
113
Die FritzBox liefert für "*.fritz.box.fritz.box" nicht "not found: 3(NXDOMAIN)", sondern "* has address 127.0.53.53":
Genau danach habe ich längere Zeit gesucht mit diversen Kombinationen, die ich aus der Beschreibung von @sunnyman gebildet habe.

Wenn das bei ihm auch die Ursache sein sollte, wäre die "normale" Resolver-Konfiguration aber auch geändert oder mir ist der Weg dorthin immer noch unklar. Unter Linux (MacOS X weiß ich es nicht genau) ist der Standard "option ndots:1" ... damit wird jeder Name mit einem Punkt (und das meint nicht nur den am Ende für die Anzeige "absolute Abfrage" anstelle von "unqualified domain name") als absolute Abfrage gesendet. Auf welchem Weg kommen jetzt das Ubuntu- bzw. das Raspbian-System zu einer Abfrage nach "...fritz.box.fritz.box"? Und nicht als "nslookup" oder "dig", sondern aus der Funktion, die normalerweise hinter einem "gethostbyname()" (auch wenn die "älter" ist) am Wirken ist?

Bei jedem Protokoll, wo es nur auf die richtige IP-Adresse am Ende ankommt, könnte man auch anstelle von "fritz.box" künftig einfach "www" abfragen, wenn die Suchdomain "fritz.box" aktiviert ist. Dann wird daraus der Name "www.fritz.box", der auf die IP-Adresse der Box zeigt.

Bei SIP kann das trotzdem problematisch werden, denn dort ist eben das "fritz.box" in "[email protected]" gleichzeitig Teil der Identität, mit der sich ein SIP-Client anmelden will. Wenn der daraus "[email protected]" macht, ist das wieder etwas anderes ... bei "[email protected]" würde ich (ohne es getestet zu haben) eher darauf tippen, daß die FRITZ!Box diese Identität beim SIP-REGISTER ablehnt. Hat das schon mal jemand von den Betroffenen probiert?
 

sf3978

IPPF-Promi
Mitglied seit
2 Dez 2007
Beiträge
7,845
Punkte für Reaktionen
14
Punkte
38
Auf welchem Weg kommen jetzt das Ubuntu- bzw. das Raspbian-System zu einer Abfrage nach "...fritz.box.fritz.box"?
Der dns-Client (Dienst) macht nach einer 1. Antwort, die "NXDomain" beinhaltet, noch eine 2. Anfrage. Wenn jetzt in der resolv.conf (oder gleichwertig) "search fritz.box" konfiguriert/eingetragen ist, dann wird "fritz.box" angehängt. So kommt dann eine Namensauflösung für "*.fritz.box.fritz.box" zustande.

EDIT:

Mit einer alten FB7170 hätte man dieses Problem nicht. Z. B.:
Code:
:~$ host -t A fritz.box 192.168.188.1
Using domain server:
Name: 192.168.188.1
Address: 192.168.188.1#53
Aliases: 

fritz.box has address 192.168.188.1
Code:
:~$ host -t A fritz.box.fritz.box 192.168.188.1
Using domain server:
Name: 192.168.188.1
Address: 192.168.188.1#53
Aliases: 

fritz.box.fritz.box has no A record
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,090
Punkte für Reaktionen
997
Punkte
113
Stimmt ... am Ende steht das sogar in der "resolv.conf"-Manpage, wenn man denn nur mal auch genau liest (was ich wohl versäumt habe):
option ndots:n
Sets a threshold for the number of dots which must
appear in a name given to res_query(3) (see
resolver(3)) before an initial absolute query will be
made. The default for n is 1, meaning that if there
are any dots in a name, the name will be tried first as
an absolute name before any search list elements are
appended to it.
The value for this option is silently
capped to 15.
Die Arbeitsweise der Libraries bei einer Namensauflösung ist tatsächlich nicht einmal Bestandteil des POSIX-Standards, der hört bei "getaddrinfo()" schon auf und verweist nur noch darauf, daß das üblicherweise auf DNS zurückgreift bei der Auflösung eines Namens. Weiter ist das Vorgehen gar nicht standardisiert.

Dann kommt bei Jitsi wohl noch hinzu, daß dort ja vermutlich sogar eigene "richtige" DNS-Abfragen nach verschiedenen Typen von Einträgen gemacht werden und da wird wohl der Code dann ebenfalls eine vorhandene Suchdomain noch anhängen nach einem NXDOMAIN (ob das logisch und sinnvoll ist, will ich gar nicht beurteilen). Dann liefert die Abfrage nach "_sip._tcp.fritz.box.fritz.box." mit SRV-Typ eben seit dem 11.11. kein NXDOMAIN mehr und damit kommt an dieser Stelle die Auflösung zum Stehen, wo sie vorher dann noch bis zum Abfragen von A/AAAA-Records weitermachte.

Manchmal bin ich so was von froh, daß ich es mir irgendwann mal angewöhnt habe, bei solchen Abfragen mit "nslookup" oder "dig" schon automatisch einen Punkt an das Ende des gesuchten Namens zu setzen - das spart die zusätzliche Angabe von Optionen (zumal der Standard bei "dig" auch noch "nosearch" ist und bei "nslookup" ist es "search", bei "host" ebenfalls, da kann man "ndots" aber noch dynamisch festlegen), wenn man die konfigurierten Suchdomains nicht einbeziehen will, was ja bei derartigen gezielten Abfragen eher selten der Fall ist (es sei denn, man will eigentlich die lokale Auflösung testen).

Andererseits ist so ein Punkt schnell überlesen und auf die Idee, daß da bei @sunnyman eine Suchdomain "fritz.box" konfiguriert sein könnte, bin ich anfangs gar nicht gekommen, weil das auch nirgendwo stand. Die kommt dann ja vermutlich auch über den DHCP-Server auf die Clients, sonst hätte er es sicherlich erwähnt, wenn er es explizit einträgt.

Also ist es am Ende dann doch ein Fehler in der Implementierung von AVM - es geht ja auch bereits bei "fritz.box.fritz.box" los mit einer externen Abfrage und zwar unabhängig vom Typ der angefragten Einträge, soweit ich das feststellen konnte. Dasselbe trifft auch auf die Domain "myfritz.box" zu, die ja ebenfalls intern verwendet wird. Egal, wo man das "fritz" gegen "myfritz" austauscht, der Effekt ist immer derselbe. Das gilt sogar noch für alle in der FRITZ!Box-DNS-Konfiguration erzeugten Einträge ... wer einen Host "client" im Netz hat und den einfach mit "ping client" ansprechen kann, sollte auch auf "nslookup fritz.box.client.fritz.box." wieder die 127.0.53.53 erhalten.

OT: Wenn man das als Fehler mal "rückwärts" aufrollt und an die Zeit vor dem 11.11. denkt, würde mich mal interessieren, was man alles hätte erreichen können, wenn ein Host im LAN der FRITZ!Box von sich behauptet, er hieße "de". Das läßt sich aber nun nur noch mit einem eigenen "richtigen" DNS-Server testen, der sich selbst als SOA für "box" ansieht. Aber irgendwo habe ich noch im Hinterkopf, daß es zumindest mal einige Browser gab, die schon bei der Eingabe einer noch unvollständigen Adresse mit der Suche nach dem passenden Host loslegten und dafür eine vorkonfigurierte Liste von gTLDs benutzten. Ob sich das in Kombination mit der Suche mit und ohne "fritz.box" am Ende zu irgendetwas verwertbarem für eine falsche Auskunft zu einer "de"-Domain benutzen ließe, wäre ja mal interessant gewesen.


Das von mir bereits als vorhanden vermutete "blacklisting" für den Namen "wpad" ist aber auch in der 41986 dann doch noch nicht umgesetzt ... es dauerte nur ein wenig länger, bis der Eintrag für "wpad" nach dem Start des avahi-Daemons in der FRITZ!Box sichtbar wurde (der läuft nicht ständig und dient nur zum Test oder zum Ausnutzen dieser Lücke).

Warum ich bei mir das Problem von @sunnyman partout nicht nachstellen konnte, obwohl ich dann extra "fritz.box" doch noch als Suchdomain hinzugefügt hatte, ist mir inzwischen auch klar:
The search list is currently limited to six domains with a total of 256 characters.
Weil ich die "offizielle" Domain auch daheim in Subdomains untergliedert habe (vpn, wlan, dmz, dynamic, home), habe ich zusammen mit dem Eintrag für "keine Subdomain" (so daß auch eine Suche nach "fb7490.dmz" funktioniert, weil ich "ndots:2" gesetzt habe) bereits die erwähnten sechs Suchdomains (die aber alle der interne NS auch als SOA behandelt und vom externen (primary) NS repliziert) in Benutzung und es ist mir selbst auch nicht so richtig aufgefallen, daß da niemals das "fritz.box" als Suchdomain verwendet wurde; das wird leider auch still ignoriert und wirft keinen Fehler, wenn da mehr als sechs Einträge stehen.