IPV64 DynDNS Präfix-Update funktioniert nicht

Mic2025 · 16. Juni 2026 um 14:14

Hallo Gemeinde,
Hallo @Dennis_Admin ,

seit letzter Nacht habe ich das Problem, dass das DynDNS-Präfix-Update über den bekannten Update-Link nicht mehr funktioniert.

https://ipv6.ipv64.net/nic/update?key=********************************************&ipv6prefix=auto&onlyprefix

Gebe ich den Link (jetzt) manuell im Browser ein, bekomme ich:

{"info":"Updateintervall overcommited","status":"403 Forbidden"}

In der WebGUI sehe ich, dass ich meine maximal 64 Updates pro Tag erreicht habe. Ich habe aber keine Idee, woher das kommt. Präfix-Updates werden doch nicht auf das tägliche Kontingent angerechnet, oder jetzt doch?

Es verursacht immer einen Fehler. Der Server gibt keine Antwort.

Ist das bekannt? Zufall oder ein Problem?

Danke und Grüße
Mic.

The_eagle · 16. Juni 2026 um 16:15

Nein, bei mir zumindest werden nur die Updates vollständiger 128 Bit v6-Adressen gezählt.

Das Problem, warum du heute bereits 64 Updates pro Tag erreicht hast muss also woanders liegen. Es ist aber denkbar, dass nach erreichen von 64 Updates pro Tag auch keine Präfixe mehr aktualisiert werden können.

Prüfe deine Logfiles, sofern du nicht so einen Gammel vom Schlage einer Fritteuse hast, die das gar nicht ins Log schreibt

Mic2025 · 16. Juni 2026 um 16:41

Nein, du weißt doch, dass ich schon ewig mein eigenes Update-Skript verwende und das erzeugt auch einen sinnvollen Log. Drin sehe ich aber keine Auffälligkeiten. Letzte Nacht gegen 4:00 Uhr wurde das letzte komplette Update erfolgreich gemacht. Da funktionierten auch die Präfix-Updates noch alle 15 min. Ab 6:15 Uhr laufen dann alle Präfix-Update-Versuche ins Leere („keine Antwort vom Server“).

Was genau den Counter auf 64 laufen lassen hat, kann ich leider nicht erkennen. Es gab keine weiteren Komplett-Update-Versuche, nur Präfix-Update-Versuche.

Ich hoffe, wenn der Counter um 0:00 Uhr wieder von 64 auf 0 resetiert wird, dass sich die Sache wieder beruhigt. Komisch ist es aber trotzdem…

Einzige Idee die ich hätte ist, dass die Response heute zu lange gedauert hat und das dann in meinem Skript als „keine Antwort“ gewertet wurde.

Grüße
Mic.

Mic2025 · 17. Juni 2026 um 05:07

Hallo,

das Problem besteht leider weiterhin. Mein Counter steht weiterhin bei 64/64 und die Präfix-Updates schlagen weiterhin fehl.

{"info":"Updateintervall overcommited","status":"403 Forbidden"}

Das normale Update heute früh 4:00 Uhr hat aber auch heute wieder funktioniert.

Hast du eine Idee, woran das liegt, @Dennis_Admin ?

Vielen Dank und Grüße
Mic.

Mic2025 · 17. Juni 2026 um 20:40

Hello again,

nachdem das Problem heute früh wieder aufgetaucht ist, habe ich mein DynDNS-Update-Skript, was mehr als ein halbes Jahr zuverlässig funktionierte, nun umgebaut. Es macht jetzt nicht mehr bei jedem Prüfzyklus (bei mir alle 15 min.) standardmäßig ein IPv6-Präfix-Update sondern prüft vorher, ob sich das Präfix geändert hat. Nur, wenn es eine Abweichung gibt, macht es ein Update auf IPV64. Mal sehen, ob damit mein Counter morgen nicht wieder auf 64/64 vollläuft. Schauen wir mal…

Grüße
Mic.

Mic2025 · 18. Juni 2026 um 05:10

Hallo zusammen,

der Fehler besteht weiterhin und ich bin mir immer mehr - auch wenn ich die Logs in meiner WebGUI von IPV64.net ansehe, mehr und mehr sicher, dass es einen Fehler im Counter gibt. Ich sende am Morgen drei IPv4-/IPv6-Update-Requests und drei IPv6-Präfix-Update-Requests und das führt schon dazu, dass der Counter auf 64/64 voll läuft. Das ist in meinen Augen kein normales Verhalten und kann irgendwie auch nicht an meinem Skript liegen.

Hast du eine Idee, woran das liegen mag, @Dennis_Admin ?

Vielen Dank für eure Hilfe.

Grüße
Mic.

Benares · 18. Juni 2026 um 08:32

Bist du dir wirklich sicher, dass du keine unnötigen Präfix-Updates machst? Log das mal auf Client-Seite.
Evtl. tauchen ja nicht alle Updates auch im Log auf, lassen aber den Update-Counter trotzdem nach oben gehen.

The_eagle · 18. Juni 2026 um 16:33

Hi @Mic2025,

ich kann deine Diagnose,

nicht nachvollziehen. ich aktualisiere per pfsense zwei vollständige IP-Adressen und zwei IPv6-Präfixe. Gezählt werden nur die beiden Aktualisierungen der IP-Adressen, die IPv6-Präfixe bleiben unberücksichtigt. Siehe:

Mic2025 · 18. Juni 2026 um 16:46

Hallo,
ja, da bin ich mir ziemlich sicher. Mein Update-Skript schreibt einen recht umfangreichen Log über alle Schritte, die es macht. Wenn es keine Abwichungen gibt, sehen die Log-Einträge pro Domain so aus:

[2026-06-18 06:30:02] ✔️ [meine-domain.ipv64.de] IPv6-DNS unverändert
[2026-06-18 06:30:02] ✔️ [meine-domain.ipv64.de] IPv4-DNS unverändert
[2026-06-18 06:30:02] 📄 [meine-domain.ipv64.de] Präfix gespeichert: ****:****:****:****
[2026-06-18 06:30:02] 📄 [meine-domain.ipv64.de] IPs gespeichert: IPv6=****:****:****:****:****:****:****:****, IPv4=**.***.***.***

Wenn es eine Abwichung gab, sehe ich das:

[2026-06-18 06:00:09] 🔄 [meine-domain.ipv64.de] IPv6-DNS: ****:****:****:****:****:****:****:**** ≠ ****:****:****:****:****:****:****:****
[2026-06-18 06:00:09] 🔄 [meine-domain.ipv64.de] IPv4-DNS: **.***.***.*** ≠ **.***.***.***
[2026-06-18 06:00:09] 📄 [meine-domain.ipv64.de] Präfix gespeichert: ****:****:****:****
[2026-06-18 06:00:09] 🔗 [meine-domain.ipv64.de] Update-Link: https://ipv64.net/nic/update?key=********************&ip6=****:****:****:****:****:****:****:****&ip4=**.***.***.***
[2026-06-18 06:00:09] 💬 [meine-domain.ipv64.de] Serverantwort: {"info":"nochg","status":"success","ip":{"ipv4":"**.***.***.***","ipv6":"****:****:****:****:****:****:****:****"}} (HTTP 200)
[2026-06-18 06:00:09] ✅ [meine-domain.ipv64.de] Update erfolgreich
[2026-06-18 06:00:09] 📄 [meine-domain.ipv64.de] IPs gespeichert: IPv6=****:****:****:****:****:****:****:****, IPv4=**.***.***.***

Und irgendwann kommt eben diese Response:

[...]
[2026-06-18 06:15:03] ⚠️ [meine-domain.ipv64.de] Serverfehler (429): {"info":"Updateintervall overcommited","status":"403 Forbidden"}
[...]

Ich sehe in meinem Log aber noch ein Problem. Es scheint so, als würde IPV64 DynDNS aktuell Probleme zu haben eine neue IPv4-Adresse an die gängigen DNS-Server zu proagieren.

Mein Log meldet heute morgen, 31x eine Abweichung zwischen der Abfrage per nslookup und der tatsächlichen IPv4 meines DSL-Anschlusses. 31 Update-Versuche sind zwar noch immer keine 64 und würden das Phänomen nicht (ganz) erklären aber irgendwas stimmt hier nicht. Das kann aber wohl nur @Dennis_Admin herausfinden.

Wie gesagt, ich verwende das (bisherige) Update-Skript seit Monaten ohne Probleme und ohne dass ich etwas verändert habe. (Die Änderungen habe ich erst gestern gemacht.)

Ich kann in meinem Skript das IPv6-Präfix-Update per Konfiguration abschalten. Das werde ich mal machen und morgen wieder schauen.

Für solche Fehlersuchen, wäre es ein tolles Feature von DynDNS IPV64, wenn man den Counter (64/64) manuell über die WebGUI wieder resetieren könnte. Verbesserungsvorschlag?

Danke und Grüße
Mic.

The_eagle · 19. Juni 2026 um 05:22

Damit ist doch nun offensichtlich was bei dir los ist und wo das Problem liegt.

31 Update-Versuche sind (bei Dual- Stack-Anschlüssen) 62 Updates der IP-Adressen, denn das Update der IPv4-Adresse und der IPv6-Adresse werden jeweils als eigenständige Updates gezählt.
Ursache sind die Abweichung zwischen der Abfrage per nslookup und der tatsächlichen IPv4 / IPv6 deines DSL-Anschlusses.

Meine pfsense macht genau das nicht. Die guckt nur:

wurde eine IP-Adresse geändert = update oder
wurde keine IP-Adresse geändert = kein update

Allerdings habe ich seit einiger Zeit das Problem, dass die Health-Checks lange Offlinezeiten anzeigen. Mit der pfsense und bei meinem ISP kann ich die Zwangstrennung auf die Minute vorgeben. Bei mir immer 04:59 Uhr.

Heute morgen z.B. hat es bis 05:49 Uhr gedauert, bis der https-Healthcheck zu meinem NC-Server wieder okay war. Also erst 50 Minuten nach Zwangstrennung.

Das bedeutet ja, dass die DNS-Server eine gute dreiviertel Stunde nicht die um 4:59 Uhr aktualisierte IP-Adresse des NC-Servers kannten und der https-Healthcheck nicht klappen konnte.

Meiner pfsense ist das egal. Die will nur aktualisieren, wenn sich die IP-Adressen tatsächlich geändert haben. Du machst aber im Skript ein nslookup und zeigt das nicht die aktuelle IP-Adressen wird erneut aktualisiert. Wenn du das im Abstand von 1 oder 2 Minuten machst, sind die 64 Updates schnell erreicht.

Mic2025 · 19. Juni 2026 um 06:21

Hallo @The_eagle,

ja, genau zu dieser Erkenntnis bin ich nun auch gekommen. Dass ein Update von IPv4 und IPv6 mit nur einem Update-Link als zwei Updates gewertet wird, wusste ich nicht (mehr). Heute früh ist es wieder passiert. (IPv6-Präfix-Updates sind deaktiviert.) Mein Skript startet alle 15 min und ich habe gesehen, dass nslookup erst nach drei, vier Stunden die neue korrigierte IPv6 (nur die änderte sich heute Nacht) zeigte.

Also erscheint es aktuell doch so, dass die DNS-Server, auf die nslookup anspricht, lange nicht aktualisiert werden. Mir erschien es aber sinnvoll, die echten IP-Adressen auf den DNS-Servern zu prüfen, um auch zu schauen, dass ein DynDNS-Update (beim letzten Skript-Lauf) funktioniert hatte. Wenn ich nur „fire and forget“ ein DynDNS-Update triggere, wenn ich lokal eine Änderung sehe, heißt das ja noch lange nicht, dass es auch auf den DNS-Servern korrekt durchgeführt wurde.

Ist dies ein normales Verhalten von DNS-Servern? Ist das Problem eher temporär (weil vielleicht gerade irgendwelche Server an ihre Lastgrenzen kommen) oder muss ich mich darauf einstellen, dass das jetzt dauerhaft so ist? Woher kommt der zeitliche Verzug?

Das würde ja heißen, dass unsere Domains für mehrere Stunden nicht (wirklich) erreichbar sind. Die von IPV64.net bereitgestellten Healthchecks (HTTP/s check) schlagen bei mir übrigens nicht Alarm.

Zwischenfrage an den Experten: Ich kann in meinem Skript für die DNS-Abfrage zwischen nslookup´ und getentumschalten. Istgetent` hier evtl. eine stabilere Alternative?

Ansonsten habe ich in meinem Skript zwei Vergleichsmechanismen eingebaut: Einmal prüft er mit nslookup global, ob es Abwichungen gibt und zweitens speichert das Skript bei jedem Lauf die aktuellen IP-Adressen meines Reverseproxy in einer Text-Datei, gegen die es dann beim nächsten Lauf prüft. Beides ist per Konfigurationsdatei ein-/ausschaltbar. Ich müsste wohl (vorübergehend?) die globale Prüfung, auf die ich mich bisher immer verlassen hatte, abschalten. Irgendwie schade…

Danke und Grüße
Mic.

The_eagle · 19. Juni 2026 um 06:51

Bei mir wie gesagt heute Morgen gut eine Dreiviertelstunde lang nicht. Meist sind es in den vergangenen ca. 10 Tagen so 30 Minuten gewesen. Jedenfalls wenn man den https-Healthchecks vertraut. Von denen bekomme ich ja immer morgens eMails.

Benares · 19. Juni 2026 um 07:57

@Mic2025, welche TTL hast du denn bei deinen DNS-Einträgen eingestellt?
Es könnte ja evtl. sein, dass deine nslookups einfach noch die alten Einträge aus dem DNS-Cache liefern, anstatt die Namen wirklich neu aufzulösen. Probier’s evtl. mal mit einem „ipconfig /flushdns“ vor dem nslookup.

The_eagle · 19. Juni 2026 um 08:32

Moin @Benares, ich mach das seit langem auf meiner pfsense indem ich 90 Sekunden nach der Neuverbindungen den Cache des unbound per cronjob leere.

Das nutzt ja aber leider auch nichts, wenn die DNS propagation seitens ipv64 30 oder 45 Minuten dauert.

Benares · 19. Juni 2026 um 09:37

Mmh, ich hab mal eben testweise einen A-Record (xxx.meinedomain.ipv64.net) mit einer TTL von 10 angelegt und die Adresse mehrfach geändert. Die gängigen Nameserver, z.B. ns1.ipv64.net, 1.1.1.1, 8.8.8.8 … sehen die Änderungen quasi sofort bzw. wie erwartet nach etwa 10s. Auch der Nameserver meines Providers, den meine Fritte verwendet geht mit, nur die Fritte selbst braucht da wesentlich länger, bis sie die neue Adresse auflöst, vielleicht ne Minute, aber keine 30 oder 40 Minuten.

The_eagle · 19. Juni 2026 um 09:53

Wenn ich am Tag mal eine neue IP bekomme (etwa weil der Server nach Update neu starten muss) klappt das auch immer sofort mit der DNS-Propagation.

Das Problem scheint nur in der Nacht / den frühen Morgenstunden zu bestehen. Da sehe ich dann zwei Stunden später dass die https-Healthchecks und auch ein ping-Healthcheck nicht geklappt haben. So wie ich das sehe und verstehe läuft ein https-Healthchecks ja über den FQDN und nicht die aktualisierte IP-Adresse.

Vermutung: nachts, wenn wegen Zwangstrennungen bei ipv64 viele DynDNS-Updates auflaufen, gibt es einen „Stau“ bei der DNS-Propagation, der langsam aufgelöst wird.

Benares · 19. Juni 2026 um 10:24

Was verstehst du denn unter „DNS-Propagation“?
Nach meinem Verständnis fragt jeder DNS-Server erstmal den „zuständigen“ DNS-Server (nslookup -q=ns irgendwas.ipv64.net) für den Namen, wenn er den Namen nicht schon in seinem Cache hat. Dann merkt er sich die Namensauflösung maximal für die Dauer der TTL in seinem Cache.
Ich denke, da müsste schon der „zuständige“ DNS-Server ns1.ipv64.net nachts erst verspätet aktualisiert werden. Das könnte schon der Fall sein. Vielleicht hilft es ja, die Zwangstrennung in einen anderen Zeitraum zu verschieben und nicht den Default (3-4 Uhr) einer Fritte zu verwenden.

The_eagle · 19. Juni 2026 um 10:36

Unter DNS-Propagation verstehe ich die Zeit, die benötigt wird, um aktualisierte DNS-Einträge (wie beispielsweise neue IP-Adressen) weltweit flächendeckend zu übernehmen. Wegen Caching-Mechanismen und der festgelegten Gültigkeitsdauer (TTL – Time to Live) kann dieser Aktualisierungsprozess zwischen einigen Minuten und wenigen Stunden dauern.

Auch der DNS-Server ns1.ipv64.net hat ja eine TTL, vor allem aber evtl. auch die Server die die Health-Checks ausführen. Die speichern ja womöglich die IP-Adressen auch lokal und fragen nicht für jeden Health-Check immer sofort einen übergeordneten DNS-Server.

Benares · 19. Juni 2026 um 11:21

Ich denke, du verwechselst das mit den Zonen-Transfers zwischen den redundanten DNS-Servern einer Domain. Nicht jeder DNS-Server hat die „ganze Welt“ im Bauch, sondern ermittelt auch fremde Namen dynamisch, quasi als Dienstleistung, auch wenn der nicht dafür zuständig ist. Natürlich gibt es da auch Caching-Mechanismen, um die Last zu verteilen.

The_eagle · 19. Juni 2026 um 11:37

Nee, das meine ich nicht. Jeder DNS-Server cached ja eine Zeit lang und fragt nicht jedes Mal nach welche IP zu z.B. google.com gehört. Wenn man z.B. https://www.whatsmydns.net/ nutzt, kann man das ja auch sehen. Wenn man das unmittelbar nach dem Update einer DynDNS IP-Adresse macht, haben nicht immer alle DNS-Server, die dort abgefragt werden, sofort die neue IP-Adresse.