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

[sunnyman]

Hallo Forum,

seit dem 11.11. habe ich Probleme mit dem Zugriff auf die Fritzbox. Ich kann mich nicht mehr mit einem SIP-Client an der Fritzbox registrieren unter Verwendung des Hostnamens (fritz.box, so wie im Konfig.-Interface angegeben).

Über den Browser und ping erreiche ich mit "fritz.box" die Fritzbox und bekomme auch ihre korrekte IP-Adresse, nicht aber bei SIP-Verbindungsversuchen. Probiert habe ich es mit 3 Rechnern. Dann wird der Host zu 127.0.53.53 aufgelöst.
Das passiert offenbar dann wenn ein Domainname genutzt wird, der bald im öffentlichen Raum benutzt werden soll.

Da das Problem bei 3 verschiedenen Rechnern mit 2 verschiedenen SIP-Clients (Jitsi, Asterisk) passiert, frage ich mich, ob da ein Problem bei der Fritzbox vorliegt oder ein Update beim DNS-Server des Internetproviders dazu geführt hat?

 

[Joe_57]

...und alle hier im Forum dürfen jetzt mal raten, welche FritzBox mit welcher Firmware du benutzt. :noidea:

Joe

 

[sunnyman]

Sorry, bin wohl noch nicht richtig bei der Sache; eigentlich wollte ich heute früh ein paar Telefonate führen und die Geschichte hat mich jetzt ärgerlich viel Zeit gekostet :-(

Also:
Fritzbox 7490, FritzOS 6.60
Rechner 1: Ubuntu 16.04, Jitsi 2.8.5426
Rechner 2: macOS Sierra, Jitsi 2.8.5426
Rechner 3: Raspbian wheezy, Asterisk 11.22.0

Ich habe mal etwas gesnifft, wenn mein Linux-Rechner mit Jitsi eine Verbindung zur Fritzbox aufbauen will.
Es findet per DNS eine SRV-Anfrage nach "_sips._TCP.fritz.box" statt, die von der Fritzbox beantwortet wird mit "No such name". Neu gestartet habe ich die Fritzbox übrigens schon.

 

[KunterBunter]

Die Fritzboxen kennen kein SIPS, nur SIP.

 

[sunnyman]

Da magst du recht haben, es wird aber auch die Anfrage nach _sip gestellt mit derselben Antwort.

 

[HabNeFritzbox]

Laut Support Datei gibt es bei DNS auch keine SRV Records. Wozu auch?

SIP oder STUN ect. sind entsprechend fritz.box oder die IP.

 

[sunnyman]

SIP oder STUN ect. sind entsprechend fritz.box oder die IP.

Aber das ist doch gerade mein Problem: wenn ich im SIP-Client bspw. "[email protected]" angebe, heißt es, er könne den Server nicht findenM Jitsispuckt bspw. in die Konsole: "No address found for (...) [email protected]".

Ändere ich den Hostnamen in die IP der Fritzbox, funktioniert es sofort.

 

[Joe_57]

...Ändere ich den Hostnamen in die IP der Fritzbox, funktioniert es sofort.

Dann hast du bei deinen Clients als DNS-Server nicht die IP-Adresse der FritzBox eingetragen.
Die Standard-IP der FritzBox (192.168.xxx.xxx) liegt in einem privaten Bereich, der nicht von öffentliche DNS-Servern aufgelöst werden kann.
Wenn du weiterhin fritz.box verwenden möchtest, kannst du ja die hosts-Dateien der Clients entsprechend anpassen.

Joe

 

[sunnyman]

Dann hast du bei deinen Clients als DNS-Server nicht die IP-Adresse der FritzBox eingetragen.

Es wäre schön wenn es so einfach wäre, aber das ist es nicht. Zum Beispiel die resolv.conf der Linux-Systeme hat die IP der Fritzbox als nameserver drin, und auch nur diese.

Und wenn das das Problem wäre, dürfte ich die Fritzbox ja wohl auch nicht per Ping erreichen oder per Webbrowser, richtig?
[/QUOTE]

 

[sparkie]

wenn

nslookup -querytype=SRV _sip._TCP.fritz.box

kein Ergebnis liefert, funktioniert dann

nslookup -querytype=SRV _sip._UDP.fritz.box

vielleicht?
Wenn das auch nicht funktioniert Fritten-Kinder-DNS entsorgen und durch was Brauchbares ersetzen. Oder wie oben geschrieben gleich die IP direkt verwenden

 

[koyaanisqatsi]

Moin

SNOM DNS-Cache (an F!B 7560 OS: 6.69)
Das...

...steht im SNOM nach einem Reboot im DNS-Cache und wird bald wieder gelöscht sein.

Da ich auch im Heimnetz DualStack aktiv habe, aber nicht für SIP nutze, verwende ich hier nur die IPv4 zum Registrieren.

 

[PeterPawn]

Ich würde ja die "Schuld" eher beim verwendeten Client suchen.

Wenn eine Abfrage nach NAPTR- oder SRV-Records kein Ergebnis erbringt, dann muß eben der Servername nach dem "@" auf "herkömmlichem" Weg durch die Suche nach einem AAAA- oder A-Record aufgelöst werden.

Das ist es ja auch, was die anderen Clients machen - wenn "ping" oder HTTP-Requests per Browser funktionieren, ist ja offenbar "fritz.box" in einen Host-Record aufzulösen.

Wenn ein Client das Parsen von "fritz.box" schon geschafft hat (sonst würde er ja auch nicht nach SRV-Records suchen können), dann sollte es ja kein Problem sein, auch weitere DNS-Abfragen auszuführen.

Wenn der Client das nicht kann (die wirklich älteste Art der Lokalisierung eines Hosts im DNS), dann wird das vermutlich irgendwo in seinen Einstellungen "verboten" sein - und dann hilft logischerweise auch keine "resolv.conf" oder "hosts"-Datei dem Resolver auf die Sprünge.

Eine FRITZ!Box, die SRV- oder NAPTR-Records für SIP-Services (egal ob UDP- oder TCP-basiert) bereitstellt, wäre mir neu ... aber das steht auch wieder alles in den Support-Daten, da braucht man gar nicht lange raten.

PS: Und wenn der SIP-Client mit der IP-Adresse anstatt des Servernamens umgehen kann (#7), wird das eigentlich nur noch deutlicher, daß der Client einfach die falschen Fragen stellt an den DNS-Server und die richtige unter den Tisch fallen läßt. Dafür kann die FRITZ!Box nichts - außer daß sie eben keine SRV-Records ausliefert ... aber das muß sie auch nicht zwingend.

 

[koyaanisqatsi]

Naja, das mit der 127.0.53.53 hab ich erst mit der 6.69er Firmware.

Und auch andere Tools, wie beispielsweise M.Engelkes Fritz!Box Tool geht erst wieder, nachdem...

Bestätigen
[x] Ausführung bestimmter Einstellungen und Funktionen zusätzlich bestätigen
(siehe: Anmeldung im Heimnetz)
...deaktiviert wurde.
(Habe ich Ihm auch schon brav gemailt )

Vielleicht isses...
[x] Nutzung von Internettelefonie aus dem Heimnetz unterbinden
(Anschlusseinstellungen)

Hab ich aber deaktiviert (Standard)
...aber der darunter...
[x] Anzahl der ausgehenden Anrufe ins Ausland begrenzen
...hab ich angehakt.

 

[PeterPawn]

Ich kann mit "dig" die FRITZ!Box nach "_sip._tcp.fritz.box. srv" fragen wie ich will (113.06.69-41986, der TE hat ja auch eine 7490 und verwendet 06.60, also kann es eigentlich nichts mit der 06.69 zu tun haben), es kommt immer keine (bzw. eine leere, also kein NXDOMAIN o.ä.) Antwort, auch wenn ich das mit "_udp" versuche.

Die entscheidende Frage wäre ja, wer der NS ist, der diese Information über die 127.0.53.53 liefert. Wenn das irgendein externer Resolver ist (warum die FRITZ!Box als SOA für die Domain "fritz.box." das überhaupt weiterleiten sollte und dann auch noch ausliefert an einen Client (rebind auf dem lokalen Host), ist mir aber auch unklar), dann wäre das event. zu erklären ... aber schon die "Adresse" ist eigentlich mehr als komisch. Woher die Anzeige im Telefon bei @koy nun kommen mag, kann man mangels Firmware kaum nachvollziehen, aber wenn der Name auch beim TE in diese 127.0.53.53 aufgelöst wird, kann das ja auch nicht das Ergebnis der fehlgeschlagenen SRV-Abfragen (die er mitgeschnitten hat) sein.

Wenn ein "dig @fritz.box dns_entity dns_type_or_any" (natürlich angepaßt) überhaupt eine Antwort liefert von einem der betroffenen Clients, dann hat ja schon mal die Auflösung von "fritz.box" (die nach dem @) funktioniert, dann sollte für jede Anfrage, deren Domain-Teil auf "fritz.box." endet, aber auch keine rekursive Abfrage an einen Forwarder weitergeleitet werden ... die FRITZ!Box ist SOA für "fritz.box." und braucht/soll niemand anderen fragen.

Es wäre vielleicht noch denkbar, daß da irgendein "böser DNS-Server" im Rahmen einer anderen Abfrage noch diese 127.0.53.53 für irgendeinen Eintrag in der Domain "fritz.box" quasi "huckepack" mitliefert als zusätzlichen Eintrag und damit "cache poisoning" bei der FRITZ!Box betreibt - ob das machbar ist, müßte man glatt mal probieren.

Dann wäre es vielleicht denkbar (das ist ja leider alles "closed source"), daß die FRITZ!Box bei so einer Abfrage zuerst ihren Cache konsultiert (der ist m.W. auch nicht in den Support-Daten zu sehen, für den Ringpuffer mit den Abfragen braucht es den Shell-Zugriff - die Support-Daten zeigen nur die "Definitionen" für den NS selbst) und dort so ein Eintrag auftaucht.

Wäre die Frage, welcher DNS-Resolver so eine Antwort an die FRITZ!Box weiterleiten sollte ... wobei eben das Nachsehen in der eigenen FRITZ!Box auch erst einmal klären könnte, ob die jemals eine solche Antwort an einen Client ausliefern konnte (showshringbuf dnsd - das sind praktisch "add" und "del" für die gecachten Einträge, die nach TTL-Ablauf dann wieder rausfliegen).

 

[sf3978]

Zum Beispiel die resolv.conf der Linux-Systeme hat die IP der Fritzbox als nameserver drin, und auch nur diese.

Dann hast Du evtl. in deiner FritzBox den DNS-Rebind-Schutz für mindestens den Domain-Namen ".box" aufgehoben? Z. B. als Test in meiner FB:

 ~ $ host -t SRV _sip._TCP.fritz.box 192.168.178.1
Using domain server:
Name: 192.168.178.1
Address: 192.168.178.1#53
Aliases: 

_sip._TCP.fritz.box.fritz.box has SRV record 10 10 0 your-dns-needs-immediate-attention.box.

 ~ $ host _sip._TCP.fritz.box 192.168.178.1
Using domain server:
Name: 192.168.178.1
Address: 192.168.178.1#53
Aliases: 

_sip._TCP.fritz.box.fritz.box has address 127.0.53.53
_sip._TCP.fritz.box.fritz.box mail is handled by 10 your-dns-needs-immediate-attention.box.

Betr. 127.0.53.53, siehe auch: http://www.heise.de/ct/hotline/Seltsame-DNS-Antwort-127-0-53-53-3087461.html

 

[sunnyman]

Dann hast Du evtl. in deiner FritzBox den DNS-Rebind-Schutz für mindestens den Domain-Namen ".box" aufgehoben?

Auch das ist nicht der Fall.

 

[JoySurfer]

Top Level Doman .box freigegeben

Scheinbar reagiert die Fritzbox bei Anfragen aus dem Heimnetz doch mit einer DNS-Abfrage aus dem Internet.
Von dort kommt die Antwort 127.0.53.53 wegen der neuen Top Level Domain.

Ich würde sagen: die Firmware der Fritzbox ist fehlerhaft.

 

[sf3978]

Auch das ist nicht der Fall.

Dann sind es evtl. dnsmasq oder systemd-resolv auf deinen Linux-Clients, die das machen.

Evtl. dort mit:

sudo tcpdump -vvveni <Interface> port 53

nachschauen.

EDIT:

Z. B.:

:~$ cat /etc/dnsmasq.conf | grep -i rebind-domain-ok=fritz.box
rebind-domain-ok=fritz.box

:~$ host _sip._TCP.fritz.box 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases: 

_sip._TCP.fritz.box.fritz.box has address 127.0.53.53
_sip._TCP.fritz.box.fritz.box mail is handled by 10 your-dns-needs-immediate-attention.box.

 

[PeterPawn]

Mit der Freischaltung dieser neuen TLD (im August stand noch kein Termin fest, nach den RRSIG-Records ging das Ende Oktober (frühestens am 26.) los), wird dann auch das Problem mit der automatischen Proxy-Konfiguration wieder akut: https://heise.de/-3288801

Der Inhaber der Domain "wpad.box" würde von normal konfigurierten LAN-Clients, die ihrerseits WPAD verwenden - was bei einigen auch noch automatisch aktiv sein kann -, nach einem Javascript-File für die Proxy-Konfiguration beim HTTP-Zugriff gefragt. Wenn da eine passende Datei ausgeliefert wird, kann ein Angreifer die gesamte HTTP-Kommunikation des betroffenen Clients (jedenfalls die, die über eine solchermaßen konfigurierte Proxy-Verbindung auch wirklich abgehandelt wird) über einen vom ihm gesetzten Proxy-Server umleiten.

Im Moment liefert die Abfrage von "wpad.box." ebenfalls die 127.0.53.53 - dem Augenschein nach wurde die aber nicht von AVM registriert und eingerichtet, es sieht nicht nach einer "delegation" aus (kein eigener SOA).

Das könnte dann aber auch erklären, woher die Daten im Cache ggf. kommen (das war dann doch kein Poisoning) ... da hat irgendein Client mit WPAD gesucht und die Box hat (fälschlicherweise, denn eigentlich ist sie ja SOA für "fritz.box.") die Anfrage weitergereicht. Was die SIP-Clients hier dann wirklich suchen, muß man halt mit einem Packet-Dump ansehen - eine A/AAAA-Abfrage nach "fritz.box" in einer SIP-URI "[email protected]" sollte immer noch die IP-Adresse der Box liefern und keine 127.0.53.53.

 

[sunnyman]

:~$ cat /etc/dnsmasq.conf | grep -i rebind-domain-ok=fritz.box
rebind-domain-ok=fritz.box

leer.

:~$ host _sip._TCP.fritz.box 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases: 

_sip._TCP.fritz.box.fritz.box has address 127.0.53.53
_sip._TCP.fritz.box.fritz.box mail is handled by 10 your-dns-needs-immediate-attention.box.

host _sip._TCP.fritz.box 127.0.0.1
;; connection timed out; no servers could be reached