Updated laufend mit Docker DDNS-Updater qmcgaw/ddns-updater

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

    {
      "provider": "custom",
      "domain": "DomainRecord",
      "url": "https://ipv64.net/nic/update?key=1234567890.....",
      "ipv4key": "ipv4",
      "ipv6key": "ipv6",
      "success_regex": "good|nochg|true|OK|success",
      "proxied": true,
      "ip_version": "ipv4",
      "ipv6_suffix": ""
    }

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)

Die Angaben sind forumgerecht verändert.

Danke für den Hinweis, ich darf meine Lesebrille nicht mehr mit Salami putzen….

Ich habe das nun mal getestet mit der config

{
  "provider": "ipv64",
  "domain": "xxxxxx.ipv64.de",
  "key": "1234567890..................",
  "proxied": true,
  "ip_version": "ipv4",
  "ipv6_suffix": ""
}

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.

vor was soll dich denn CDN schützen?

Klar, bei aktivem CDN löst nslookup zu einer anderen IP-Adresse auf, als der zuletzt aktualisierten.

Den hatte ich ja laufen, aber ich wollte da nicht verstreut da und dort etwas laufen haben. Bis jetzt war der Container jedenfalls aktiv.

Schutz ist jetzt vlt. etwas weit gegriffen, nennen wir es Verschleierung. Muss man erst mal drauf kommen, wenn diese Themen sonst eher mitlaufen.