@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.
