Ich verwende auf einem NAS in Docker den bekannten qmcgaw/ddns-updater und möchte den alcapone1933/ddns-ipv64 daher eigentlich nicht mehr nutzen, da ich mit dem DDNS-Updater noch einige weitere DNS-Adressen aktuell halte und daher das zentral verwalten möchte.
Im Grunde funktioniert das auch, jedoch im Gegensatz zu allen anderen DNS-Adressen wird die IP-Adresse bei jedem IP-Check geupdated, obwohl sich die IP nicht geändert hat. Dies führt dazu, dass die 64 Maximalabfragen in 24 h innerhalb weniger Stunden aufgebraucht sind.
Momentan sieht die Sequenz wie folgt aus, wobei es keine Rolle spielt, ob ich die Domain-Update-URL verwende oder die Account-Update-URL
Ist „DomainRecord“ richtig? Sollte da nicht eher die Domain stehen? Dagegen wird m.W. geprüft ob ein Update notwendig ist. Und wieso „custom“? ipv64 wird doch direkt unterstützt (s. hier)
aber der Effekt war zuerst unverändert. Wenn PERIOD=5m (oder auch anders) abgelaufen ist, wird die IP geupdated, obwohl diese sich nicht verändert hat. Den Parameter “proxied“ habe ich hinzugenommen, keine Änderung.
Dann ist mir eingefallen, dass für diese Domain der CDN-Service aktiviert ist, um bei der Verwendung des DNS einen besseren Schutz zu haben, aber dadurch wird eine andere IP verwendet und die stimmt nicht mit der eigentlichen IPv4 überein. Nach dem deaktivieren läuft nun der DDNS-Updater korrekt, wahrscheinlich auch mit dem custom config.
Ich nehme an, dass in dem Container alcapone1933/ddns-ipv64 das so individuell versteuert wird, dass ohne Änderung einer IP gar keine Checks erfolgen, oder der CDN-Service mit einbezogen wird. Für den Betrieb des Containers wird letztlich auch nur die Domain-Update-URL und die Domain angegeben, wie oben auch.
Hi Andy,
ich nutze bei mir den Updater von alcapone1933, der checkt alle 15 Minuten über https://ipinfo.io/ip, ob ein Update notwendig ist, meist macht er nichts.
2026-08-19T10:30:21.594502855Z [ddns-ipv64] ==============================================================================================
2026-08-19T10:45:00.773750487Z [ddns-ipv64] 2026-08-19 12:45:00 INFO !!! - IPv6 ist deaktiviert (IPV6_ENABLED=no)
2026-08-19T10:45:00.773839881Z [ddns-ipv64] 2026-08-19 12:45:00 INFO !!! - IPv4 Detection gestartet...
2026-08-19T10:45:00.773859783Z [ddns-ipv64] 2026-08-19 12:45:00 INFO !!! - IPv4 gefunden: 89.245.77.197 (Quelle: https://ipinfo.io/ip)
2026-08-19T10:45:00.773872399Z [ddns-ipv64] 2026-08-19 12:45:00 INFO !!! - IPv6 ist deaktiviert
2026-08-19T10:45:01.773859232Z [ddns-ipv64] 2026-08-19 12:45:00 KEIN UPDATE - IPv4=89.245.77.197 IPv6=
2026-08-19T10:45:01.773926413Z [ddns-ipv64] ==============================================================================================
2026-08-19T11:00:00.961504163Z [ddns-ipv64] 2026-08-19 13:00:00 INFO !!! - IPv6 ist deaktiviert (IPV6_ENABLED=no)
2026-08-19T11:00:00.961598646Z [ddns-ipv64] 2026-08-19 13:00:00 INFO !!! - IPv4 Detection gestartet...
2026-08-19T11:00:00.961619945Z [ddns-ipv64] 2026-08-19 13:00:00 INFO !!! - IPv4 gefunden: 89.245.77.197 (Quelle: https://ipinfo.io/ip)
2026-08-19T11:00:00.961634444Z [ddns-ipv64] 2026-08-19 13:00:00 INFO !!! - IPv6 ist deaktiviert
2026-08-19T11:00:01.961907570Z [ddns-ipv64] 2026-08-19 13:00:00 KEIN UPDATE - IPv4=89.245.77.197 IPv6=
Es war aber schon öfter Thema hier, dass, abhängig von der Tageszeit, Updates zwar in der Datenbank von ipv64.net ankommen (Web-Interface zeigt die korrekte IP), aber das Update der DNS-Server (nslookup xxxxxx.ipv64.de) erst stark verzögert erfolgt. Bei mir hat es geholfen den Zeitpunkt der zuvorkommenden Zwangstrennung aus den Stoßzeiten (3-4 Uhr) auf 1-2 Uhr zu verlagern. Nun stimmt auch DNS relativ zeitnah.