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

sf3978

IPPF-Promi
Mitglied seit
2 Dez 2007
Beiträge
7,847
Punkte für Reaktionen
14
Punkte
38
Code:
host _sip._TCP.fritz.box 127.0.0.1
;; connection timed out; no servers could be reached
Dann lauscht dein dnsmasq (oder gleichwertig) nicht auf der IP 127.0.0.1.

Siehe die Ausgaben von:
Code:
sudo netstat -tulpen | grep -i :53
EDIT:

Wie ist auf deinem 16.04 die Ausgabe von:
Code:
cat /etc/nsswitch.conf | grep -i hosts
?
... in der support-Datei der FritzBox, die Eintragungen in der Section:
Code:
##### BEGIN SECTION dns_server DNS configuration

##### END SECTION dns_server
?

BTW: Ist dein 16.04 eine Neuinstallation oder ein release-upgrade von z. B. 14.04?
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,104
Punkte für Reaktionen
1,002
Punkte
113
@sf3978:
Warum gehst Du eigentlich davon aus, daß bei @sunnyman auf den Hosts ein lokaler DNS vorhanden ist?

Er hat doch geschrieben, daß er die FRITZ!Box direkt in der resolv.conf eingetragen hat (in #9).

Dann sucht sich die verwendete C-Library (als Beispiel, wobei auch "Hochsprachen" beim Resolver meist auf die Clib zurückgreifen) aus der resolv.conf die Adresse des NS (aus der "nameserver"-Zeile) und befragt direkt diesen Server. Da muß es doch gar keinen lokalen DNS-Service als Resolver geben?
 

sf3978

IPPF-Promi
Mitglied seit
2 Dez 2007
Beiträge
7,847
Punkte für Reaktionen
14
Punkte
38
@sf3978:
Warum gehst Du eigentlich davon aus, daß bei @sunnyman auf den Hosts ein lokaler DNS vorhanden ist?
Weil ich schon einige Hosts mit 16.04 gesehen habe, bei denen es dann z. B. so:
Code:
tcp        0      0 0.0.0.0:5355            0.0.0.0:*               LISTEN      102        19706      1022/systemd-resolv 
tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN      0          28428      1931/dnsmasq        
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      102        19704      1022/systemd-resolv 
tcp      129      0 127.0.2.1:53            0.0.0.0:*               LISTEN      0          18966      1/init              
tcp6       0      0 :::5355                 :::*                    LISTEN      102        19709      1022/systemd-resolv 
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           116        20214      1098/avahi-daemon:  
udp        0      0 0.0.0.0:5355            0.0.0.0:*                           102        19705      1022/systemd-resolv 
udp        0      0 127.0.1.1:53            0.0.0.0:*                           0          28427      1931/dnsmasq        
udp        0      0 127.0.0.53:53           0.0.0.0:*                           102        19703      1022/systemd-resolv 
udp   213504      0 127.0.2.1:53            0.0.0.0:*                           0          18967      1/init              
udp6       0      0 :::5353                 :::*                                116        20215      1098/avahi-daemon:  
udp6       0      0 :::5355                 :::*                                102        19708      1022/systemd-resolv
aussieht und das auch dann, wenn eine FritzBox vorhanden ist.

Er hat doch geschrieben, daß er die FRITZ!Box direkt in der resolv.conf eingetragen hat (in #9).
Ja, aber das Eintragen durch den user in die resolv.conf ist das eine. Wichtig ist, was letztendlich in diese Datei, durch andere Dienste evtl. dort noch eingetragen/(überschrieben?) worden ist.
 

Theo Tintensich

Aktives Mitglied
Mitglied seit
10 Mrz 2008
Beiträge
1,740
Punkte für Reaktionen
48
Punkte
48
Secure DNS im Avast.
Das klingt dann nach der Verwendung von DNSSEC, was wohl ein externer DNS-Server wäre. Also nicht die F!B
Oder?
 

HabNeFritzbox

IPPF-Urgestein
Mitglied seit
12 Dez 2017
Beiträge
15,892
Punkte für Reaktionen
303
Punkte
83
Was hat Avast Internet Security mit nem IP-Telefon zutun?
 

Theo Tintensich

Aktives Mitglied
Mitglied seit
10 Mrz 2008
Beiträge
1,740
Punkte für Reaktionen
48
Punkte
48
Was hat Avast Internet Security mit nem IP-Telefon zutun?
Gute Frage ;-)

Da der TO, wie es aussieht, ein Soft-Phone verwendet, denn es wird kein Telefon-Typ genannt, ist es eine Sache, die aufd em Computer, auf dem das Soft-Phone läuft, schiefläuft.

In einem anderen Thread wurde ja IPv6 genannt, und auch hier im Thread DualStack.
Eigentlich sollte ja die F!B das abhändeln, aber ....
 

HabNeFritzbox

IPPF-Urgestein
Mitglied seit
12 Dez 2017
Beiträge
15,892
Punkte für Reaktionen
303
Punkte
83
In #3 wird ja Mac und Linux Rechner genannt, nicht Android Smartphone oder Windows PC wo sowas eher üblich ist.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,104
Punkte für Reaktionen
1,002
Punkte
113
@sf3978:
Nun ist ein Ubuntu 16.04 auch nur eines der Systeme mit identischen Symptomen, soweit ich das verstanden habe (Hinweise erwünscht, wo ich etwas überlesen habe).

Solange das beim Raspian nicht ebenfalls die Vermutung ist, daß da von irgendwelchen systemd-Skripten die resultierende resolv.conf noch einmal geändert wurde, ist die Suche nach einem lokalen Resolver m.E. der falsche Ansatz und ich gehe auch davon aus, daß der TE den Inhalt der "resolv.conf" auch bei aktiver Netzwerkverbindung noch einmal geprüft hat. Was im MacOS los sein mag, will ich nicht beurteilen ... aber wenn das auch dieselben Symptome sind, sind es drei verschiedene betroffene Systeme.

Auch die Feststellung, daß bei einem "nslookup" mit "127.0.0.1" als Server ja gerade niemand zu erreichen ist, spricht je eher dagegen, daß es einen lokalen Resolver geben sollte als für die Annahme, daß der dann auch noch selektiv an die IP-Adressen gebunden ist (ausgerechnet an "localhost" dann nicht) und das in einer Standardkonfiguration, denn eine eigene Einstellung des TE hätte er sicherlich erwähnt.
 
Zuletzt bearbeitet:

sunnyman

Mitglied
Mitglied seit
13 Jan 2006
Beiträge
248
Punkte für Reaktionen
0
Punkte
16
@sf3978:
Nun ist ein Ubuntu 16.04 auch nur eines der Systeme mit identischen Symptomen, soweit ich das verstanden habe (Hinweise erwünscht, wo ich etwas überlesen habe).
Vollkommen richtig. Das Raspbian ist wheezy und ohne systemd.
Die Fritzbox ist übrigens nicht manuell in die resolv.conf gekommen sondern per DHCP.

Nochmal zur Klarstellung:

Der Zugriff auf den SIP-Server der Fritzbox per "fritz.box" hat von allen 3 Systemen funktioniert, und das über Jahre und auch bereits bei einer Fritzbox 7390, die dann mal den Gewittertod starb.

Das Problem trat plötzlich auf, ohne dass ich etwas verändert habe. An der Fritzbox ganz sicher nicht, und auf dem Ubuntu 16.04 und dem Mac sind keine Updates in zeitlicher Nähe durchgeführt worden. Einzig auf dem Raspbian habe ich mal ein apt-get upgrade / dist-upgrade gemacht, aber auch das stand, soweit ich mich erinnere, in keinem direkten zeitlichen Zusammenhang.
 

JoySurfer

Neuer User
Mitglied seit
15 Nov 2016
Beiträge
2
Punkte für Reaktionen
0
Punkte
0

sunnyman

Mitglied
Mitglied seit
13 Jan 2006
Beiträge
248
Punkte für Reaktionen
0
Punkte
16
Danke für den Hinweis, aber in den betreffenden Netzen gibt es keine Windows-Systeme. Zudem sollte der Secure-DNS-Server diese Antworten ja wohl auch nur für das lokale System geben oder wenn er gefragt wird, was hier ja auch nicht zutrifft.
 

sf3978

IPPF-Promi
Mitglied seit
2 Dez 2007
Beiträge
7,847
Punkte für Reaktionen
14
Punkte
38
Die Fritzbox ist übrigens nicht manuell in die resolv.conf gekommen sondern per DHCP.

Das Problem trat plötzlich auf, ohne dass ich etwas verändert habe. An der Fritzbox ganz sicher nicht,
Starte mal auf deinem Ubuntu 16.04:
Code:
sudo tcpdump -c 30 -vvveni <Interface> port 53
und führe danach auf deinem Ubuntu 16.04:
Code:
host _sip._TCP.fritz.box
aus. Wie ist danach, die Ausgabe von tcpdump?
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,104
Punkte für Reaktionen
1,002
Punkte
113
@sunnyman:
Passiert das auch nach einem Neustart der Box?

Meine Idee für die Erklärung (die muß nicht stimmen, ist reine Spekulation und nur der Versuch, das zu verstehen) wäre es, daß irgendwann ein Client im LAN mit Proxy-Autodiscovery an den DNS-Server in der FRITZ!Box herantritt und den dann nach "wpad.box" (die letzte "Stufe", wenn vorher nichts gefunden wurde) befragt. Der geht jetzt hin, sucht sich den zuständigen Server für "box" als TLD und kriegt dessen SOA. Wenn der die Information ebenfalls irgendwo speichert und bei der nächsten Abfrage einer "fritz.box"-Adresse dann der DNS-Hierarchie folgt und nicht mehr mitkriegt, daß er selbst SOA für "fritz.box" ist und bei "box" beginnt (er hat ja einen "frischen" Cache-Eintrag für den SOA der TLD und darunter vermutlich aber keinen für "fritz.box"), dann könnte das passieren, was Du beschreibst. Ansonsten dürfte der gar nicht erst den "box"-DNS befragen für "fritz.box."-Abfragen.

Ist zwar nur Spekulation und hängt davon ab, wie da der Cache bei AVM aufgebaut ist ... aber wenn das eine verkettete Liste ist und an der Spitze steht die Domain "box", während darunter der "fritz" in der nächsten Ebene fehlt, dann wäre es denkbar (und auch nicht vollkommen abwegig), daß der NS die Adresse versucht extern aufzulösen.

Ich kann das leider ohne aufwändige Umkonfiguration nicht selbst testen, weil bei mir der DNS-Server (den auch die FRITZ!Box als Forwarder benutzt) eine eigene "box"-Domain hat:
Code:
$ORIGIN .
$TTL 172800     ; 2 days
box                             IN SOA  central.home.meinedomain.de. root.central.home.meinedomain.de. (
                                2013080301 ; serial
                                10800      ; refresh (3 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
                        NS      central.home.meinedomain.de.
$ORIGIN box.
fritz                   A       192.168.178.1
hat, damit ich per "fritz.box" auch wirklich zugreifen kann, denn bei mir ist die Box nicht der DNS-Server.

Allerdings gingen dann wohl entweder gar keine "lokalen" Abfragen mehr (außer auf ein "NXDOMAIN" hin wird dann doch die eigene Konfiguration noch durchsucht) oder der DNS trägt seine eigene Konfiguration auch (als nicht-verfallenden Eintrag) in der Cache-Struktur ein und der wird nicht mehr gefunden, sobald die "Verzweigung" für "box" zu einem anderen SOA davor erfolgt - was dann erst wieder nach so einem "Auto-Discovery" erfolgen würde.

Je nachdem, welche Theorie stimmt, könnte es sogar helfen, eine alte "Angriffsmöglichkeit" auf das FRITZ!OS nun zum eigenen Nutzen umzufunktionieren. Normalerweise hört WPAD mit der Suche auf, wenn ein passender Host gefunden wird und der auch noch eine Datei für die Proxy-Konfiguration anbietet. Dann könnte es schon helfen, wenn es in der FRITZ!Box einen Eintrag "wpad.fritz.box." gibt (einfach einen "Pseudohost" mit diesem Namen anlegen als Netzwerkgerät) und die Box deshalb nicht mehr nach "wpad.box" gefragt wird. Dann könnte man das (bis zu einer Lösung seitens AVM) durch einen eigenen Webserver, der eine (neutrale) "wpad.dat" (mit dem richtigen MIME-Typ, nicht irgendeinem) bereitstellt, entschärfen. Ansonsten ist im WPAD-Draft (einen verabschiedeten RFC als Standard gibt es dafür gar nicht) wieder festgelegt, daß sich der Client weiter durchfragen soll (Punkt 4.7).

Ich bin mal gespannt, wie AVM das Problem angehen wird ... auf eine gemeldete Lücke, die sich aus der Behandlung von lokalen Namen durch das FRITZ!OS ergibt oder zumindest ergab, hat AVM mir versichert, man habe das Problem im Blick, wenn nicht sogar im Griff.

Das FRITZ!OS verwurstet(e) nämlich nicht nur "richtige" DNS-Namen, sondern auch mDNS-"Erkenntnisse" werden/wurden nicht unter der dafür üblichen Domain "local" (oder einer anderen) gehandelt, sondern zur Domain "fritz.box" hinzugefügt.

Das führt dann dazu, daß irgendein Netzwerk-Client einfach per mDNS behaupten kann, er hieße "wpad" und dann liefert(e) die FRITZ!Box netterweise bei späteren Abfragen nach "wpad.fritz.box" dessen IP-Adresse an den Fragenden.

Stellt dieser Client dann auch noch den benötigten HTTP-Server mit der passenden "wpad.dat" und tatsächlich einen Proxy-Server bereit, kann man im Handumdrehen als Angreifer im LAN den HTTP-Traffic eines anderen Clients über den eigenen Host umleiten ... nicht ganz ohne (Hinter-)Grund behaupte ich immer wieder aufs Neue, ein Angriff auf fremde FRITZ!OS-Credentials wäre kinderleicht möglich.

Und das liegt auch nicht am mDNS oder ähnlichem an sich ... das "Vermischen" der Namensräume im FRITZ!OS war die eigentliche Ursache des Problems. Kein Client würde bei einer per DHCP konfigurierten "Such-Domain" von "fritz.box" nach einem Host "wpad.local" suchen (oder welche der anderen denkbaren mDNS-Domainnamen man auch verwenden mag, von zeroconf.org bis 0pointer.de) und damit könnte sich so ein Angreifer einen Wolf labern.

Jedenfalls kam von AVM damals die Antwort:
AVM schrieb:
Der von Ihnen gemeldeten Punkt ist uns bereits seit der Kontaktaufnahme mit
Heise und dem dazu veröffentlichten Artikel zum Thema WPAD bekannt.
[...]
Wir untersuchen zur Zeit noch, ob wir in diesem Zusammenhang ein default
DNS-Blacklisting bestimmter Hostnamen umsetzen.
Wenn es nunmehr mit der Freischaltung von "box" richtig akut wird (wenn ich mich nicht "vertestet" habe, wird zumindest "wpad" nicht mehr als Hostname einfach zu "fritz.box" hinzugefügt im 7490-Laborzweig - was ja dem "blacklisting" aus der AVM-Antwort entsprechen würde), daß die Box keine externen Abfragen unterhalb von "fritz.box" (und auch nicht für wpad.box, auch wenn das zur Zeit ebenfalls 127.0.53.53 liefert) ausführt, dann wird das vermutlich noch einmal ein schönes Stück Arbeit werden ... ist halt alles "closed source" und da nutzt es nichts, wenn es andere DNS-Server (von bind bis dnsmasq) schon heute richtig machen.

Ob AVM auch auf die Übernahme anderer mDNS-Namen nach "fritz.box" ab jetzt verzichtet, habe ich nicht ausführlich getestet - ist eben alles noch Labor-Zweig. Aber ich persönlich finde es auch generell keine gute Idee, solche "Ansagen" eines Clients in die "offizielle Auskunft" einzubeziehen.

Wenn jemand sich in seinem Netz darauf verläßt, daß es keinen anderen Host "MeinServer" gibt und dann eben nach negativer DNS-Abfrage in der eigenen Suchdomain auf andere Namenserkennungen umgeschaltet wird (z.B. NetBIOS over IP wie beim Samba), dann ist es eben eine richtig schlechte Idee, wenn irgendein Client von sich behaupten kann, er wäre jetzt "MeinServer" (da gibt es keine Authentifizierung oder Autorisierung für eine solche Behauptung) und dann übernimmt das der DNS-Server einfach als seine eigene Antwort auf die (automatische) Abfrage von "MeinServer.fritz.box." - das ist einfach Gülle. Netter Versuch, es dem Kunden so einfach wie möglich zu machen, seine Geräte mit irgendeinem Namen anzusprechen ... aber ein Scheunentor für Angreifer im LAN.

Das ist bei der 41986 auch nicht ohne weiteres zu ermitteln gewesen (die neue von heute muß erst einmal "abhängen"), da dort bei den Supportdaten erstmals auf "aicmd" zum Auslesen der Daten umgestellt wurde (ja, es gibt immer wesentlich mehr Änderungen "unter der Haube" als man von außen sehen kann) und dabei gleich noch ein "fi" zuviel im Code verblieb, der die Supportdaten an dieser Stelle abbrechen läßt - wie weit also die "neighbours" immer noch berücksichtigt werden, kriegt man bei der 41896 nur auf anderen Wegen heraus.

- - - Aktualisiert - - -

Ich habe das jetzt mal etwa ausführlicher auf der FRITZ!Box getestet ... es gelingt mir (113.06.69-41986) absolut nicht, für einen Namen unterhalb von "fritz.box" die Antwort 127.0.53.53 von der FRITZ!Box zu erhalten. Entweder das ist bereits gefixt (ich müßte erst die 06.60 in der zweiten Partition installieren um das zu testen) oder ich stelle mich zu blöd an.

Sowie ich den Namen "fritz.box" abwandele (z.B. "frItz.box"), kriege ich logischerweise die 127.0.53.53 vom NS für die TLD - aber keine Chance, den "multid"-Cache irgendwie zu "verwirren".

Zwar fügt der brav A- und AAAA-Einträge für alle möglichen Namen hinzu:
Code:
2016-11-18 07:13:58.813 - add AAAA wpad.box ttl=143 empty answer, flags=0x0000
2016-11-18 07:13:58.880 - add A wpad.box ttl=3599, flags=0x0000
2016-11-18 07:13:58.914 - add PTR 53.53.0.127.in-addr.arpa ttl=3239 nxdomain, flags=0x0000
2016-11-18 07:13:58.950 - del PTR 53.53.0.127.in-addr.arpa (flags=0x0000)
2016-11-18 07:13:58.950 - add PTR 53.53.0.127.in-addr.arpa ttl=3238 nxdomain, flags=0x0000
2016-11-18 07:16:21.813 - del AAAA wpad.box (flags=0x0000)
2016-11-18 07:17:12.471 - add AAAA box ttl=899 empty answer, flags=0x0000
2016-11-18 07:17:12.621 - add A box ttl=3599, flags=0x0000
2016-11-18 07:21:25.368 - add AAAA _tcp.fritzi.box ttl=899 empty answer, flags=0x0000
2016-11-18 07:21:25.433 - add A _tcp.fritzi.box ttl=3599, flags=0x0000
2016-11-18 07:21:26.843 - add A time.apple.com ttl=87, flags=0x0000
2016-11-18 07:22:53.842 - del A time.apple.com (flags=0x0000)
2016-11-18 07:23:04.903 - add SRV fritzo.box ttl=3599, flags=0x0003
2016-11-18 07:23:16.309 - add ANY fritzo.box ttl=5 empty answer, flags=0x0003
2016-11-18 07:23:16.440 - add ANY fritzo.box ttl=3599, flags=0x80000003
2016-11-18 07:23:21.309 - del ANY fritzo.box (flags=0x0003)
und speichert offenbar auch negative Antworten, aber alles nicht dann, wenn das unterhalb von "fritz.box" liegt. Es liegt also wohl nicht am DNS-Server der FRITZ!Box und daß der selbst keine SRV- oder NAPTR-Records für die eigenen Services verwaltet, bleibt weiter gültig.

@sunnyman:
Ich würde hier ein System mit einem der SIP-Clients neu starten und parallel dazu noch einmal die FRITZ!Box. Letztere eigentlich nur, damit deren Resolver-Cache auch wirklich leer ist. Bei Start des Clients sollte erst einmal noch kein SIP-Client gestartet werden, sondern erst einmal ein "tcpdump" (oder vielleicht ja auch Wireshark) und zwar am besten mit Sicherung in eine Datei. Ansehen kann man das immer noch später und ich würde mich auch nicht ausschließlich auf Port 53 festlegen - schon eine zwischenzeitlich noch auftauchende mDNS-Abfrage nach dem Namen könnte wichtig sein. Heutzutage sind solche "zeroconf"-Abfragen auch nicht mehr so richtig exotisch und bei Jitsi als Client würde es mich auch nicht so sehr wundern (ohne es zu wissen), wenn da in der Suchreihenfolge nach SIP-Registraren auch andere Dienste als DNS zurate gezogen würden.

Um die Quelle (nicht nur den Absender, sondern auch die Ursache) dieser 127.0.53.53-Antwort zu finden, muß man wohl erst die Reihenfolge der Abfragen durch den SIP-Client genau verstehen ... und dazu sollte man auch im Dump sehen können, welche Abfragen und Antworten da im Netzwerk in welcher Reihenfolge auftauchen.

Da gerade solche DNS-Probleme wegen der verschiedenen Caches auch immer merkwürdige Effekte aufweisen, wäre der "saubere Start" wirklich extrem wichtig. Schon eine lokal für die angegebene TTL gecachte Antwort kann dazu führen, daß da im Packetdump eine Abfrage "fehlt" und dann rätselt man endlos herum, was es mit so einem "missing link" auf sich haben könnte.

Irgendwo gibt es - dank der nunmehr existierenden TLD "box" - bei der Suche nach dem Hostnamen durch den SIP-Client eine Antwort, die es vor dem 11.11. (da ging die Domain wohl online, vermutlich auch noch um 11:11 Uhr?) eben nicht gab und wo dann der Client einfach weitergesucht hat. Jetzt kommt diese Antwort mit der 127.0.53.53 und da wird die Suche dann eben abgebrochen. Nur wenn diese Antwort irgendwie verhindert werden kann, wird der Client wohl bis zur "gewöhnlichen" Abfrage eines A- oder AAAA-Records kommen und dann wohl auch wieder die Adresse "fritz.box" auflösen können.
 

informerex

IPPF-Urgestein
Mitglied seit
20 Apr 2005
Beiträge
17,173
Punkte für Reaktionen
53
Punkte
48

koyaanisqatsi

IPPF-Urgestein
Mitglied seit
24 Jan 2013
Beiträge
12,510
Punkte für Reaktionen
323
Punkte
83
Moin

:gruebel:
PeterPawn schrieb:
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.
Im SNOM hab ich mal geschaut...
Screenshot_2016-11-18-10-11-59.png
...und die DHCP Option 15 rausgenommen.
http://wiki.snom.com/Networking/DHCP/Options
Dazu noch die Domain fritz.box gelöscht, welcher durch die DHCP-Option 15 eingetragen wurde.

Nach Neustart blieb der DNS-Cache leer und fritz.box wird nicht mehr als Domain eingetragen.
 
Zuletzt bearbeitet:

Theo Tintensich

Aktives Mitglied
Mitglied seit
10 Mrz 2008
Beiträge
1,740
Punkte für Reaktionen
48
Punkte
48

sf3978

IPPF-Promi
Mitglied seit
2 Dez 2007
Beiträge
7,847
Punkte für Reaktionen
14
Punkte
38
Die FritzBox liefert für "*.fritz.box.fritz.box" nicht "not found: 3(NXDOMAIN)", sondern "* has address 127.0.53.53":
Code:
:~ $ host -t A ergeerghh5t4554g5.fritz.box.fritz.box 192.168.178.1
Using domain server:
Name: 192.168.178.1
Address: 192.168.178.1#53
Aliases: 

ergeerghh5t4554g5.fritz.box.fritz.box has address 127.0.53.53
Mit "search fritz.box" in der "/etc/resolv.conf" (und "rebind-localhost-ok" in der "/etc/dnsmasq.conf") kann man das reproduzieren. Z. B.:
"mit"
Code:
:~$ host -t A 4453452er888grferg.fritz.box
4453452er888grferg.fritz.box.fritz.box has address 127.0.53.53
Code:
:~$ sudo tcpdump -vvveni any port 53
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
10:12:55.574769  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 90: (tos 0x0, ttl 77, id 26867, offset 0, flags [none], proto UDP (17), length 74)
    127.0.0.1.60083 > 127.0.0.1.53: [bad udp cksum 0xfe49 -> 0xa2cf!] 35498+ A? 4453452er888grferg.fritz.box. (46)
10:12:55.574937 Out 00:1b:77:40:ca:3b ethertype IPv4 (0x0800), length 90: (tos 0x0, ttl 77, id 43032, offset 0, flags [DF], proto UDP (17), length 74)
    192.168.178.21.51515 > 192.168.178.1.53: [udp sum ok] 15153+ A? 4453452er888grferg.fritz.box. (46)
10:12:55.578607  In c0:25:06:2b:52:de ethertype IPv4 (0x0800), length 132: (tos 0x0, ttl 64, id 38276, offset 0, flags [none], proto UDP (17), length 116)
    192.168.178.1.53 > 192.168.178.21.51515: [udp sum ok] 15153 NXDomain* q: A? 4453452er888grferg.fritz.box. 0/1/0 ns: fritz.box. [9s] SOA fritz.box. admin.fritz.box. 1479460375 21600 1800 43200 10 (88)
10:12:55.578738  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 132: (tos 0x0, ttl 77, id 26868, offset 0, flags [DF], proto UDP (17), length 116)
    127.0.0.1.53 > 127.0.0.1.60083: [bad udp cksum 0xfe73 -> 0xe7b3!] 35498 NXDomain* q: A? 4453452er888grferg.fritz.box. 0/1/0 ns: fritz.box. [9s] SOA fritz.box. admin.fritz.box. 1479460375 21600 1800 43200 10 (88)
10:12:55.579116  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 77, id 26869, offset 0, flags [none], proto UDP (17), length 84)
    127.0.0.1.41928 > 127.0.0.1.53: [bad udp cksum 0xfe53 -> 0x202d!] 12229+ A? 4453452er888grferg.fritz.box.fritz.box. (56)
10:12:55.579200 Out 00:1b:77:40:ca:3b ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 77, id 43033, offset 0, flags [DF], proto UDP (17), length 84)
    192.168.178.21.55207 > 192.168.178.1.53: [udp sum ok] 35785+ A? 4453452er888grferg.fritz.box.fritz.box. (56)
10:12:55.622726  In c0:25:06:2b:52:de ethertype IPv4 (0x0800), length 116: (tos 0x0, ttl 64, id 38277, offset 0, flags [none], proto UDP (17), length 100)
    192.168.178.1.53 > 192.168.178.21.55207: [udp sum ok] 35785 q: A? 4453452er888grferg.fritz.box.fritz.box. 1/0/0 4453452er888grferg.fritz.box.fritz.box. [30m] A 127.0.53.53 (72)
10:12:55.622883  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 116: (tos 0x0, ttl 77, id 26879, offset 0, flags [DF], proto UDP (17), length 100)
    127.0.0.1.53 > 127.0.0.1.41928: [bad udp cksum 0xfe63 -> 0x243b!] 12229 q: A? 4453452er888grferg.fritz.box.fritz.box. 1/0/0 4453452er888grferg.fritz.box.fritz.box. [30m] A 127.0.53.53 (72)
"ohne"
Code:
:~$ host -t A 4453452er888thrth5674htrhthrferg.fritz.box
Host 4453452er888thrth5674htrhthrferg.fritz.box not found: 3(NXDOMAIN)
Code:
:~$ sudo tcpdump -vvveni any port 53
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
10:32:17.275287  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 104: (tos 0x0, ttl 77, id 21895, offset 0, flags [none], proto UDP (17), length 88)
    127.0.0.1.44082 > 127.0.0.1.53: [bad udp cksum 0xfe57 -> 0x45c9!] 32638+ A? 4453452er888thrth5674htrhthrferg.fritz.box. (60)
10:32:17.275527 Out 00:1b:77:40:ca:3b ethertype IPv4 (0x0800), length 104: (tos 0x0, ttl 77, id 56850, offset 0, flags [DF], proto UDP (17), length 88)
    192.168.178.21.51809 > 192.168.178.1.53: [udp sum ok] 56869+ A? 4453452er888thrth5674htrhthrferg.fritz.box. (60)
10:32:17.286689  In c0:25:06:2b:52:de ethertype IPv4 (0x0800), length 146: (tos 0x0, ttl 64, id 23191, offset 0, flags [none], proto UDP (17), length 130)
    192.168.178.1.53 > 192.168.178.21.51809: [udp sum ok] 56869 NXDomain* q: A? 4453452er888thrth5674htrhthrferg.fritz.box. 0/1/0 ns: fritz.box. [9s] SOA fritz.box. admin.fritz.box. 1479461537 21600 1800 43200 10 (102)
10:32:17.286861  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 146: (tos 0x0, ttl 77, id 21898, offset 0, flags [DF], proto UDP (17), length 130)
    127.0.0.1.53 > 127.0.0.1.44082: [bad udp cksum 0xfe81 -> 0x85f9!] 32638 NXDomain* q: A? 4453452er888thrth5674htrhthrferg.fritz.box. 0/1/0 ns: fritz.box. [9s] SOA fritz.box. admin.fritz.box. 1479461537 21600 1800 43200 10 (102)
10:32:17.287644  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 104: (tos 0x0, ttl 77, id 21899, offset 0, flags [none], proto UDP (17), length 88)
    127.0.0.1.41219 > 127.0.0.1.53: [bad udp cksum 0xfe57 -> 0x13bd!] 48313+ A? 4453452er888thrth5674htrhthrferg.fritz.box. (60)
10:32:17.287969 Out 00:1b:77:40:ca:3b ethertype IPv4 (0x0800), length 104: (tos 0x0, ttl 77, id 56852, offset 0, flags [DF], proto UDP (17), length 88)
    192.168.178.21.56281 > 192.168.178.1.53: [udp sum ok] 55523+ A? 4453452er888thrth5674htrhthrferg.fritz.box. (60)
10:32:17.290961  In c0:25:06:2b:52:de ethertype IPv4 (0x0800), length 146: (tos 0x0, ttl 64, id 23192, offset 0, flags [none], proto UDP (17), length 130)
    192.168.178.1.53 > 192.168.178.21.56281: [udp sum ok] 55523 NXDomain* q: A? 4453452er888thrth5674htrhthrferg.fritz.box. 0/1/0 ns: fritz.box. [9s] SOA fritz.box. admin.fritz.box. 1479461537 21600 1800 43200 10 (102)
10:32:17.291068  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 146: (tos 0x0, ttl 77, id 21900, offset 0, flags [DF], proto UDP (17), length 130)
    127.0.0.1.53 > 127.0.0.1.41219: [bad udp cksum 0xfe81 -> 0x53ed!] 48313 NXDomain* q: A? 4453452er888thrth5674htrhthrferg.fritz.box. 0/1/0 ns: fritz.box. [9s] SOA fritz.box. admin.fritz.box. 1479461537 21600 1800 43200 10 (102)
EDIT:

Eine alte SD-Karte mit wheezy (... ohne lauschende Dienste auf dem Port 53) in den PI gesteckt und getestet:
Code:
 ~ $ cat /etc/resolv.conf
domain fritz.box
search fritz.box
nameserver 192.168.178.1
Code:
 ~ $ host -t A tfvzuftugergrzftuzt.fritz.box
tfvzuftugergrzftuzt.fritz.box.fritz.box has address 127.0.53.53
Code:
 ~ $ sudo tcpdump -vvveni eth0 port 53
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:52:31.078022 b8:27:eb:11:42:30 > c0:25:06:2b:52:de, ethertype IPv4 (0x0800), length 89: (tos 0x0, ttl 64, id 10191, offset 0, flags [none], proto UDP (17), length 75)
    192.168.178.24.51093 > 192.168.178.1.53: [bad udp cksum 0xe5b3 -> 0xd028!] 6539+ A? tfvzuftugergrzftuzt.fritz.box. (47)
15:52:31.079396 c0:25:06:2b:52:de > b8:27:eb:11:42:30, ethertype IPv4 (0x0800), length 131: (tos 0x0, ttl 64, id 28772, offset 0, flags [none], proto UDP (17), length 117)
    192.168.178.1.53 > 192.168.178.24.51093: [udp sum ok] 6539 NXDomain* q: A? tfvzuftugergrzftuzt.fritz.box. 0/1/0 ns: fritz.box. [9s] SOA fritz.box. admin.fritz.box. 1479480751 21600 1800 43200 10 (89)
15:52:31.081051 b8:27:eb:11:42:30 > c0:25:06:2b:52:de, ethertype IPv4 (0x0800), length 99: (tos 0x0, ttl 64, id 10192, offset 0, flags [none], proto UDP (17), length 85)
    192.168.178.24.50448 > 192.168.178.1.53: [bad udp cksum 0xe5bd -> 0x993b!] 62404+ A? tfvzuftugergrzftuzt.fritz.box.fritz.box. (57)
15:52:31.083048 c0:25:06:2b:52:de > b8:27:eb:11:42:30, ethertype IPv4 (0x0800), length 115: (tos 0x0, ttl 64, id 28773, offset 0, flags [none], proto UDP (17), length 101)
    192.168.178.1.53 > 192.168.178.24.50448: [udp sum ok] 62404 q: A? tfvzuftugergrzftuzt.fritz.box.fritz.box. 1/0/0 tfvzuftugergrzftuzt.fritz.box.fritz.box. [28m45s] A 127.0.53.53 (73)
 
Zuletzt bearbeitet: