nslookup <ip client-box> <ip client-box>
Das verstehe ich gerade nicht so richtig, was man damit erreicht oder überprüft.
Wenn es tatsächlich die Abfrage nach dem Schema "nslookup 192.168.100.1 192.168.100.1" sein sollte, also eine "reverse lookup"-Anfrage für einen Eintrag "1.100.168.192.in-addr.arpa", dann würde ich - solange die Box Proxy/Forwarder ist und die Abfrage nicht explizit das Forwarden (recursive-Flag) verbietet (was m.W. - es hängt etwas davon ab, was das für ein Host-System ist - bei dieser "nicht-interaktiven" Form nicht der Fall ist) - eher erwarten, daß diese Abfrage von der FRITZ!Box nicht unbedingt aus ihrem eigenen Cache bereits beim ersten Mal beantwortet werden kann und sie deshalb an den dort konfigurierten nächsten DNS-Server weitergeleitet wird. Das Ergebnis wäre damit dann die Antwort des (DNS-)Uplinks.
Aber das ist tatsächlich nur eine Erwartung/Überlegung und nicht selbst probiert. Was kommt denn heraus, wenn man das auf einer FRITZ!Box im IP-Client-Mode macht? Wenn man nicht anhand der Support-Daten den Inhalt des DNS-Caches vor und nach einer solchen Abfrage vergleichen will, bliebe ja noch der Mitschnitt des Netzwerk-Verkehrs, um den zum Uplink dabei zu sehen. Es könnte genauso gut aber natürlich auch sein, daß die Box ihre eigene Adresse auch als IP-Client automatisch in den Cache einträgt, wie sie es dann tut, wenn sie selbst einen Teil des Netzes verwaltet. Das stünde dann wieder im DNS-Teil der Supportdaten und zwar schon vor der ersten "nslookup"-Anfrage nach dem o.a. Schema ... wenn die Box von keinem Client befragt wird, sollte sie auch nichts im Cache haben, was sie nicht selbst eingetragen oder schon einmal abgefragt hat.
Auch die "feiner abzustufende" Befragung des Caches/Servers/Proxies/Forwarders per "dig"-Kommando könnte - wenn man schon beim ersten Aufruf ordentlich aufpaßt, denn wenn eine Angabe erst einmal im Cache steht, muß man den TTL-Ablauf dieser Angabe erst einmal abwarten - genauere Erkenntnisse liefern, wobei auch hier der Mitschnitt natürlich quasi Pflicht wäre.
Was ich - für die 06.20 nur, danach nicht mehr getestet - ausschließen könnte, wäre das Berücksichtigen der Domain-Angabe, wenn die als Router arbeitet und extern DHCP macht. Eine 7390 mit 06.20 als Router im internen Netz erhielt ihre eigene IP-Adresse (wie alle anderen LAN-Clients auch) per DHCP von einem ISC-dhcpd zusammen mit einem sehr kompletten Satz an weiteren Parametern (u.a. auch die Option für die Adresse eines ACS zum Testen von TR-069, das war der eigentliche Zweck des Tests) und verwendete weder den übermittelten eigenen Domain-Namen noch die Liste der Suchdomains jemals selbst in einer eigenen Abfrage. Ein "ping clientname" ohne explizite Angabe des Domainnamen in der Console dieser 7390 ergab also nicht den Namen dieses Clients (und ein ICMP-Paket an diesen), sondern immer "unknown address", da die Vervollständigung zu einem FQDN (und die mehrmalige Abfrage für jeden Eintrag der Suchliste) Aufgabe des Clients ist/wäre.
Wie gesagt, ich weiß es nicht genau, wie die Box als IP-Client arbeitet (ist mangels Angriffsflächen eher nicht der Modus, den ich näher betrachte). Als Router kann ich das "Akzeptieren" fast ausschließen und ein Ergebnis mit korrektem Host- und Domain-Namen auf die o.a. Reverse-Lookup-Anfrage würde ich - rein aus dem Bauch heraus, das ist keine gesicherte Erkenntnis - eher dem benutzten Forwarder zuschreiben als der Box (also dem multid) selbst.
