Dann eben als Screenshot, wenn sonst nix erlaubt ist!
Habe keine Probleme.
Info: „Updating…“ ist relativ neu. Das liegt daran, dass Einträge in die DB nicht sofort synchronisiert werden, sondern wenige Sekunden versetzt. Ich rede von so 2-3-4 Sekunden.
Das bedeutet Updating…
Der Eintrag ist trotzdem spätestens nach der TTL von 10 Sekunden gültig.
Hi @Dennis_Admin ,
ja, die Anzeige von „Updating…“ macht durchaus Sinn. Ist es normal, dass sie nicht automatisch verschwindet, erst wenn man die Webseite z.B. mit Taste F5 neu lädt?
Mein Problem am Mittwoch war, dass IPV64.net mehrere Stunden nicht auf meinen (funktionierenden) Update-Link reagiert hat (von 3:00 Uhr bis ca. 7:00 Uhr). Dann habe ich mich eingeloggt und die IPv6 manuell geändert und da ging das „Updating…“ nicht mehr weg… auch nach mehreren Minuten. Erst im Laufe des Tages normalisierte sich das (wobei ich nicht schauen konnte, ab wann genau - abends ging es wieder).
Grüße
Mic.
Nur mal so am Rande, das Ding funktioniert übrigens immer noch nicht. Ist wohl doch eine Fehlkonstruktion:
ich@pc:~# docker logs -f ddns-ipv64
==============================================================================================
================================ START DDNS UPDATER IPV64.NET ================================
==============================================================================================
================ ###### ######## ## ## ####### ## ## ================
================ ## ## ## ## ## ## ## ## ## ================
================ ## ## ## ## ## ## ## ## ================
================ ## ######## ## ## ######## ## ## ================
================ ## ## ## ## ## ## ######### ================
================ ## ## ## ## ## ## ## ================
================ ###### ## ### ####### ## ================
==============================================================================================
2025-07-13 17:01:57 DOMAIN - Sie haben eine DOMAIN gesetzt
2025-07-13 17:01:57 DOMAIN - Deine DOMAIN mein-domain.ipv64.de
2025-07-13 17:01:57 DOMAIN KEY - Sie haben einen DOMAIN Key gesetzt
2025-07-13 17:01:57 SHOUTRRR - Sie haben keine SHOUTRRR URL gesetzt
2025-07-13 17:01:57 FEHLER !!! - Die Angaben sind falsch gesetzt: DOMAIN oder DOMAIN KEY
2025-07-13 17:01:57 INFO !!! - Stoppen sie den Container und Starten sie den Container mit den richtigen Angaben erneut
==============================================================================================
==============================================================================================
================================ STOP DDNS UPDATER IPV64.NET ================================
==============================================================================================
========================= ###### ####### ####### ####### =========================
========================= # # # # # # # =========================
========================= # # # # # # =========================
========================= ##### # # # ###### =========================
========================= # # # # # =========================
========================= # # # # # # =========================
========================= ##### # ####### # =========================
==============================================================================================
Ich hab da keinen Einfluss drauf, das kommt aus meiner Community. Ihr müsst das bitte über GIT klären und nicht hier.
Könnten wir die Themen mit der Community nicht auch hier auf diesem Forum besprechen? Dann wäre alles an einem Ort.
Ja das können wir natürlich, aber das Projekt für diesen Updater wird auf GIT bearbeitet. Der Bearbeiter des Projektes ließt hier vielleicht nicht.
Ihr habt im GIT Projekt einen Fall geöffnet ?
Hallo zusammen,
ich hatte nochmal ausprobiert, ob ich meine FritzBox nicht doch überreden kann, ein Update des IPv6-Präfix durchzuführen. Dazu habe ich den Link verwendet, der auf der Kommandozeile funktioniert.
https://ipv6.ipv64.net/nic/update?key=`***my_key***&ip6lanprefix=<ip6lanprefix>&ipv6prefix=auto&onlyprefix
In der FritzBox funktioniert es aber nicht und sie zeigt mir nun diese Fehlermeldung wiederholend im Log an:
Kennt das jemand von euch?
Grüße
Mic.
Jetzt mal ich, weil ich einfach unzählige Fehler von euch einfach nicht nachvollziehen kann.
Testdetails:
Fritzbox 7590 AX v2
Vodafone Business DSL
Externes Modem Draytek Vigor 167
FRITZ!OS: 8.02
Ich habe eine RICHTIGE Ipv4 (kein CGNAT müll) und IPv6.
VORHER BILDER
Alle Felder sind leer, nichts ist drin.
URL aus der Anleitung von der Webseite nehmen (inkl. Prefix Updater)
https://ipv64.net/nic/update?key=111111111111g0FBxojNYZKMp3cQ4&ip=<ipaddr>&ip6=<ip6addr>&ip6lanprefix=<ip6lanprefix>
In die Fritzbox die Daten eintragen.
URL: übertragen vom Webseite
Domainname: domainname
benutzer: IRGENDWAS HIN SCHREIBEN mir egal was..
passwort: IRGENDWAS HIN SCHREIBEN egal was..
Übernehmen klicken
NACHHER ca. 10 sekunden später.
Schön zu erkennen, beide IPs (v4 und v6) werden gleichzeitig aktualisiert und das IPv6 Prefix auch noch.
Mein Verdacht:
- Passiert bei den Versionen ab OS8 dieser Hedgefond-Tochtergesellschaft aus Berlin, wenn man CDN aktiv hat, weil IP-Adresse(n) die der Update-String aktualisiert ungleich jener des CDN ist. Offenbar prüft deren gammeliges OS ab Version 8 die IP-Adressen per
nslookup
.nslookup
gibt dann die IP des CDN zurück. Dann denkt sich dieses dämliche OS halt: „oh muss ich updaten, IP stimmt nicht“. - Es wird (wie bei @Mic2025) nur der Prefix aktualisiert, wegen
&onlyprefix
. Dann klapptnslookup
natürlich auch nicht. Offenbar muss man dann zwangsweise auch die IPv6-Adresse der Fritte selbst auch noch mit aktualisieren.
Kann ich selbst aber nicht verifizieren. Habe nur Zugriff auf pfsense und Fritten mit OS7.60.
Wer DynDNS und IPv64 CDN zusammen nutzt… Der kann sich nicht darauf verlassen, das dyndns bei manchen Endgeräten sauber funktioniert. Es wird am DNS manipuliert mit IPv64 CDN, da kann niemand richtig über DNS überprüfen, ob die Änderung angekommen ist.
Hallo zusammen,
also als erstes muss ich mal schmunzeln oder den Kopf schütteln oder beides. Auf der einen Seite schreibst du auf deiner Webseite von IPV64.net (als Pluspunkt für „dein Produkt“), dass quasi alle FritzBoxen unterstützt werden aber auf der anderen Seite äußert ihr euch hier im Forum so abfällig über die Geräte von AVM. Ich habe seit Jahren FritzBoxen und bin sehr zufrieden damit. Auch der Support von AVM ist einer der Besten, den ich kenne. Daher unterstütze ich AVM auch gerade beim Testen ihres neue FritzOS 8.10 auf meiner FritzBox 7590 AX v2. (Frage am Rande, wozu hast du, @Dennis_Admin noch ein externes DSL-Modem an deiner FritzBox? DSL kann doch die FritzBox selbst.
Egal… und ja, @Dennis_Admin ich habe an meinem 1&1-Anschluss diesen CGNAT und DS-Lite Müll (wie du es nennst). Dafür habe ich mir vor ca. zwei Jahren mal die Mühe gemacht und mein ganzes Heimnetzwerk auch auf IPv6 umgestellt (inkl. damals Pi-hole auf einem RasPi). Und ohne diesen „CGNAT-Müll“ bräuchte ich deinen CDN Portmapper auch gar nicht. Da hättest du den ja umsonst entwickelt. Den CDN Portmapper von IPV64.net habe ich aber auf „nur IPv4“ eingestellt. Der von dir beschriebene Konflikt scheint als bei mir nicht die Ursache zu sein.
Der Verdacht, den @The_eagle beschreibt, erscheint mir da schon eher möglich zu sein. Klingt jedenfalls plausibel. Wie gesagt, wenn ich eine „vollständigen“ Update-Link eintippe (also ohne „onlyprefix“ etc.) dann läuft das Update auf der FeritzBox durch aber danach ist eben die WebGUI der FritzBox unter mein-domain.ipv64.de erreichbar und nicht meine NextCloud. Also nicht das, was ich möchte.
Ich habe aber jetzt ein Ticket bei AVM erstellt und denen das Problem und die Besonderheit von IPV64.net (Präfix-Update) beschrieben. Ich hoffe, sie schauen es sich an und es kommt da auch eine Lösung.
Unabhängig davon habe ich auf GitHub auch ein Ticket wegen de Problem mit dem nicht funktionierenden Docker Update Tool erstellt.
Aber alles aktuell kein Show-Stopper für mich. Mein selbstgebasteltes Skript macht zuverlässig seine Updates und hält meine NextCloud erreichbar:
Danke und Grüße
Mic.
Hallo @Mic2025
Mein Docker Container funktioniert nur für ipv4 derzeit steht aber auch in der Beschreibung.
Das ist ja spannend. Er funktionierte bei mir auch mit IPv6 ein paar Tage lang gut. Ist der Fehler, den er bei mir Verursacht darauf zurückzuführen? Aber gut zu wissen, dann experimentiere ich damit nicht mehr rum. Danke. Aus Neugierde: Ist ein Update für IPv6 deinerseits geplant?
Habe drüber nachgedacht halte es mir aber offen.
Ich habe Antwort von AVM bekommen. Sie haben tatsächlich für mich einen Test mit IPV64.net gemacht. Ich kopiere mal unkommentiert den interessanten Teil ihrer Antwort:
Mit der obigen Udpate-URL wurde bei uns der WAN-Präfix aktualisiert (durch ‚ipv6prefix=auto‘). Wurde der Teil (ipv6prefix=auto) entfernt, wurde der LAN-Präfix aktualisiert (durch 'ip6lanprefix=>').
Also wenn der WAN-Präfix aktualisiert werden soll, dann ‚ipv6prefix=auto‘ nutzen.
Wenn der LAN-Präfix aktualisiert werden soll, dann 'ip6lanprefix=' nutzen.Es wäre weiterhin günstiger, dass die IPv6-WAN-Adresse der Box ebenfalls aktualisiert wird, denn diese wird benötigt um zu prüfen, ob das Update erfolgreich durchgeführt wurde. Ohne Adresse schlägt die abschließende Verifizierung fehl und das Update wird - nach einigen DNS-Versuchen - erneut gesendet. Dadurch wird das Tageslimit der möglichen Updates (vom Anbieter auf 64/Tag festgelegt) erreicht und anschließend werden weitere Updates vermutlich ignoriert.
Ich habe mich über deren OS negativ geäußert. Ich bin ich und weder Mitarbeiter von ipv64 noch irgendwie mit Dennis verwandt oder verschwägert. Meine Äußerungen entsprechen meiner persönlichen Meinung zu deren OS und ist durch durch Artikel 5 GG gedeckt.
Nö, nur ein davon. Entweder CG-NAT oder DS-Lite. Die dritte Option wäre Dual-Stack.
Leider hast du aber offenbar das Thema IPv6 in den zwei Jahren noch immer nicht vollständig inhaltlich durchdrungen und verstanden. Deine Probleme hier haben nichts mit ipv64 zu tun, sondern mit deiner Konfiguration und Umsetzung der Umstellung auf IPv6. Augenscheinlich hast du leider nicht alle sich aus dem Konzept von IPv6 im Vergleich zu IPv4 ergebenden Aspekte bedacht und in deinem Konzept und der Umsetzung dieses Konzepts berücksichtigt.
Wurde ja offenbar auch von denen in deren Antwort auf dein Ticket bestätigt.
Eine Lösung gibt es längst und es läge in deiner Hand die Konfiguration deines LAN’s und der DynDNS-Einstellungen bei IPV64 entsprechend anzupassen.
Für mich ist das ganz offensichtlich. Die Lösung liegt in der Verwendung von Domain-Präfixen in Kombination mit einem IPv6 Prefix sowie einem oder mehreren Record Update-URL - Security Level 3 (High). IPV64 bietet seit langem die Option diese zu verwenden.
Das sollte sogar mit den von dieser Hedgefond-Tochtergesellschaft aus Berlin bestätigten Unzulänglichkeiten von deren OS im Zusammenhang mit DynDNS-Updates umsetzbar sein. Unzulänglichkeiten, weil es gar keine guten Grund gibt die Notwendigkeit eines DynDNS-Updates per DNS-Abfrage zu prüfen. Es würde vollkommen ausreichen würde deren OS prüfen ob sich die IP-Adressen, die deren Geräte vom ISP zugewiesen bekommen haben, seit dem letzten Update verändert haben. Nur dann wäre ein DynDNS-Update nämlich erforderlich.
Warum du unbedingt per Docker die DynDNS updaten willst erschließt sich mir auch nicht so ganz. Da Docker-Container meines Wissens nach keine eigene IP-Adressen haben, anders als VM’s, kann man doch einfach das OS des Hosts (z.B. Debian) den Job erledigen lassen. Ein simples curl -sSL "https://ipv64.net/nic/update?..."
sollte doch jedes Host-OS hinbekommen.
Hallo zusammen,
ja, ich dachte mir schon, dass ihr nicht verheiratet seid. Und ja, alles noch im Rahmen von Recht und Gesetz, was und wie du hier schreibst. Es bringt nur etwas (unnötige) Schärfe rein. Ich habe eine positivere Meinung zu AVM und den Pomm Fritters Geräten, wobei ich dir an einer Stelle rechtgeben möchte: In früheren Versionen war, die FritzBox „offener“ und besser für Tüftler geeignet. Aber dafür gibt es ja jetzt OpenWRT, der das unbedingt mag. Ich verstehe AVM, dass sie hier für die breite Masse ein paar security-relevante Türen schließen musste.
Anyhow… zurück zum Thema. Was das Thema IPv6 Präfix und Suffix, sowie Domain Präfix und Suffix angeht, sehe ich aktuell nichts, was ich in meinem Setup übersehen habe aber das heißt nicht, dass ich nicht doch etwas übersehen habe.
Hier ein grob skizziertes Bild dazu:
Mir ist auch die Besonderheit von IPV64.net bewusst, dass man nur das IPv6 Präfix quasi auf den Domain Suffix (also alle Domains in meinem IPV64.net User Account) updaten kann. Das klappt ja bei mir auch aber: Eben nicht aus der FritzBox heraus, weil es da diesen komischen Test gibt, den AVM implementiert hat. Ich interpretiere das so, dass die DynDNS-Option in der FritzBox nur dafür gedacht ist, die WebGUI des FritzOS selbst via DynDNS übers Internet verfügbar zu machen. Das ist kein Problem/Fehler/Nachteil/… von IPV64.net (habe ich auch nie behautet ). Ich habe AVM schon geantwortet und gesagt, dass das mit dem Test eine blöde Idee ist und dass ich das, was sie mir vorgeschlagen habe, eben genau nicht möchte. Ich denke, da müssen die jetzt erst mal drüber nachdenken. Möglicherweise kenne sie diese (neue?) Möglichkeit von IPV64.net gar nicht, dass man da nur das Präfix updaten kann.
Ich habe die besagte Funktion in der FritzBox jedenfalls erst einmal wieder deaktiviert und verlasse mich weiter auf mein Update-Script, welches direkt auf dem Host-PC meiner NextCloud als CronJob alle 15 min läuft.
Damit ist erst einmal alles okay. Wenn AVM mir nochmal eine Rückmeldung gibt, lasse ich es euch gern wissen.
Was den Docker angeht: Nein, brauche ich nicht unbedingt, aber wenn es ein (halbwegs) offizielles Tool gibt, nutze ich gern dieses oder möchte zumindest sehen, dass es funktioniert. Mein selbstgebasteltes Skript macht es ja auf genau die von dir beschriebene simple Art und Weise. Wenn ich irgendwann mal Lust und Zeit habe, lade ich es vielleicht mal bei GitHub hoch.
Am Rande: In der Tat verwendet 1&1 kein CG-NAT mehr, nur noch SD-Lite. Sorry, meine Verwechslung.
Ich denke, wir sind vom Stand her gar nicht so weit auseinander. Euch allen ein schönes Wochenende.
Grüße
Mic.
Meine Kritik an den Fritten-Fritzen hat nichts damit zu tun, dass die ein paar security-relevante Türen schlißen mussten. Im Gegenteil. Die ließen security-relevante Scheunentore offen. Etwa bei VPN. Jahrzehntelang gab es da bei Fritten nur IPSec und das auch nur in einer kastrierten Version, mit minder sicheren Optionen zur Verschlüsselung als möglich gewesen wäre. OpenVPN wurde nie angeboten.
Nun gibt es endlich Wireguard als Alternative zu IPSec. Aber auch das in der den Fritten-Fritzen eigenen Art in einer kastrierten Version. Die Geräte denen man per Wireguard Zugang zum LAN geben will bekommen doch glatt gleich eine IP-Adresse aus dem LAN der Fritte. Vernünftige Implementierungen, die die etablierte Best Practice beachten, verwenden ein Transfernetz. Die Die Geräte denen man per Wireguard Zugang zum LAN geben will bekommen also eine IP-Adresse aus einem separaten Netz, so dass man zwischen diesem und dem eigentlich LAN Firwall-Rules setzen kann/muss, die genau regeln was die per VPN zugeschalteten Geräte können und dürfen sollen.
Folgendes Zitat zeigt mir, dass wir es doch sind.
Das ist ja nur möglich, wenn man in der Fritte den Fernzugriff aktiviert. Etwas das ich niemals machen würde. Selbst die Fritten-Fritzen sagen dazu:
- Das Aktivieren des Fernzugriffs auf die FritzBox sollte nur erfolgen, wenn dies unbedingt erforderlich ist, da es ein potenzielles Sicherheitsrisiko darstellt.
Warum sagen die das? Weil dazu die Ports 443 (https) oder 80 (http) für den Zugriff auf die Weboberfläche freigegeben werden müssen und man die Fritte so unnötig exponiert. Best Practice wäre hier das nur über den Umweg des VPN’s zu ermöglichen. Dann muss nur der VPN-Port exponiert werden.
Zudem würde ich niemals Server, die direkt aus dem Internet erreichbar gemacht werden sollen, wie eine Nextcloud, direkt im LAN betreiben wollen. Server gehören in ein separates Netzwerksegment, das durch physische NIC’s oder VLAN’s vom eigentlichen LAN getrennt ist und für das man eigene Firewall-Rules definieren kann.
Eine Fritte macht da die Grätsche. Die kann das schlicht nicht.
Darum verwende ich keine Fritten, sondern eine pfsense direkt am Anschluss des ISP.
Damit will ich dir nicht deine Kompetenz absprechen, sondern verdeutlichen, dass wir beide sehr unterschiedliche Ansätze hinsichtlich des Aufbaus und der Sicherheit unseres LAN’s haben.
Auch dir ein schönes Wochenende !!!