[Frage] Namesauflösung xxx.fritz.box seit V7.0 unzuverlässig

m.kress · 9 Nov 2018

PeterPawn schrieb:
Ansonsten wäre die Frage, ob bei @m.kress die Geräte jetzt tatsächlich immer dieselbe Adresse zugewiesen bekommen und ob sie sich seit der Änderung des Namens schon mal diese Adresse "neu" von der Box geholt haben ...

Bisher scheinen die Geräte immer die gleich IP bekommen zu haben. Meine Lease-Time beträgt 5 Tage.

PeterPawn schrieb:
Was steht denn jetzt in den DNS-Informationen zu diesen beiden LAN-Clients? Deren Ausgabe (die der DNS-Daten) ist ja auch in den Support-Daten zu finden, wenn man keinen Shell-Zugriff hat.

Ist das unterhalb von "*** zone default" (bei den "hash xx" Angaben)? Da ist nichts mit dem Namen oder der IP zu finden.

PeterPawn · 9 Nov 2018

m.kress schrieb:
Bisher scheinen die Geräte immer die gleich IP bekommen zu haben.

Ich denke nicht, daß man das durch reine Beobachtung (vor allem bei solchen Zeiträumen) näher untersuchen kann. Wenn ein Client explizit ein "DHCP-Release" macht, sollte er beim nächsten Einschalten/Starten ja auch mit einem DHCP-DISCOVER nach einem DHCP-Server suchen und von der alten Adresse gar nichts mehr wissen (anders als bei einem RENEW) ... da kann man dann auch gleich den Mitschnitt machen und prüfen, daß (a) tatsächlich ein neuer Request erfolgt und ob (b) die Antwort der Box den bereits angesprochenen Namen enthält oder nicht.

Die meisten Geräte machen bei der Umstellung von DHCP auf statisch auch ein solches "RELEASE" ... man kann das danach ja wieder auf DHCP umstellen.

m.kress · 9 Nov 2018

PeterPawn schrieb:
Eben das macht sie ja nicht (hat sie m.W. bisher auch nie (zumindest nicht absichtlich) gemacht für diese "unbenannten" Geräte - wo wurden denn diese "PC-irgendwas"-Namen jemals aufgelöst vom DNS-Server im FRITZ!OS?)

Ja, ich habe keinen anderen DNS Server im Netz.

PeterPawn schrieb:
... wäre irgendjemand der Ansicht, es ist eindeutiger, wenn anstelle des "PC-irgendwas" (also ein, zumindest der Syntax nach, noch "gültiger" Wert) da ein "Gerät ohne Namen 001" steht und diese Nummer hochgezählt wird? Sicherlich nicht ...

Ich stehe bei dieser Frage irgendwie auf dem Schlauch. Der von der FB vergebene PC-irgendwas-Name wird nicht aufgelöst, weshalb ich für diese Geräte eine feste IP jetzt vergeben muss.

PeterPawn schrieb:
wieder der von der FRITZ!Box als "Platzhalter" genutzte gemeint ist, dann erlaube ich mir noch einmal die Frage, wann die Box diesen "Namen" denn jemals aufgelöst hätte.

Ich habe nicht darauf geachtet, seit dann das genau nicht mehr geht. Definitv vor 7.00 hat es noch funktioniert (mit einer 7490). Es funktionierte einfach wie ich es erwartet habe: Bei Geräten ohne Namen wurde einer von FB vergeben (waren das nicht mal Namen mit der Mac-Adresse?). Diesen konnte man dann selbst ändern und wurde auch aufgelöst. Ich habe mir darüber keine Gedanken mehr gemacht, weil das Verhalten für mich völlig normal war.

Ich muss aber auch dazusagen, ich habe meine 7490 durch eine 7590 ersetzt, als die 7490 noch auf 6.xx war und die 7590 schon auf 7.00. In diesem Zuge wurde auch der Repeater 310 gegen einen zweiten 1750E getauscht. Dabei fiel auch ein AVM Powerline-Adapter weg. Die 7590 habe ich clean mit 7.00 konfiguriert (also alles eingegeben).
Danach wurden drei Kameras ins Netz eingehangen. Zwei neue und eine ältere aus dem Schrank. Genau bei dieser ist mir dann das Problem aufgefallen. Aber aufgrund des anderen Devices (dem Sat-Receiver), bin ich mir sicher, dass die Auflösung mit der 7490 und einer 6.xx funktioniert hatte (wie auch bei der 7390, die ich davor hatte).

PeterPawn schrieb:
Wenn es sich (angesichts der Satzstellung aber sehr komisch) doch auf den selbstvergebenen bezieht, da sollte die Box vermutlich den Namen in den DNS-Server übernehmen (und das macht sie ja in bestimmten Konstellationen auch, wie ich oben gezeigt habe) und wenn das wirklich nicht geschieht, wäre das - auch wenn die Mechanismen bei AVM nicht dokumentiert sind und m.W. nirgendwo steht (nicht mal in der Online-Hilfe: https://service.avm.de/help/de/FRITZ-Box-7590/017p2/hilfe_client_details), daß so ein "selbstvergebener Name" dann auch per DNS aufgelöst würde - wohl in den Augen der meisten FRITZ!Box-Besitzer tatsächlich überraschend - selbst wenn nur wenige davon betroffen sein dürften und es ja ggf. sogar noch Möglichkeiten gibt, das irgendwie herbeizuführen..

Sagte ja auch der AVM-Support. Ich war doch sehr überrascht, weil die Funktion für mich seit vielen Jahren selbstverständlich war.

PeterPawn schrieb:
Dahin gehen ja wohl die "Anstrengungen" in diesem Thread oder habe ich das falsch verstanden und das hier ist nur der Kummerkasten für diese Probleme?

Nix Kummerkasten, ich greife z.B. den Datenstrom der Kamera ab, wobei ich den Namen verwenden. Eine feste IP muss ich dafür jetzt halt verwenden. Hatte mich eigentlich schon damit abgefunden, bis ich den Thread gelesen habe.

PeterPawn · 9 Nov 2018

m.kress schrieb:
Ja, ich habe keinen anderen DNS Server im Netz.

Ich schrieb ja auch nicht von einem anderen DNS-Server, meine Frage ging dahin, ob der DNS-Server im FRITZ!OS diese "PC-irgendwas"-Namen jemals aufgelöst hat und wenn ja, wann das gewesen sein soll.

Ich kann mich daran nämlich nicht erinnern, schon jemals in den DNS-Daten irgendeinen Host-Eintrag mit dem Namen "PC-irgendwas" (und das "irgendwas" schließt hier sowohl die MAC- als auch die IPv4-Adresse ein) gesehen zu haben und wenn ich mit einem "grep" über die Support-Dateien gehe, die sich so im Laufe der Zeit bei mir angesammelt haben, finde ich da (zumindest im DNS-Kontext) auch keine solchen Einträge ... wobei die ausführlichere Darstellung durch das "dnsd dump" für den "multid" auch noch nicht so ewig in den Support-Daten enthalten ist.

m.kress schrieb:
Ich stehe bei dieser Frage irgendwie auf dem Schlauch. Der von der FB vergebene PC-irgendwas-Name wird nicht aufgelöst, weshalb ich für diese Geräte eine feste IP jetzt vergeben muss.

Dann nimm doch einfach mal als gegeben hin, daß sich diese Geräte im Netzwerk "nicht identifizieren" - soweit sind wir uns ja wohl einig. Sie geben der FRITZ!Box schlicht keinen einzigen Hinweis, wie sie genannt werden wollen.

Was sollte die FRITZ!Box denn nach Deiner Ansicht jetzt machen? Soll sie die Geräte, weil sie keinen Namen haben, aus der Netzwerkübersicht komplett herauslassen oder ohne jeden Eintrag unter "Name" anzeigen? Was soll sie tun?

Was sie jetzt tut, ist folgendes: Sie verwendet für diese Geräte, die sich ansonsten nicht weiter zu erkennen geben, einfach einen "Phantasienamen" ... statt des "PC-192-168-irgendwas" könnte sie auch 16 Zeichen Zufall verwenden oder irgendetwas anderes, was noch schlechter zu lesen und/oder zu merken ist.

Wenn sie das dann nicht auch noch gleich in das "Netzwerkverzeichnis" in Form des DNS aufnimmt, finde ich das - gerade in Anbetracht der Bedeutung des DNS für korrekte Verbindungen zum tatsächlich gewünschten Ziel - auch durchaus nachvollziehbar ... das muß anderen nicht ebenso gehen, aber ich hätte dann schon gerne ein schlagkräftiges Argument gelesen, warum man einem Gerät mit der IP-Adresse 192.168.178.20 nun unbedingt auch noch den Namen "PC-192-168-178-20" im DNS geben muß. Wenn sich die IP-Adresse des Gerätes ändert, würde sich ja dann auch dieser Name wieder ändern ... der bringt also rein gar nichts, um ein Gerät darüber sicher zu erreichen - außer es geht "um das Gerät, was gerade diese IP-Adresse hat" und das könnte man durch die direkte Verwendung der Adresse auch wieder einfacher haben und braucht dafür keine DNS-Abfrage.

Warum die FRITZ!Box einen "internen Namen" braucht bzw. verwendet, ist hingegen leicht zu erkennen ... nur so kann sie solche Geräte in den Filtereinstellungen oder den Portfreigaben (oder wo die sonst noch gebraucht werden) auch identifizieren bzw. dem Benutzer in einer passenden Form anzeigen, denn intern reicht ihr vermutlich auch schon die MAC-Adresse alleine.

------------------------------------------------------------------------------------

Ich bestreite ja auch nicht, daß die Box nach der Änderung des Namens für den LAN-Client (durch den Benutzer über das GUI) den passenden DNS-Eintrag erzeugen sollte (spätestens beim nächsten REQ bzw. ACK), wenn denn der Client tatsächlich auch eine feste IP-Adresse kriegt (also das "Immer dieselbe Adresse zuweisen" auch wirklich aktiv ist). Ohne diese Option finde ich das nämlich auch schon wieder recht mutig, wenn man einfach für eine Adresse, die sich jederzeit ändern kann (weil sie auch mal einem anderen Client zugewiesen sein könnte), wieder einen festen Namen vergibt und könnte es durchaus nachvollziehen, wenn das FRITZ!OS dann keinen automatischen DNS-Eintrag vornimmt.

Denn das DNS und DHCP sind eben doch zwei verschiedene Paar Schuhe und auch wenn das FRITZ!OS beide gemeinsam verwaltet (so es denn zur DHCP-Adresse einen DNS-Namen erzeugt, weil es sich nicht nur um einen dieser Phantasienamen handelt), kann/darf/soll ein anderer Client im Netz durchaus auch selbst die Ergebnisse vorhergehender DNS-Abfragen cachen (bis die TTL abgelaufen ist) - wenn jetzt plötzlich ein anderer Client die Adresse hat, die zuvor noch einer dieser "Unbenannten" verwendete (ohne sie zu "reservieren" für diesen Client), dann klopft ein anderer LAN-Client auch mal schnell beim falschen (LAN-)Host an, nur weil sein DNS-Cache noch einen alten Eintrag enthält.

Davor ist man zwar auch nicht gefeit, wenn alle Namen im LAN ordentlich vergeben sind ... aber einem Client, der sich mit seinem Namen identifiziert, ordnet das FRITZ!OS ja nach Möglichkeit auch (schon von sich aus) immer wieder dieselbe Adresse zu - da ergibt sich das "immer dieselbe Adresse" schon fast implizit und die Checkbox könnte sich AVM bei solchen Kandidaten eigentlich sparen, solange die Range nicht "ausverkauft" ist und keine neuen, freien IPv4-Adressen mehr zur Verfügung stehen (was bei den meisten Heim-Netzen wohl eher selten passiert, solange die 181er-Range aus den Voreinstellungen verwendet wird), was dann zur "Wiederverwendung" zwingt.

Bei einem "PC-irgendwas"-Eintrag macht sich aber das FRITZ!OS nicht mal die Mühe, sich den zu merken ... schau mal für so einen Eintrag in einer "frischen" Box in die "landevices"-Sektion der "ar7.cfg" - da sollte so ein Eintrag gar nicht auftauchen (in aktueller Firmware) und damit ein Reboot auch nicht überdauern. Wann da der Hausmeister mit dem Besen kommt und alte Einträge automatisch entsorgt, weiß ich auch nicht ... aber den Button "Entfernen" hat auf der Seite "Netzwerkverbindungen" sicherlich auch jeder schon mal gesehen.

------------------------------------------------------------------------------------

Aber zurück zu dem "feste Adresse" und dem eigenen Namen ... ich halte es nicht wirklich für abwegig, daß der DHCP-Server bei der Vergabe der IP-Adresse erst mal ganz genau nachschaut. Dazu hat er ja die "landevices"-Sektion und dort die Einträge "manual_ip" (wenn die Adresse nicht per DHCP vergeben wurde von der FRITZ!Box) und "static_ip" (das ist wohl das "immer dieselbe zuweisen", wobei es auch für Geräte mit "manual_ip=yes" gesetzt ist und daher ein Hint für den (notwendigen) Eintrag im DNS-Server sein könnte).

Wenn es den Eintrag gibt (und zwar zum Zeitpunkt der Vergabe der IP-Adresse), dann sollte auch ein Eintrag im DNS-Server erzeugt werden. Gibt es den nicht und das Gerät kriegt erst hinterher seinen Namen vom FRITZ!Box-Besitzer, könnte ich mir auch vorstellen, daß das wirklich erst beim nächsten Anfordern einer Adresse per DHCP geändert wird im DNS.

Das war ja die Bitte um den zusätzlichen Test aus meinem letzten Beitrag ... vielleicht komme ich heute nacht mal dazu, die Reaktion des FRITZ!OS mit "dhclient" selbst so richtig zu untersuchen. Mir ist nämlich nicht so ganz klar, wo das FRITZ!OS jetzt (in der Netzwerkübersicht) den Unterschied macht, ob das umbenannte Gerät nun seine eigene statische Adresse verwendet oder ob es sich um einen Eintrag handelt, der einem "Unbekannten" (Gerät) von der Box selbst per DHCP zugewiesen wurde. Gut ... letzteres ist eben etwas, was sich ändern könnte - während man bei einem statischen Eintrag (noch dazu einem, den der Besitzer dann umbenannt hat von Hand im GUI) schon unterstellen könnte, daß diese Adresse sich auch nicht alle Nase lang ändert.

Wobei ich eben auch noch so meine "Verständnisprobleme" habe ... was genau ist denn nun mit:

m.kress schrieb:
Diesen konnte man dann selbst ändern und wurde auch aufgelöst.

gemeint? Bezieht sich das "wurde auch aufgelöst" auf den Namen vor oder nach der Änderung im GUI oder gar auf alle beide? Das ist ja wieder der Punkt, nach dem ich schon gefragt habe ... welche FRITZ!OS-Version hat jemals diese "PC-irgendwas"-Namen über den DNS-Server herumerzählt? Und sei es nur bei der Reverse-Auflösung (also bei der Abfrage der IP-Adresse mit einem Namen "PC-irgendwas" geantwortet)? Ich kann mich - auch schon geschrieben - an keine erinnern ... daher die Frage, wann das gewesen sein soll, damit man das mal nachstellen (und überprüfen) kann.

------------------------------------------------------------------------------------

Der DNS-Server hat halt auch noch das Problem, daß er irgendwie aus Sch***** Bonbons machen soll ... eigentlich gibt es keine "ordentliche DNS-Verwaltung" im LAN einer FRITZ!Box (genau für solche Fälle ist aber per se das mDNS gedacht und die Tatsache, daß vernünftige (m)DNS-Clients eben wissen, daß das dort alles nur auf der "Selbstauskunft" beruht und entsprechende Vorsicht geboten ist, wenn man die Infos aus dem DNS für bare Münze nimmt) und das soll dann trotzdem - um nur den Kunden damit nicht zu belästigen - alles automatisch ablaufen.

Damit steht aber sowohl dem Mißbrauch als auch dem -verständnis wieder einiges an Türen offen ... wenn ich ein NAS (mit dem schönen DNS-Namen "NAS") habe, auf dem ein "geheimer" Account sich per (unverschlüsseltem) HTTP mit "basic auth" anmeldet, dann muß ich nur den DNS-Server im FRITZ!OS irgendwie dazu bringen, daß er mich selbst als "nas.fritz.box" führt und die Abfrage des anzugreifenden Clients nach "nas" mit meiner Adresse beantwortet - schwupps, meldet sich der Client eben bei mir an (notfalls kann ich den sogar an das echte NAS weiterreichen) und teilt mir die Account-Daten mit.

Daher sind solche "dynamischen" Namen eben ohnehin immer mit viel Vorsicht zu genießen ... und das FRITZ!OS will hier den Spagat zwischen Sicherheit (u.a. der neue "wpad"-Filter gehört ja auch in diese Kategorie, ebenso der Rebind-Schutz) und Nutzerfreundlichkeit machen, der aber eben nicht immer gelingt.

Schon zwei Geräte im LAN, die sich beide mit derselben "hostname"-Option per DHCP eine Adresse besorgen wollen, bieten reichlich Konfliktstoff - m.W. ist bei kaskadierten FRITZ!Boxen auch immer erst mal "fritz.box" als "hostname" eingestellt (bei den erweiterten DHCP-Einstellungen für das WAN-Interface), was per se schon ein Problem ist, wenn man mit einem eigenen DHCP-Server arbeitet. Wie oft meiner schon den Eintrag "fritz.box.<meine_lokale_domain>" geändert hat, weil eine Box als kaskadierter Router sich eine Adresse holen wollte, weiß ich nicht genau - aber ich weiß, daß der auch Probleme kriegt (nicht nur wegen des zweistufigen Namens), wenn ein zweites Gerät diesen Namen auch gerne hätte. Aber das sind halt alles Probleme, vor denen so ein DNS-Server steht, wenn er "automatisch" arbeiten soll. Es ist also (zumindest nach meiner Überzeugung) alles auch nicht sooo simpel, daß man jetzt irgendwie (ohne Spezifikation bzw. Dokumentation) ein bestimmtes Verhalten voraussetzen könnte bzw. nur das eine dann das richtige Vorgehen wäre. Es mag noch "Gewohnheiten" geben, aber auch die muß man (siehe "wpad"-Filter) immer mal wieder auf den Prüfstand stellen und ihre Auswirkungen abschätzen.

------------------------------------------------------------------------------------

Ich bin ja durchaus auch Deiner Meinung, wenn Du davon ausgehst, daß für einen DHCP-Client (auch wenn der sich nicht selbst mit Namen identifiziert beim DHCP-Request, sondern "nur" mit seiner MAC-Adresse, die er beim DHCP ja mitsenden muß), dem man einen eigenen Namen und "immer dieselbe Adresse verwenden" mitgegeben hat im GUI, am Ende auch ein DNS-Eintrag existieren sollte ... aber der wird eben vielleicht auch erst dann erstellt, wenn sich dieser Client (nach dem Umbenennen in der FRITZ!Box) beim nächsten Mal sein (feste) IPv4-Adresse abholt. Das wäre ja noch zu testen ... oder hast Du das nun schon mal mitgeschnitten, was da beim zweiten DHCP-Dialog passiert?

Ausgangspunkt ist ja bei den Überlegungen und Tests immer die "frische" Box und damit hat der Client beim ersten DHCP-Request eben noch keinen Namen ... erst beim ersten, der dem "Umbenennen" dann folgt. Und auch aus der Sicht des DHCP-Servers dürfte es einen Unterschied machen, ob ein bereits aktiver Client nur seine Adresse erneuern will (dann darf der DHCP-Server ja davon ausgehen, daß alle notwendigen Aktionen bereits bei der ersten Vergabe der Adresse erfolgten - warum sollte er das noch einmal alles checken?) oder ob er einem Client tatsächlich eine "neue" Adresse zuweist, selbst wenn diese ggf. aus einem Eintrag mit einer "festen" Adresse stammt (das wäre dann so einer mit "immer dieselbe").

Wenn man dann noch liest, mit welchen Geräten Du diese Probleme hast und davon ausgehen darf, daß die sicherlich eher "durchlaufen" (auch so ein Receiver wird heutzutage ja eher selten in den "deep standby" geschickt, bei dem auch das Netzwerk dann tot ist - einfach weil er dann auch keine gespeicherten Aufnahmen streamen kann o.ä. und eine IP-Kamera wird sicherlich auch nicht regelmäßig neu gestartet), dann müssen die ja noch nicht zwangsläufig nach dem Versuch des Umbenennens auch eine neue Adresse angefordert haben, wenn sie nur die alte immer wieder verlängert haben.

Theo Tintensich · 9 Nov 2018

Ich glaube, der meint Namen vom Typ

welche die F!B vergibt, wenn es keine anderen Namen gibt.

Bei meinem Netz vergeben ich die Namen in einem eigenen DNS-Server, die dann bei der F!B auch in den Netzwerkeigenschaften verwendet erden, sogar, wenn das Gerät nicht zu lange ausgeschaltet ist (die obigen sind es)

Ich habe es in einem Mesh-Netz mit zwei 7430, FW 7.01, auch festgestellt, dass die zweite F!B nicht im Netz (z.B. per Browser) mit dem Namen erreichbar ist, den ich ihr gegeben habe.

Früher war das wohl möglich. Jetzt nicht mehr.
Wenn man die IP der zweiten F!B nicht hat (ich habe sie in der ersten erst ein auf einen festen Wert gestellt) erreicht man die zweite F!B über ihren 8von mir gegebenen Namen) im Heimnetz-Menü, wo sich hinter dem Namen aber nur ein Link auf die IP befindet.

Ich befürchte, dass dieses die Auswirkungen der Registrierung der TLD .box. sind.
AVM versucht wohl verhindern, dass die Namen ins Internet aufgelöst werden, wo dann Seiten aufgerufen werden, die nicht im Sinne des Benutzers sind.

m.kress · 10 Nov 2018

Vielleicht nochmal zur Erklärung, warum ich die Auflösung dieser Geräte (die mit PC-irgendwas) für sinnvoll halte und verwende:
Ich nutzte den (Host-)Namen um auf die Geräte im Netz zuzugreifen, was i.d.R. auch klappt. Falls man den Hostnamen nicht ändern kann, unterstüzt die FB durch die Möglichkeit des Umbenennens (es gibt Microcontroller, bei denen der Hostname nach dem Reboot fest eingestellt ist). Ich versuche wo es geht auch DHCP zu verwenden, um z.B. wenn das Gerät an ein anderes (Test-)Netz oder bei Änderungen am Netzwerk die Geräte nicht umkonfigurieren zu müssen. Das alles funktioniert auch bei den meisten Geräten. Kein Thema. Keine Liste mit vergeben festen IP pflegen, denn ich habe nur zwei fest vergeben, bei 40 Geräten mit DHCP im Netz.

Jetzt gibt es Geräte für welche die FB keinen Namen ermitteln kann. Es wird von der FB ein Name aus "PC-" und "DHCP-IP" vergeben. Ggf. wird dieser sogar per DHCP Option 12 übermittelt. Solange sich die per DHCP vergebene IP nicht ändert, könnte man diesen Namen verwenden. Aber das geht nicht, was ich jetzt verstehen kann. Es macht keinen Sinn macht, weil der Name die per DHCP vergebene IP enthält (ggf. war deshalb früher mal die MAC statt IP drin). Jetzt ändere ich den Namen "PC-irgendwas" manuell. Die FB könnte das Gerät mittels MAC identifizieren und auch die gleiche IP vergeben (analog "immer gleiche IP vergeben", nur diesen in diesem Falle nicht explizit angehakt ist). Das hatte ich auch so irgendwann mal gelesen. Eigentlich wäre alles gut: Ich kann das mit DHCP konfigurierte Gerät mit seinem Namen ansprechen, ohne das ein Name in der FB ermittelt werden konnte. Die Software mit dem ich auf das Gerät zugreife, kennt vom Gerät nur den Namen. Ich muss nur an einer Stelle drehen, wenn das Gerät ersetze oder es in ein andereres Netz hänge: In der FB.

andilao · 10 Nov 2018

Theo Tintensich schrieb:
Ich glaube, der meint Namen vom Typ (bild) welche die F!B vergibt, wenn es keine anderen Namen gibt.

Diese generischen Hostnamen wurden von meinen Fritzboxen aus den Mac-Adressen von WLAN-Geräten gebildet, die sich nicht erfolgreich anmelden konnten und logischerweise keine IP-Adressen erhalten konnten, IMHO eine andere Geschichte.

sf3978 · 10 Nov 2018

m.kress schrieb:
Vielleicht nochmal zur Erklärung, warum ich die Auflösung dieser Geräte (die mit PC-irgendwas) für sinnvoll halte und verwende:

Naja, ich denke das tatsächliche bzw. wahre Problem ist, wenn man mit der V7.0 (und >) keinen _lokalen_ A-/AAAA-record mit nsupdate (oder gleichwertig) in der FritzBox mehr registrieren kann.

m.kress · 12 Nov 2018

sf3978 schrieb:
Naja, ich denke das tatsächliche bzw. wahre Problem ist, wenn man mit der V7.0 (und >) keinen _lokalen_ A-/AAAA-record mit nsupdate (oder gleichwertig) in der FritzBox mehr registrieren kann.

Ich glaube auch, dass es zumindest es damit zusammenhängt.

Wie ich erst jetzt getestet habe, ist mein Problem auch unabhängig vom DHCP. Ich wenn ich eine feste IP vergebe (außerhalb des DHCP-Bereiches), kann ich zwar einen Namen in FB vergeben, aber aufgelöst wird dieser nicht.

PeterPawn · 12 Nov 2018

m.kress schrieb:
wenn ich eine feste IP vergebe (außerhalb des DHCP-Bereiches), kann ich zwar einen Namen in FB vergeben, aber aufgelöst wird dieser nicht.

Das ist aber dann wieder definitiv nicht bei jeder 07.01 so ... das hatte ich mit dem Umbenennen der 192.168.178.10 in "thor" ja ein paar Beiträge weiter vorne gezeigt.

m.kress schrieb:
Ich glaube auch, dass es zumindest es damit zusammenhängt.

Woher weißt Du denn, daß Deine zwei "Problemgeräte" ihrerseits mittels "nsupdate" versuchen, irgendeinen Namen dort einzutragen? Hast Du das in irgendeinem Mitschnitt mal gesehen und kannst es uns zeigen?

sf3978 · 12 Nov 2018

PeterPawn schrieb:
... mittels "nsupdate" versuchen, irgendeinen Namen dort einzutragen? Hast Du das in irgendeinem Mitschnitt mal gesehen und kannst es uns zeigen?

Lt. Beitrag #34 hat er _manuell_ versucht, mit nsupdate einen A-record in seiner FB zu registrieren und das hat nicht funktioniert. Es kam die Meldung:

Code:

; Communication with 192.168.201.254#53 failed: timed out
dns_request_createvia3: not implemented

EDIT:

@m.kress

Versuch mal ernuet, mit tcp und im debug mode:

Code:

nsupdate -v -d -D

m.kress · 12 Nov 2018

Nochmals inkl. tcpdump:

nsupdate:

Code:

# nsupdate -v -d -D -L 10
setup_system()
12-Nov-2018 13:42:22.335 dns_requestmgr_create
12-Nov-2018 13:42:22.335 dns_requestmgr_create: 0xb4d49f08
reset_system()
user_interaction()
> server 192.168.201.254
do_next_command()
> update add ipcam3.fritz.box 600 a 192.168.201.34
do_next_command()
evaluate_update()
update_addordelete()
> send
do_next_command()
start_update()
12-Nov-2018 13:42:46.868 dns_request_createvia
12-Nov-2018 13:42:46.875 request_render
12-Nov-2018 13:42:46.875 requestmgr_attach: 0xb4d49f08: eref 1 iref 1
12-Nov-2018 13:42:46.875 mgr_gethash
12-Nov-2018 13:42:46.875 req_send: request 0xb4d51108
12-Nov-2018 13:42:46.876 dns_request_createvia: request 0xb4d51108
12-Nov-2018 13:42:46.876 req_senddone: request 0xb4d51108
12-Nov-2018 13:42:46.877 req_response: request 0xb4d51108: success
12-Nov-2018 13:42:46.878 req_cancel: request 0xb4d51108
12-Nov-2018 13:42:46.878 req_sendevent: request 0xb4d51108
recvsoa()
About to create rcvmsg
12-Nov-2018 13:42:46.878 dns_request_getresponse: request 0xb4d51108
show_message()
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id:  29150
;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ipcam3.fritz.box.              IN      SOA

;; AUTHORITY SECTION:
fritz.box.              9       IN      SOA     fritz.box. admin.fritz.box. 1542026566 21600 1800 43200 10

Found zone name: fritz.box
The master is: fritz.box
send_update()
Sending update to 192.168.201.254#53
12-Nov-2018 13:42:46.880 dns_request_createvia
12-Nov-2018 13:42:46.880 request_render
12-Nov-2018 13:42:46.881 requestmgr_attach: 0xb4d49f08: eref 1 iref 2
12-Nov-2018 13:42:46.881 mgr_gethash
12-Nov-2018 13:42:46.881 dns_request_createvia: request 0xb4d55308
show_message()
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  42811
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 0
;; UPDATE SECTION:
ipcam3.fritz.box.       600     IN      A       192.168.201.34

12-Nov-2018 13:42:46.882 dns_request_destroy: request 0xb4d51108
12-Nov-2018 13:42:46.882 req_destroy: request 0xb4d51108
12-Nov-2018 13:42:46.882 requestmgr_detach: 0xb4d49f08: eref 1 iref 1
Out of recvsoa
12-Nov-2018 13:42:46.882 req_connected: request 0xb4d55308
12-Nov-2018 13:42:46.882 req_send: request 0xb4d55308
12-Nov-2018 13:42:46.882 req_senddone: request 0xb4d55308
12-Nov-2018 13:43:01.878 dispatch 0xb4d45878 response 0xb4d54788 192.168.201.254#53: cancel: failsafe event 0xb4d48c08 -> task 0xb4d30f88
12-Nov-2018 13:43:01.878 req_response: request 0xb4d55308: unexpected error
12-Nov-2018 13:43:01.878 req_cancel: request 0xb4d55308
12-Nov-2018 13:43:01.878 req_sendevent: request 0xb4d55308
update_completed()
; Communication with 192.168.201.254#53 failed: unexpected error
recvsoa: trying next server
Destroying request [0xb4d55308]
12-Nov-2018 13:43:01.878 dns_request_destroy: request 0xb4d55308
12-Nov-2018 13:43:01.878 req_destroy: request 0xb4d55308
12-Nov-2018 13:43:01.878 requestmgr_detach: 0xb4d49f08: eref 1 iref 0
send_update()
../../../lib/dns/name.c:1002: REQUIRE((((source) != ((void *)0)) && (((const isc__magic_t *)(source))->magic == ((('D') << 24 | ('N') << 16 | ('S') << 8 | ('n')))))) failed, back trace
#0 0xb70a6846 in ??
#1 0xb70a6775 in ??
#2 0xb752fee0 in ??
#3 0x5030e8 in ??
#4 0x504a9d in ??
#5 0x5060b9 in ??
#6 0xb70cbdf4 in ??
#7 0xb707427a in ??
#8 0xb6d36ae6 in ??
Abgebrochen

tcpdump:

Code:

13:42:46.881660 IP 192.168.201.253.43379 > 192.168.201.254.53: Flags [S], seq 3730272205, win 29200, options [mss 1460,sackOK,TS val 46364666 ecr 0,nop,wscale 7], length 0
13:42:46.882141 IP 192.168.201.253.43379 > 192.168.201.254.53: Flags [.], ack 2458768476, win 229, options [nop,nop,TS val 46364666 ecr 234943400], length 0
13:42:46.882664 IP 192.168.201.253.43379 > 192.168.201.254.53: Flags [P.], seq 0:52, ack 1, win 229, options [nop,nop,TS val 46364667 ecr 234943400], length 5242811 update [1n] SOA? fritz.box. (50)
13:43:01.882265 IP 192.168.201.253.43379 > 192.168.201.254.53: Flags [F.], seq 52, ack 2, win 229, options [nop,nop,TS val 46368416 ecr 234947149], length 0

nmap:

Code:

# nmap 192.168.201.254

Starting Nmap 7.40 ( https://nmap.org ) at 2018-11-12 13:47 CET
Nmap scan report for fritz.box (192.168.201.254)
Host is up (0.00045s latency).
Not shown: 993 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
5060/tcp open  sip
8181/tcp open  intermapper
MAC Address: 44:4E:6D:76:D9:D8 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 2.13 seconds

sf3978 · 12 Nov 2018

m.kress schrieb:

Nochmals inkl. tcpdump:

tcpdump:

Code:

13:42:46.881660 IP 192.168.201.253.43379 > 192.168.201.254.53: Flags [S], seq 3730272205, win 29200, options [mss 1460,sackOK,TS val 46364666 ecr 0,nop,wscale 7], length 0
13:42:46.882141 IP 192.168.201.253.43379 > 192.168.201.254.53: Flags [.], ack 2458768476, win 229, options [nop,nop,TS val 46364666 ecr 234943400], length 0
13:42:46.882664 IP 192.168.201.253.43379 > 192.168.201.254.53: Flags [P.], seq 0:52, ack 1, win 229, options [nop,nop,TS val 46364667 ecr 234943400], length 5242811 update [1n] SOA? fritz.box. (50)
13:43:01.882265 IP 192.168.201.253.43379 > 192.168.201.254.53: Flags [F.], seq 52, ack 2, win 229, options [nop,nop,TS val 46368416 ecr 234947149], length 0

Das ist nur der Traffic vom Client zur FritzBox (DNS-Server).
Versuch mal mit:

Code:

tcpdump -vvveni <Interface> host 192.168.201.254 and tcp port 53

(Interface anpassen und ohne spitze Klammern).

m.kress · 12 Nov 2018

Code:

# tcpdump -vvveni eth0 host 192.168.201.254 and tcp port 53
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:02:28.697820 00:30:48:dd:d1:72 > 44:4e:6d:76:d9:d8, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 31505, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.201.253.45625 > 192.168.201.254.53: Flags [S], cksum 0xaa97 (correct), seq 3697594025, win 29200, options [mss 1460,sackOK,TS val 47560120 ecr 0,nop,wscale 7], length 0
15:02:28.698121 44:4e:6d:76:d9:d8 > 00:30:48:dd:d1:72, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.201.254.53 > 192.168.201.253.45625: Flags [S.], cksum 0x1f45 (correct), seq 1239169901, ack 3697594026, win 14480, options [mss 1460,sackOK,TS val 236138854 ecr 47560120,nop,wscale 6], length 0
15:02:28.698363 00:30:48:dd:d1:72 > 44:4e:6d:76:d9:d8, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 31506, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.201.253.45625 > 192.168.201.254.53: Flags [.], cksum 0x85ba (correct), seq 1, ack 1, win 229, options [nop,nop,TS val 47560121 ecr 236138854], length 0
15:02:28.705244 00:30:48:dd:d1:72 > 44:4e:6d:76:d9:d8, ethertype IPv4 (0x0800), length 118: (tos 0x0, ttl 64, id 31507, offset 0, flags [DF], proto TCP (6), length 104)
    192.168.201.253.45625 > 192.168.201.254.53: Flags [P.], cksum 0xb431 (correct), seq 1:53, ack 1, win 229, options [nop,nop,TS val 47560122 ecr 236138854], length 5248305 update [1n] SOA? fritz.box. ns: ipcam3.fritz.box. [10m] A 192.168.201.34 (50)
15:02:28.705496 44:4e:6d:76:d9:d8 > 00:30:48:dd:d1:72, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 2568, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.201.254.53 > 192.168.201.253.45625: Flags [.], cksum 0x8585 (correct), seq 1, ack 53, win 227, options [nop,nop,TS val 236138856 ecr 47560122], length 0
15:02:43.695653 44:4e:6d:76:d9:d8 > 00:30:48:dd:d1:72, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 2569, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.201.254.53 > 192.168.201.253.45625: Flags [F.], cksum 0x76e1 (correct), seq 1, ack 53, win 227, options [nop,nop,TS val 236142603 ecr 47560122], length 0
15:02:43.698344 00:30:48:dd:d1:72 > 44:4e:6d:76:d9:d8, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 31508, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.201.253.45625 > 192.168.201.254.53: Flags [.], cksum 0x683a (correct), seq 53, ack 2, win 229, options [nop,nop,TS val 47563871 ecr 236142603], length 0
15:02:43.700812 00:30:48:dd:d1:72 > 44:4e:6d:76:d9:d8, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 31509, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.201.253.45625 > 192.168.201.254.53: Flags [F.], cksum 0x6839 (correct), seq 53, ack 2, win 229, options [nop,nop,TS val 47563871 ecr 236142603], length 0
15:02:43.701141 44:4e:6d:76:d9:d8 > 00:30:48:dd:d1:72, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 21219, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.201.254.53 > 192.168.201.253.45625: Flags [.], cksum 0x683a (correct), seq 2, ack 54, win 227, options [nop,nop,TS val 236142604 ecr 47563871], length 0
^C
9 packets captured
9 packets received by filter
0 packets dropped by kernel

Ich habe den nsupdate auch von einem anderen System abgesetzt. Identischer Fehler.

PeterPawn · 12 Nov 2018

Das sieht bei mir in etwa ebenso aus ... nur daß ich eben die WS-Dissektoren benutze und nicht die vom "tcpdump".

Denn mit denen stellt sich ja schon die Frage, ob die Längenangabe von 5248035 Byte stimmen könnte, die der Dissector da für das Update anzeigt ... wenn ja, fehlen dem "multid" wohl noch jede Menge Daten (denn das reale Paket ist ja gerade mal 104 Byte groß, wie die Zeile zum IPv4-Header darüber verrät) und es wäre verständlich, warum der in Wirklichkeit gar keine Reaktion auf das vierte Paket zeigt. Denn schaut man sich die Flags an, ist da keine Antwort - nur das ACK für den Empfang des Requests. Es startet mit dem SYN vom Client, der Server antwortet mit seinem SYN und der Client bestätigt den Verbindungsaufbau mit ACK. Danach kommt der Update-Request vom Client und vom Server noch genau das erwähnte ACK ... nunmehr kehrt für 15 Sekunden Ruhe ein, bevor der Server mit FIN die Verbindung schließt, was der Client mit ACK quittiert und wo er dann seinerseits noch ein FIN hinterherschickt, welches wieder der Server quittiert.

Da kommt also keine Antwort mit einem Fehler ... es kommt schlicht gar keine.

Wobei hier ohnehin wieder jede Menge "Rahmenbedingungen" hineinspielen ... denn wie man im Debug-Log des "nsupdate" sieht, vergewissert sich dieses Kommando erst mal mit einer SOA-Abfrage, wer denn nun eigentlich der zuständige Server wäre ... davon ist im "tcpdump" dann wieder gar nichts zu sehen und die einzige, halbwegs plausible Erklärung ist ein lokaler Resolver-Cache, der die SOA-Abfrage beim Server überflüssig machte oder die Ausgabe des "tcpdump" wurde "redigiert". Ich tendiere ja zu ersterem ...

---------------------------------------------------------------------------------------------------------------------

Der AVM-NS versteht/benutzt ja u.a. auch DNS-Cookies (RFC 7873, speziell Punkt 5.1 und 5.2) - die sieht man aber nicht, wenn man nicht wirklich "tief" (eben z.B. mit den WS-Dissektoren) in die Pakete schaut.

Ich weiß nicht, was AVM hier tatsächlich macht bzw. erwartet ... mein Verdacht geht einfach in die Richtung, daß da die Implementierung noch ihre Schwächen hat - auch wenn ich nicht weiß (und nicht testen will), wie weit das mit den Cookies zurückreicht.

Ich kriege z.B. von einem DNS-Server (in der 7580, Version 07.01) auch für unbekannte Hosts eine Antwort (halt ein NXDOMAIN, wobei man bei solchen Abfragen auch immer das "(no)search" explizit angeben sollte, wenn man "dig" benutzt), diese enthält aber ab der zweiten Antwort nicht mehr den Keks, den der Client für die/bei der Abfrage vorgegeben hat, sondern den aus der ersten Abfrage, welcher vom Server immer wiederholt wird (was eigentlich falsch ist nach RFC 7873, Punkt 5.2):

Code:

vidar:~ $ dig @192.168.178.1 +nosearch +tcp nohost2 any

; <<>> DiG 9.11.2 <<>> @192.168.178.1 +nosearch +tcp nohost2 any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5322
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 3cd10396ecee132ee35b65c55be99a57bc7724f93b22ee08 (good)
;; QUESTION SECTION:
;nohost2.                       IN      ANY

;; AUTHORITY SECTION:
.                       10800   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2018111200 1800 900 604800 86400

;; Query time: 111 msec
;; SERVER: 192.168.178.1#53(192.168.178.1)
;; WHEN: Mon Nov 12 16:20:55 CET 2018
;; MSG SIZE  rcvd: 139

vidar:~ $ dig @192.168.178.1 +nosearch +tcp nohost2 any
;; Warning: Client COOKIE mismatch

; <<>> DiG 9.11.2 <<>> @192.168.178.1 +nosearch +tcp nohost2 any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51722
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 3cd10396ecee132ee35b65c55be99a57bc7724f93b22ee08 (bad)
;; QUESTION SECTION:
;nohost2.                       IN      ANY

;; AUTHORITY SECTION:
.                       10798   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2018111200 1800 900 604800 86400

;; Query time: 2 msec
;; SERVER: 192.168.178.1#53(192.168.178.1)
;; WHEN: Mon Nov 12 16:20:58 CET 2018
;; MSG SIZE  rcvd: 139

vidar:~ $ dig @192.168.178.1 +nosearch +tcp nohost2 any
;; Warning: Client COOKIE mismatch

; <<>> DiG 9.11.2 <<>> @192.168.178.1 +nosearch +tcp nohost2 any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62135
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 3cd10396ecee132ee35b65c55be99a57bc7724f93b22ee08 (bad)
;; QUESTION SECTION:
;nohost2.                       IN      ANY

;; AUTHORITY SECTION:
.                       10781   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2018111200 1800 900 604800 86400

;; Query time: 1 msec
;; SERVER: 192.168.178.1#53(192.168.178.1)
;; WHEN: Mon Nov 12 16:21:15 CET 2018
;; MSG SIZE  rcvd: 139

vidar:~ $

Ob das bei der 7490 auch so wäre (und ob das ggf. nur bei TCP der Fall ist - bei der 7580 ist das L4-Protokoll egal, auch was das Cookie-Problem angeht), kann ich nicht ermitteln, weil ich von der 7490 gar keine Antwort erhalte (das ist analog zum Update-Request mit "nsupdate"), wenn ich einen unbekannten Host abfrage, ohne dabei die Domain mit anzugeben: Das ist allerdings bei der 7490 immer dieselbe Reaktion ... egal ob ich mit TCP oder UDP zugreife. Nur wird bei UDP halt die Abfrage noch ein paar Mal wiederholt, was insgesamt länger braucht, bis vom "dig" dann ein Timeout diagnostiziert wird.

Code:

vidar:~ $ dig @192.168.130.1 +tcp +nosearch nohost2 any

; <<>> DiG 9.11.2 <<>> @192.168.130.1 +tcp +nosearch nohost2 any
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
vidar:~ $ dig @192.168.130.1 +notcp +nosearch nohost2 any

; <<>> DiG 9.11.2 <<>> @192.168.130.1 +notcp +nosearch nohost2 any
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
vidar:~ $ dig @192.168.130.1 +notcp +nosearch nohost2.fritz.box. any

; <<>> DiG 9.11.2 <<>> @192.168.130.1 +notcp +nosearch nohost2.fritz.box. any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54496
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;nohost2.fritz.box.             IN      ANY

;; AUTHORITY SECTION:
fritz.box.              9       IN      SOA     fritz.box. admin.fritz.box. 1542035777 21600 1800 43200 10

;; Query time: 0 msec
;; SERVER: 192.168.130.1#53(192.168.130.1)
;; WHEN: Mon Nov 12 16:16:17 CET 2018
;; MSG SIZE  rcvd: 77

vidar:~ $ dig @192.168.130.1 +notcp +nosearch vidar any

; <<>> DiG 9.11.2 <<>> @192.168.130.1 +notcp +nosearch vidar any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52001
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3

;; QUESTION SECTION:
;vidar.                         IN      ANY

;; ANSWER SECTION:
vidar.                  9       IN      A       192.168.130.2

;; AUTHORITY SECTION:
vidar.                  9       IN      NS      fritz.box.

;; ADDITIONAL SECTION:
fritz.box.              9       IN      A       192.168.130.1
fritz.box.              9       IN      AAAA    fd00::...
fritz.box.              9       IN      AAAA    ...

;; Query time: 0 msec
;; SERVER: 192.168.130.1#53(192.168.130.1)
;; WHEN: Mon Nov 12 16:16:35 CET 2018
;; MSG SIZE  rcvd: 134

vidar:~ $

Diese "Unklarheiten" sind auch der Grund, warum ich hier zwischen dem Datenbestand des DNS-Servers (den man sich eben in den Support-Daten ansehen muß, wenn man keinen Shell-Zugang hat/will) und den Abfragen unterscheiden möchte bzw. warum man das schon sehr konkret angeben sollte, womit man seine Abfragen gemacht und das Problem festgestellt hat.

Denn eigentlich sollte ein Client die Antwort eines Servers ignorieren, wenn dieser mit einem falschen Cookie antwortet ... das ist ja eine Maßnahme gegen "cache poisoning" bzw. "amplification attacks" (wo der Client mit Antworten zugeschüttet wird) und wenn der Client das korrekt umsetzt und diese Antwort ignoriert (so denn eine kommt, denn beim "nsupdate" (auch bei @m.kress) und beim Abfragen der 7490 für einen nicht vorhandenen Namen gibt es ja keine, auch keine mit falschem Cookie), dann wäre das "nach außen sichtbare Ergebnis" ja auch ein "unbekannter Host", was man leicht mit "nicht im DNS-Bestand" verwechseln könnte.

sf3978 · 12 Nov 2018

m.kress schrieb:
... nsupdate auch von einem anderen System abgesetzt. Identischer Fehler.

Hier eine funktionierende Registrierung, mit der Firmware 6.52:

Code:

:~$ nsupdate -v -d -D -L 10
setup_system()
12-Nov-2018 18:25:02.103 dns_requestmgr_create
12-Nov-2018 18:25:02.103 dns_requestmgr_create: 0xb55def08
reset_system()
user_interaction()
> server 192.168.178.1
do_next_command()
> zone fritz.box
do_next_command()
> update add ipcam7.fritz.box 1800 A 192.168.178.29
do_next_command()
evaluate_update()
update_addordelete()
> send
do_next_command()
start_update()
send_update()
Sending update to 192.168.178.1#53
12-Nov-2018 18:26:16.357 dns_request_createvia
12-Nov-2018 18:26:16.358 request_render
12-Nov-2018 18:26:16.358 requestmgr_attach: 0xb55def08: eref 1 iref 1
12-Nov-2018 18:26:16.358 mgr_gethash
12-Nov-2018 18:26:16.358 dns_request_createvia: request 0xb55ddf08
show_message()
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  19033
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 0
;; ZONE SECTION:
;fritz.box.            IN    SOA

;; UPDATE SECTION:
ipcam7.fritz.box.    1800    IN    A    192.168.178.29

12-Nov-2018 18:26:16.361 req_connected: request 0xb55ddf08
12-Nov-2018 18:26:16.361 req_send: request 0xb55ddf08
12-Nov-2018 18:26:16.361 req_senddone: request 0xb55ddf08
12-Nov-2018 18:26:16.367 req_response: request 0xb55ddf08: success
12-Nov-2018 18:26:16.367 req_cancel: request 0xb55ddf08
12-Nov-2018 18:26:16.368 req_sendevent: request 0xb55ddf08
update_completed()
12-Nov-2018 18:26:16.368 dns_request_getresponse: request 0xb55ddf08
12-Nov-2018 18:26:16.368 message has 23 byte(s) of trailing garbage
show_message()

Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  19033
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; ZONE SECTION:
;fritz.box.            IN    SOA

12-Nov-2018 18:26:16.368 dns_request_destroy: request 0xb55ddf08
12-Nov-2018 18:26:16.368 req_destroy: request 0xb55ddf08
12-Nov-2018 18:26:16.368 requestmgr_detach: 0xb55def08: eref 1 iref 0
done_update()
reset_system()
user_interaction()
> quit
do_next_command()
cleanup()
Shutting down task manager
shutdown_program()
Shutting down request manager
12-Nov-2018 18:26:23.210 dns_requestmgr_shutdown: 0xb55def08
12-Nov-2018 18:26:23.210 send_shutdown_events: 0xb55def08
Destroy DST lib
Destroying request manager
12-Nov-2018 18:26:23.212 dns_requestmgr_detach: 0xb55def08: eref 0 iref 0
12-Nov-2018 18:26:23.212 mgr_destroy
Freeing the dispatchers
Shutting down dispatch manager
Destroying event
Shutting down socket manager
Shutting down timer manager
Destroying hash context
Destroying name state
Removing log context
Destroying memory context

Code:

# tcpdump -vvveni wlan1 host 192.168.178.1 and tcp port 53
tcpdump: listening on wlan1, link-type EN10MB (Ethernet), capture size 262144 bytes
18:26:16.358334 48:02:2a:17:62:b4 > c0:25:06:2b:52:de, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 64, id 30732, offset 0, flags [DF], proto TCP (6), length 56)
    192.168.178.22.44950 > 192.168.178.1.53: Flags [S], cksum 0xde3f (correct), seq 4223439399, win 28640, options [mss 1432,sackOK,TS val 387627 ecr 0], length 0
18:26:16.361070 c0:25:06:2b:52:de > 48:02:2a:17:62:b4, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 56)
    192.168.178.1.53 > 192.168.178.22.44950: Flags [S.], cksum 0x07f3 (correct), seq 3390436002, ack 4223439400, win 5792, options [mss 1460,sackOK,TS val 122383388 ecr 387627], length 0
18:26:16.361192 48:02:2a:17:62:b4 > c0:25:06:2b:52:de, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 30733, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.178.22.44950 > 192.168.178.1.53: Flags [.], cksum 0xc96f (correct), seq 1, ack 1, win 28640, options [nop,nop,TS val 387628 ecr 122383388], length 0
18:26:16.361428 48:02:2a:17:62:b4 > c0:25:06:2b:52:de, ethertype IPv4 (0x0800), length 118: (tos 0x0, ttl 64, id 30734, offset 0, flags [DF], proto TCP (6), length 104)
    192.168.178.22.44950 > 192.168.178.1.53: Flags [P.], cksum 0x7c91 (correct), seq 1:53, ack 1, win 28640, options [nop,nop,TS val 387628 ecr 122383388], length 5219033 update [1n] SOA? fritz.box. ns: ipcam7.fritz.box. [30m] A 192.168.178.29 (50)
18:26:16.365320 c0:25:06:2b:52:de > 48:02:2a:17:62:b4, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 40638, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.178.1.53 > 192.168.178.22.44950: Flags [.], cksum 0x227b (correct), seq 1, ack 53, win 5792, options [nop,nop,TS val 122383389 ecr 387628], length 0
18:26:16.367811 c0:25:06:2b:52:de > 48:02:2a:17:62:b4, ethertype IPv4 (0x0800), length 118: (tos 0x0, ttl 64, id 40639, offset 0, flags [DF], proto TCP (6), length 104)
    192.168.178.1.53 > 192.168.178.22.44950: Flags [P.], cksum 0x559d (correct), seq 1:53, ack 53, win 5792, options [nop,nop,TS val 122383389 ecr 387628], length 5219033 update- q: SOA? fritz.box. 0/0/0 (50)
18:26:16.367873 48:02:2a:17:62:b4 > c0:25:06:2b:52:de, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 30735, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.178.22.44950 > 192.168.178.1.53: Flags [.], cksum 0xc904 (correct), seq 53, ack 53, win 28640, options [nop,nop,TS val 387630 ecr 122383389], length 0
18:26:16.407447 c0:25:06:2b:52:de > 48:02:2a:17:62:b4, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 40640, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.178.1.53 > 192.168.178.22.44950: Flags [F.], cksum 0x2240 (correct), seq 53, ack 53, win 5792, options [nop,nop,TS val 122383393 ecr 387630], length 0
18:26:16.443686 48:02:2a:17:62:b4 > c0:25:06:2b:52:de, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 30736, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.178.22.44950 > 192.168.178.1.53: Flags [.], cksum 0xc8ec (correct), seq 53, ack 54, win 28640, options [nop,nop,TS val 387649 ecr 122383393], length 0
18:26:23.211396 48:02:2a:17:62:b4 > c0:25:06:2b:52:de, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 30737, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.178.22.44950 > 192.168.178.1.53: Flags [F.], cksum 0xc250 (correct), seq 53, ack 54, win 28640, options [nop,nop,TS val 389340 ecr 122383393], length 0
18:26:23.213790 c0:25:06:2b:52:de > 48:02:2a:17:62:b4, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.178.1.53 > 192.168.178.22.44950: Flags [.], cksum 0x18e8 (correct), seq 54, ack 54, win 5792, options [nop,nop,TS val 122384074 ecr 389340], length 0
^C
11 packets captured
11 packets received by filter
0 packets dropped by kernel

Code:

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

ipcam7.fritz.box has address 192.168.178.29

Code:

:~$ dig -x 192.168.178.29 +short
ipcam7.fritz.box.

m.kress · 14 Nov 2018

Ich habe testweise mal die 7390 (FRITZ!OS: 06.85) ins Netz gehangen. nsupdate lief einwandfrei durch, die Auflösung wird auch durchgeführt:

Code:

# nsupdate -v -d -D -L 10
setup_system()
14-Nov-2018 10:19:11.126 dns_requestmgr_create
14-Nov-2018 10:19:11.126 dns_requestmgr_create: 0xb4d16f08
reset_system()
user_interaction()
> server 192.168.201.252
do_next_command()
> update add ipcam3.fritz.box 600 a 192.168.201.34
do_next_command()
evaluate_update()
update_addordelete()
> send
do_next_command()
start_update()
14-Nov-2018 10:19:33.468 dns_request_createvia
14-Nov-2018 10:19:33.473 request_render
14-Nov-2018 10:19:33.473 requestmgr_attach: 0xb4d16f08: eref 1 iref 1
14-Nov-2018 10:19:33.473 mgr_gethash
14-Nov-2018 10:19:33.473 req_send: request 0xb4d1e108
14-Nov-2018 10:19:33.473 dns_request_createvia: request 0xb4d1e108
14-Nov-2018 10:19:33.475 req_senddone: request 0xb4d1e108
14-Nov-2018 10:19:33.475 req_response: request 0xb4d1e108: success
14-Nov-2018 10:19:33.475 req_cancel: request 0xb4d1e108
14-Nov-2018 10:19:33.475 req_sendevent: request 0xb4d1e108
recvsoa()
About to create rcvmsg
14-Nov-2018 10:19:33.476 dns_request_getresponse: request 0xb4d1e108
show_message()
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id:  14701
;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ipcam3.fritz.box.              IN      SOA

;; AUTHORITY SECTION:
fritz.box.              9       IN      SOA     fritz.box. admin.fritz.box. 1542187173 21600 1800 43200 10

Found zone name: fritz.box
The master is: fritz.box
send_update()
Sending update to 192.168.201.252#53
14-Nov-2018 10:19:33.476 dns_request_createvia
14-Nov-2018 10:19:33.478 request_render
14-Nov-2018 10:19:33.479 requestmgr_attach: 0xb4d16f08: eref 1 iref 2
14-Nov-2018 10:19:33.480 mgr_gethash
14-Nov-2018 10:19:33.480 dns_request_createvia: request 0xb4d22308
show_message()
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  42570
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 0
;; UPDATE SECTION:
ipcam3.fritz.box.       600     IN      A       192.168.201.34

14-Nov-2018 10:19:33.482 dns_request_destroy: request 0xb4d1e108
14-Nov-2018 10:19:33.482 req_destroy: request 0xb4d1e108
14-Nov-2018 10:19:33.482 requestmgr_detach: 0xb4d16f08: eref 1 iref 1
Out of recvsoa
14-Nov-2018 10:19:33.482 req_connected: request 0xb4d22308
14-Nov-2018 10:19:33.482 req_send: request 0xb4d22308
14-Nov-2018 10:19:33.483 req_senddone: request 0xb4d22308
14-Nov-2018 10:19:33.486 req_response: request 0xb4d22308: success
14-Nov-2018 10:19:33.486 req_cancel: request 0xb4d22308
14-Nov-2018 10:19:33.487 req_sendevent: request 0xb4d22308
update_completed()
14-Nov-2018 10:19:33.487 dns_request_getresponse: request 0xb4d22308
14-Nov-2018 10:19:33.487 message has 23 byte(s) of trailing garbage
show_message()

Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  42570
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; ZONE SECTION:
;fritz.box.                     IN      SOA

14-Nov-2018 10:19:33.487 dns_request_destroy: request 0xb4d22308
14-Nov-2018 10:19:33.487 req_destroy: request 0xb4d22308
14-Nov-2018 10:19:33.487 requestmgr_detach: 0xb4d16f08: eref 1 iref 0
done_update()
reset_system()
user_interaction()
> man nslookup
do_next_command()
incorrect section name: man
> exit
do_next_command()
incorrect section name: exit
> quit
do_next_command()
cleanup()
Shutting down task manager
shutdown_program()
Shutting down request manager
14-Nov-2018 10:19:54.988 dns_requestmgr_shutdown: 0xb4d16f08
14-Nov-2018 10:19:54.988 send_shutdown_events: 0xb4d16f08
Destroy DST lib
Destroying request manager
14-Nov-2018 10:19:54.990 dns_requestmgr_detach: 0xb4d16f08: eref 0 iref 0
14-Nov-2018 10:19:54.990 mgr_destroy
Freeing the dispatchers
Shutting down dispatch manager
Destroying event
Shutting down socket manager
Shutting down timer manager
Destroying hash context
Destroying name state
Removing log context
Destroying memory context

Code:

# dig @192.168.201.252 ipcam3

; <<>> DiG 9.10.3-P4-Debian <<>> @192.168.201.252 ipcam3
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28362
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ipcam3.                                IN      A

;; ANSWER SECTION:
ipcam3.                 9       IN      A       192.168.201.34

;; Query time: 2 msec
;; SERVER: 192.168.201.252#53(192.168.201.252)
;; WHEN: Wed Nov 14 10:20:45 CET 2018
;; MSG SIZE  rcvd: 40

Die Funktionalität ist also irgendwann, ich vermute mal mit 7.00, rausgeflogen.

PeterPawn · 14 Nov 2018

m.kress schrieb:
Die Funktionalität ist also irgendwann, ich vermute mal mit 7.00, rausgeflogen.

Ja, das mag für das "nsupdate" gelten (wobei "nsupdate" eben auch nur eine Umsetzung/ein Programm ist, das diese Updates nach RFC verwendbar macht) ... wobei das insofern wohl nicht "rausgeflogen" ist, als auch "geistiger Dünnpfiff" als Eingabe (sofern der nicht gleich vom "nsupdate" weggefangen wird - also meinetwegen ein Update, wo die Box gar nicht SOA für die Domain ist) genauso keiner Antwort "gewürdigt" wird, wie ein (eigentlich) korrektes Update.

Ich würde also noch nicht verzweifeln und die RFC-Updates für alle Ewigkeit abschreiben ... obwohl sie (zumindest nach meiner Ansicht) ja auch eine Sicherheitslücke werden können (nicht umsonst gibt es ergänzende RFCs, die das um schlüsselbasierte Authentifzierung erweitern).

Aber das hat ja auch nichts mit der Tatsache zu tun, daß (bzw. ob) die FRITZ!Box beim Umbenennen eines "PC-irgendwas"-Eintrags nun einen DNS-Eintrag erzeugt oder nicht ... oder wird jetzt ernsthaft behauptet, die zwei Geräte bei @m.kress haben das vorher über diese RFC-Updates bei der Box bekannt gemacht, wie sie heißen wollen? Ich denke, die mußten vorher auch schon von Hand umbenannt werden? Habe ich das mißverstanden?

Den ganzen Cookie-Klamauk hat AVM aber wohl wirklich erst mit der 07.0x eingebaut (die 06.9x kennt da keine "OPT") ... gut möglich, daß da mit den nächsten Updates dann wieder mal etwas vorgelegt wird, was tatsächlich funktioniert - auch bei den (bzw. allen) Abfragen.

Ich kann ja nun das Phänomen von @m.kress mit der 7580 nicht nachstellen ... gibt es denn hier wirklich niemanden mit einer 7590, der statische Clients in seinem Netz hat und denen über das GUI erst einen Namen verpassen muß, weil sie ansonsten als "PC-ip-adresse" in der Netzwerk-Übersicht landen? Geht da die Umbenennung auch nicht? Bei der 7580 habe ich eben (mit 07.01) so gar keine Probleme damit ... die erratischen Reaktionen bei der Abfrage des DNS-Servers haben ja nichts mit dessen Datenbestand zu tun - denn die habe ich tatsächlich auch.

m.kress · 15 Nov 2018

Der Test mit der alten FB/Firmware sollte beweisen, dass
1.) der nsupdate auch von meinem System aus funktioniert/funktioniert hat.
2.) die Möglichkeit eines manuellem Nameservereintrags bei Geräten für die die FB kein Namen ermitteln kann von AVM entfernt wurde.

Letztendlich scheint es von AVM - aus welchen Gründen auch immer (Sicherheit?) - gewollt zu sein, dass dieses Feature (Geräte ohne Namen einen DNS Namen zu vergeben) herausgeworfen wurde. Schade das es nicht dokumentiert wurde und AVM auch auf Anfrage sich sich nur mit dem Satz "kein offizelles Feature" dazu äußert. Die Funktonaltität war mindestens seit 6 Jahren (wahrscheinlich sogar länger) implementiert.

sf3978 · 15 Nov 2018

m.kress schrieb:
2.) die Möglichkeit eines manuellem Nameservereintrags ...

... oder per cronjob. Z. B so:

Code:

25 1    * * 7    <user>    /usr/bin/nsupdate -v /usr/local/etc/nsupdate.txt > /dev/null 2>&1

Und damit habe ich nie Probleme mit der lokalen Namensauflösung (für alle Geräte) im Subnetz meiner FritzBox.

[Frage] Namesauflösung xxx.fritz.box seit V7.0 unzuverlässig

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Aktives Mitglied

Neuer User

andilao

Guest

IPPF-Promi

Neuer User

IPPF-Urgestein

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

IPPF-Urgestein

IPPF-Promi

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Promi

Statistik des Forums