im Portal sehe ich meine aktuelle IP Adresse. Die Updates funktionieren auch.
Seit heute ist es jedoch so, dass, wenn ich dns abfragen mache (verschiedene DNS Server, oder auch externe z.b. DNS-Abfragen | heise Netze)
Bekomme ich die Adresse die ich gestern hatte. Seit 13 Stunden habe ich aber eine neue.
Stimmt was am ipv64 nicht?
auch hier dasselbe.
Auch mein Routerneustart brachte natürlich nix.
Wenn ich mit meinem Account auf ipv64.net einlogge sehe ich meine aktuelle IP. Auch gerade aktualisiert.
aber die externen abfragen zeigen eben auf die adresse von gestern…
ich kann den Eintrag über die Webseite aktualisieren, ja, das habe ich schon gesehen.
Das Problem das ich habe ist, dass DNS Anfragen mit der IP vom Tage zuvor beantwortet wurden, und nicht mt der im IPv64 …..
Das Problem hatte ich von ein paar Monaten schon mal.
Das Problem habe nicht nur ich, auch alle DNS hier: https://www.whatsmydns.net/
Gaben die IP Adresse von einem Tag vorher wieder, obwohl im Portal die aktuelle Adresse steht.
Wie gesagt, das ist nicht das erste mal, dass das passiert….
Ich war heute 6 Stunden mit dem Zug unterwegs und habe während der Fahrt mehrfach auf meine Nextcloud zugegriffen. Wenn die zu meiner DynDNS-Adresse gehörende IP-Adresse nach der Zwangstrennung heute Nacht, wie deine, nicht an die DNS-Server weitergegeben worden wäre, hätte das nicht geklappt.
Es scheint also entweder ein individuelles Problem zu sein, oder eines, das nur bestimmte Server betrifft.
Auch wenn das Thema schon etwas älter ist aber es gibt scheinbar noch keine Lösung
Ich habe seit ca. 14Tagen DSL Probleme gehabt.
Daher habe ich mir mal Uptime-Kuma aufgesetzt und einen Monitor auf Google gesetzt um meinem Anbieter zu zeigen wann die Ausfälle sind
Dabei habe ich festgestellt das meine Domain (wszene.com) zwar nach jeden IP-Wechsel sofort auf der IPv64 Seite die neue IP bekommt (das geht wirklich schnell denn im Cloudrouter habe ich bei meiner S2S keine wirklichen Abbrüche) aber die DNS-Eintrags-Wechsel dauern ungewöhnlich lange (bis1h) auf der IPv64 Seite steht in der ganzen Zeit der Status auch auf “updating“
Kann sich das evtl. noch einmal jemand ansehen
Danke im Voraus
Gruß
Marcel
PS:
@Dennis_Admin da hast mit dem Dienst IPv64 inkl. aller “Unterdienste“ wirklich etwas sehr gutes auf die Beine gestellt
Nun habe ich das gleiche Problem. Wie oben beschrieben, ist in den Nameservern eine veraltete IP Adresse eingetragen (geprüft über https://www.whatsmydns.net, nslookup und dig 8.8.8.8 meine.domain.de) während in meinem Account bei ipv64.net die richtige (aktuelle) IP angezeigt wird.
Ich update meine IP über Docker (docker-ddns-ipv64). Im Log bekomme ich folgendes zu sehen:
docker-ddns-ipv64
026-07-10 16:00:00 INFO !!! - IPv4 gefunden: 89.183.220.XXX (Quelle: https://ipinfo.io/ip) → richtige IP
2026-07-10 16:00:00 INFO !!! - IPv6 ist deaktiviert
2026-07-10 16:00:00 KEIN UPDATE - IPv4=89.183.220.XXX IPv6= → richtige IP
2026-07-10 16:00:20 INFO !!! - IPv6 ist deaktiviert (IPV6_ENABLED=no)
2026-07-10 16:00:20 IPv4 CHECK - Domain meinedomain.srv64.de hat IPv4: 89.183.217.YYY → falsche IP
So wie ich dein Problem verstehe, ist es der falsche Beitrag. Passender wäre: IPV64 DynDNS Präfix-Update funktioniert nicht, weil es ja prinzipiell funktioniert nur eben zeitlich verzögert.
Soweit ich weiß hatte sich ja schon herauskristallisiert, dass es oft zu solchen Verzögerungen kommt, wenn das Update in den „Stoßzeiten“ erfolgt, meist um die 4 Uhr herum. Das Update der Datenbank ist dann zwar erfolgreich, aber das Update der DNS-Server erfolgt erst verzögert.
Abhilfe dürfte sein, z.B. in der Fritte der Zwangstrennung zuvorzukommen und den Zeitpunkt zu verschieben. Der Default ist wohl 3-4 Uhr und vermutlich belassen es viele bei diesem Wert, wodurch es zu diesen Stoßzeiten kommt. Auch bei Ereignissen sieht man das recht schön
Ich hab jetzt mal bei mir den Zeitraum der zuvorkommenden Zwangstrennung von 3-4 Uhr auf 1-2 Uhr geändert. Seither klappt das DynDNS-Update wesentlich zeitnäher und im Log der Fritte treten wesentlich weniger „DynDNS-Fehler“-Meldungen auf. Das erhärtet den Verdacht auf Update-Probleme während der Stoßzeiten.