s. mein letztes Posting:
Warum funktionieren die anderen DynDNS-Aufloeser heute noch ohne Stoerung, ipv64 seit wenigen Tagen nicht?
Common ist doch allen die alte (un_veraenderte) Technik/Das Netz/die Skripte etc, die bei allen anderen noch ziehen, losgeleost von DSLite. 
Gruss
ELindemann
@ELindemann Und warum zeigst du nicht mal die vollständige Ausgabe der Fritte vom Online-Monitor? Da würde man nämlich zweifelsfrei sehen ob Du DS-Lite hast. Was gibt es da zu verbergen, außer den IP-Adressen, die du ja teilweise schwärzen könntest!?
Wann sind denn dein ips das letzte mal geupdatet worden? Offenbar ist es möglich das hier ein Fehler bei ipv64 liegt.
@ELindemann Für mich ist wegen der Technischen Spezifikationen von 1&1 solange klar, dass du DS-Lite hast bis du hier zweifelsfrei das Gegenteil beweist und miut DS-LIte kann das was du willst nicht eifwandfrei funktioneren.
No more support ohne Beweis dass es kein DS-Lite ist !!!
Ja, jede Nacht Zwangstrennung, jede Nacht an zwei Standorten neue IPv4 und IPv6-Adressen
Habe die selbe problematik mit der telekom. Weltweit wird meine alte ip genutzt nur ipv64 hat die neue im System.
Dann löse doch jetzt mal eine Neuverbindung aus. Ist ja, je nach Hardware, nicht sonderlich aufwändig. Bei meiner pfsense hinter einem Modem (Vigor 167) gibt es nur eine Unterbrechung von wenigen Sekunden.
Bist Du ein Mit-Admin, dass Du sowas in den Raum stellst?
Ich frage; waere fein, wenn Du entspannt antwortetest.
Hier ist der Screenshot, Du bist dran.
Trotzdem schuldest Du noch eine Antwort, warum die anderen DynDNS-Aufloeser gestern/heute noch funktionieren, aber ipv64 (seit zwei? d) nicht mehr?
Wo ist hier die Logik?
Mir ist nicht bekannt, dass 1und1 aktuell hier umgestellt haette, auch nix dazu
gelesen.
BTW: habe den DNS-Aufloeser auf EU-DNS-Root 141.1.1.1 umgestellt, keine positive Veraenderung, der fuehrt auch die alte Name/IP Kombination.
Nachtrag:
92. != 10.
92. != 172.
92. != 192.
Wo ist der Fehler?
Danke dafür. 
@The_eagle Du kannst solange du willst auf dem Thema DS-Lite rumhacken, wie du willst, aber darum geht es hier doch gar nicht. Es geht hier primär nicht darum, dass jemand seine Dienste nicht erreichen kann. Das ist das indirekte Resultat daraus, dass die A-Records nicht sauber durch die DNS-Hierarchie propagiert werden.
Also oft genug stellt sich raus, dass Leute nur DS-Lite oder CGNAT haben und nichts davon wissen. Dann wird viel Zeit mit Fehlersuche vergeudet, obwohl es einfach nicht funktionieren kann. Bei 1&1 steht DS-Lite sogar in deren Technischen Spezifikationen. Du hast aber kein DS-Lite (und auch kein CGNAT). Jetzt ist es eindeutig, vielleicht hast du kein DS-Lite weil du schon seit Jahren dort Kunde bist.
Zu deinem Problem. Nach Möglichkeit sollte immer der Router oder die Firewall, die mittels Modem direkt mit dem DSL-Anschluss verbunden ist die IP-Adressen updaten. Insbesondere wenn nur IPv4 genutzt wird macht es absolute keinen Sinn das von einem Pi oder anderen System hinter dem Router oder der Firewall erledigen zu lassen. Du hast eh nur genau eine IPv4-Adresse und die liegt am Router oder der Firewall und die bekommen die Zwangstrennung unmittelbar mit und lösen das Update aus. Ein System dahinter bekommt davon zunächst nichts mit und muss in bestimmten Zeitintervallen prüfen ob sich die Adresse geändert hat. Das allein führt schon zu zeitlichen Verzögerungen.
Daher solltest du den Job die IPv6-Adresse zu aktualisieren von der Fritte erledigen lassen, nicht von deinem Pi. Nutzt du am Pi auch IPv6 empfehlt sich die Nutzung des ip6lanprefix-Updates der Fritte und Zuweisung eines festen Interface-Identifer auf Basis der IPv6 Interface-ID durch die Fritte.
Der Pi muss dann nix mehr tun. Alle nötigen Updates erfolgen unmittelbar nach Zwangstrennung durch die Fritte.
Habe ich durchgeführt, gleiches Verhalten…
Zu komisch nur, dass bei mir die von einer pfsense und einer Fritte an zwei verschiedenen Standorten Updates sauber durch alle DNS-Hierarchien propagiert wurden. Zwangstrennung Fritte = heute 03:55 Uhr, Zwangstrennung pfsense heute 04:58 Uhr.
Wenn es ein generelles Problem mit den DNS-Updates gäbe, dann müsste doch wohl aller Nutzer:innen von home64.de-Domains gleichermaßen davon betroffen sein.
In deinem Raspi ist der Fehler. der macht den Updatejob. Aber ich kenne nicht dessen Konfiguration und leider ist die Glaskugel heute vom Tisch gefallen und in 1.000 Teile zersprungen, so dass ich darin auch nichts mehr sehen kann.
Die Adressen mit 10. 172. und 192. sind aber mutmaßlich Class A, B und C-Adressen. Also private, keine öffentlichen. Um das genau zu sagen müsstest du zumindest die 172. und 192. vollständig zeigen, oder selbst das hier lesen und verstehen
Neuverbindung wollte ich eh machen und hat das problem gelöst. Denke daher, dass das system die ips zwar angenommen hat aber nicht weiter verteilt hat. Wie es genau läuft weiß ich nicht, aber mutmaße das es heute nacht irgendwie zu einem derartigen fehler gekommen ist.
Hallo The_eagle,
as i told you, kein DS-Lite.
Nochmal zur Logik:
Alle anderen Ausfloeser funken doch weiterhin. Wenn auch die nicht mehr OK waeren, dann, dann, dann. Aber ist nicht. Einzig, wie bjinthahouse schreibt, alles sieht Ok aus, update erfolgt, aber die Welt kriegt es nicht mit. Halt dg.
Ich bin nicht der Ueberzeugung, dass die Fritzbox das DNS.Update machen sollte, warum?
Wie Du siehst, wenn ein Service (hier wahrscheinlich etwas Internes @ipv64) versagt, bist Du komplett raus.
Ausser … Du hast andere Einheiten, die aus dem hinteren Ring per cron akt. mit der alten IP abgelcihen, ohne den Service an sich zu belaestigen und dann den Abgleich per curl anstossen.
Daher mache ich das seit paar Jahre (eher Dekaden ;-)) genauso, nicht eine Einheit, sondern mehrere, die auf die IP4 schauen (nicht ip6) und entsprechend agieren.
Zudem, die Fritzbox kann halt nur eine, mit einem Skript kann ich alle anderen auch abfragen, bei Bedarf agieren.
Die Fritzbox macht vieles richtig, aber einen DNS-Server kennt sie nicht, heisst immer fritz.box. Wenn ich also einen DNS-Server im LAN haben muss, dann ziehe ich einiges von der FBox weg.
FBox @home, ja, mit einer Linux-Kiste dahinter viel besser.
@prof. Umgebung ist die FBox nicht soooo geeignet, da ist die pfsense/opnsense weitaus besser, stabiler (zudem auch besser als die teure HW von Sophos und wie sie alle heissen); einzig man muss wissen, was man da macht. 
Leider ist deine Letzte Antwort, dass der Raspi fehlerhaft sei absolut falsch.
Warum?
a) nicht nur, dass der Raspi korrekt updated, das sagt die GUI bei ipv64
b) ich kann auch gegen validieren, weil die andeere remote identisches Skript ausfuehrt und bei dieser Einheit (linux/debian, auch hier nicht von der FBox) funkt es weiterhin korrekt.
c) weiterhin gibt es auf der GUI die Option (ohne jegliche Raspi-Thematik) das update im Browser auf der GUI @ipv64 auszufuehren.
Allen gemeinsam ist, ein update wird korrekt ausgefuehrt, kommt aber in der Welt nicht an.
BTW
Du solltest bitte nicht belehrend auftreten, weil das Bsp. mit != nur zeigen sollte, dass ich eben (auch in der erweiterten Darstellung priv. Adresse, die fangen ja auch defintiv mit 10/172/192 an) kein DS-Lite habe.
Auch, wenn dein Postulat bei mir richtig sein sollte (was es nicht ist, s.o.), so hast Du trotzdem eine Erklaerungsluecke bei bjinthahouse, der auch noch kurz die Leitung getrennt hat und wohl auf der FBox abgleicht, zudem definitiv nicht ein DS-Lite bei TKom hat.
Warum Du Dich der Login verschliesst, kann ich nicht ganz greifen.
Summa: Ich behaupte mal, dass ipv64 das Update temp. nicht in die Welt gibt/kriegt.
Jedoch sind wir alle doch ein wenig erfahren, dass man auch fuer diesen Fall vorgedacht hat, oder?
Ich denke in paar Tagen funkt es wieder. Ich bin da rel. entspannt. Waere schade, wenn dieser Service (paar andere und meinen ) DNS Namen nicht mehr betreuen wollte. 
:-|.
Ich warte ab.
Denke fuer deine Hilfestellung.
Gruss
ELindemann
Nochmal: was sollen die drei verscheiden Adresse aus Class A, B und C-Netzen auf dem Raspi!? Warum führst du die hier an? Denkst du das wären die Adressen die bei ipv64.net geupdatet werden sollten? Oder war das irgendeine Nebelkerze um weitere Verwirrung zu stiften? Jeder Verweis auf Ipv4-Adrssen aus Class A, B und C-Netzen ist (um es mal deutlich zu sagen) totaler Schwachsinn !!!
PS: mach das mit deine schwachsinnigen Konfiguration mit mind. drei verschieden IPv4-Adresen am Raspi aus Class A, B und C-Netzen mit dir selbst aus. Son’ Schwachsinn versteht kein normal denkender.
Hallo The_eagle,
ich finde deine Wortwahl schwierig. Ich denke, dass gehoert sich nicht.
Zu keinem Zeitpnkt habe ich hier geschrieben, dass diese Adressen auf dem Raspi konfiguriert sind. Sondern, dass die oeffentliche IP4-Adresse (von 1und1) fuer den Anschluss eben_ nicht wie Du die ganze Zeit postuliert hast eine DS-Lite/CGNAT sei.
Du hast immer beharrt (gar mit einem Postulat keinen Support mehr zu geben), dass ich evtl. eine DS-Lite Adresse haette. Die 92. (in der oeffentlichen IP4) zeigte mir vorher und mit dem Screenshot auch Dir, dass deine Theorie nicht stimmte.
Und nichts anderes sollte die 92 != 10/172/192 zeigen, KEIN DSLite/CGNAT. q.e.d.
Warum Du den Abgleich eines Raspi mit diesen IP-Adressen zusammenrbringst leuchtet mir wahrlich nicht ein. Du hast danach gefragt und ich belegte, dass ich kein DS-Lite/CGNAT habe.
Ausserdem hast Du weiterhin keine Antwort, warum ein identisches Konstrukt (FBox - linux-Einheit, die ipv64 updatet) in einem anderen Netzwerk funkt.
Ebenso auch fuer bjinthahouses Problem hast Du auch keine Loesung; wenn wir meinen Schwachsinnn ausser acht lassen wollten.
Es ist sicherlich nicht schwachsinnig, was ich mache und (wahrscheinlich, ja Spekulation) laenger als Du schon viele Jahre gemacht habe nur weil Du eingefahren denkst, nicht in toto die Problematik verstanden hast.
Ich finde egal wie kompliziert und/oder vllt. gar defizitaer die Thematik/Problematik wiedergegeben wurde (vllt?) ist der Tonfall im Forum sehr wichtig und ebenso auch vorgegeben. Bitte achte auf deine Wortwahl.
Statt schwachsinnig koenntest Du schreiben: technisch ist dein Konstrukt nicht gut oder ich rate Dir zu einer besseren technischen Umsetzung etc.
Have phun.
ELindemann
Schon in Beitrag #8 war eindeutig, dass es kein DS-Lite ist.
Da fragt man sich schon, wieso da so sinnlos eine Diskussion dazu angestoßen wird.
@Loesung
Da ich den Subject des Threads nicht geloest markieren kann, moechte ich mit diesem Beitrag die Anfrage als GELOEST schliessen.
Das Studium der FBox-Logs belegte, dass die IP a.b.c.52 vor wenigen Tage bei uns konfiguriert war. Warum auch immer (seit wann?) rotiert die IP bei 1und1 nicht mehr taeglich. Schon, aber eben nicht alle 24h.
Mehrere Versuche, wie FBox re-dial, ein Neustart - ebenso wie The_eagle vorgeschlagen hatte - den Abgleich auf die FBox zu legen brachten keine Loesung des Problems. Das Update (egal von der FBox oder von einer anderen Maschine) wurde bei ipv64 korrekt vorgenommen, jedoch der konfigurierte Name wurde nicht nach draussen, in die Welt synchronisiert.
Da manche Dienste @home auf diesen Namen konfiguiert waren, wollte ich diesen Namen nicht in den Wind schiessen.
Loesung:
→ Ich denke ohne missbraeuchlichen Einsatz (unter diesen Kautelen) habe ich unter einer neuen Emailadresse einen neuen Account bei ipv64 angelegt.
→ Unter diesem Account legte ich einen neuen [dynname1].ipv64.net an.
→ dieser DynName wurde vom Skript (hinter der Fbox, linux-Einheit) korrekt auf die akt. IP gebunden/aufgeloest.
=>
→ den alten [dysfunf_DynName0].ipv64.net habe ich unter dem alten Account geloescht
→ diesen [dysfunf_DynName0].ipv64.net habe ich unter dem neuen Benutzeraccount (mit der neuen Emailaddr./Neuanmeldung bei ipv64) neu angelegt/konfiguriert.
=>
Es erfolgte ein sofortiger Abgleich des vor wenigen Tagen verloren gegangenen Names [dysfunf_DynName0].ipv64.net per Skript von einer Linux-Einheit hinter der FBox.
Eben dies, einen zweiten Account bei ipv64 wollte ich vermeiden. Interessant waere zu erfahren, ob auf dem alten Account ein [neuer_DynName].ipv64.net auch nicht mehr in die Welt gemeldet werden wird, dann saehe es nach einem korrumpierten Benutzeraccount bei ipv64 (wo auch immer) aus.
Wenn dieser neue Name funkte, dann war der Wurm nicht im Account, sondern beim alten DynNamen drin.
— geloest — / — closed —
Gruss
ELindemann
