Hi, klingt nach meinem Problem: Update in einem Call möglich? sub.home64.de und pre.sub.home64.de, selbe IPv4, unterschiedliche IPv6 - #9 von Gl1der .
Bisherige Erkenntnis: der Fall scheint nicht vorgesehen oder dokumentiert zu sein. Würde mir die Integration dieses “Features” auch wünschen.
Meine bisherige Lösung: FRITZ!Box klopft gar nicht mehr bei IPv64.net, sondern auf meinem Server (nur billiger Webspace mit PHP) an, und übermittelt einfach sämtliche benötigten Daten (IPv4, IPv6 der Box, IPv6-Präfix, auf Wunsch auch noch Weiteres, man kann die URL ja frei gestalten und auf dem Webspace parsen). Dort läuft ein Skript, welches dann die einzelnen Updates bei IPv64.net ausführt (ist ja nur ne URL abrufen, und die richtigen URLs werden eben von dem Skript zusammengebaut - hier könnte man dann auch die Record-Keys “hardcoden”, oder man übergibt den Domain-Key (oder Account-Key) als “Passwort” aus der FRITZ!Box).
Das Skript meldet dann das Ergebnis seines ersten Updates (“good”, “nochg”…) an die FRITZ!Box zurück (und loggt sämtliche Aufrufe mit URL und JSON-Ergebnis von IPv64.net).
Derzeit versuche ich (bzw. die KI mit meinen blauäugigen Prompts) noch, das Skript so anzupassen, dass es zunächst einmal eine DNS-Anfrage macht, um herauszufinden, ob überhaupt ein Update nötig ist (weil wohl auch nochg gegen das Updatelimit zählt). Aber ich hab auch nicht den ganzen Tag zeit, das ist work in progress. Und das Skript achtet eigentlich auch auf das Maximal-3-Updates-in-10-Sekunden-Limit, aber das habe ich (also die KI) wohl bei einer der letzten Änderungen zerschossen… (das Skript ist ohnehin bisher ein heilloses durcheinander mit verschiedensten Fragmenten, übrig gelassenen alten Codeschnipseln, auskommentierten Funktionen, die ich wahrscheinlich nie wieder brauchen werde, und täglich wird’s noch schlimmer… aber die Grundfunktionalität ist gegeben).
Ach, jüngste Beobachtung: wenn man mit einem Aufruf nur das IPv6-Präfix aktualisieren will, dann sollte man wohl &onlyprefix mit übergeben. Denn auch wenn man keine IPv4 mitsendet, ermittelt IPv64 diese wohl anhand des Aufrufs, und aktualisiert diese auch - mit der des Skript-Servers. Damit wird dann wohl auch eine nur Sekunden vorher “korrekt” auf die der FRITZ!Box gesetzte IPv4 überschrieben. Aber: still more testing needed.
Vorteil einer solchen Lösung meines Erachtens jedenfalls: Updates werden nur ausgeführt, wenn sich an den IPs der FRITZ!Box auch wirklich etwas ändert. Also nicht nach cron-Zeitplan, der x Mal am Tag läuft, aber dann doch vielleicht erst 20 Minuten nach einer Änderung. Und welche Updates ausgeführt werden, kann ich frei bestimmen. Ich könnte auch andere DynDNS-Anbieter (mit URL-Update-Möglichkeit) einbinden. Und mit der vorherigen DNS-Abfrage (wenn sie funktioniert), wird auch kein Update ausgeführt, falls z. B. Teile gleich bleiben sollten. Die FRITZ!Box führt (gut zu Testzwecken) nämlich nach meinen Beobachtungen auch ein Update nach Änderung “ihrer” DynDNS-URL (oder anderen Daten von der Seite) aus.
In deinem Fall könnte so etwas auch klappen, wenn du doch bereit wärst, die URL in der FRITZ!Box (einmalig) zu ändern, und den bisher gut funktionierenden Aufruf eben von deinem Skript erledigen ließest. Es ist jetzt ja auch nicht so, dass es ein Hexenwerk wäre, ein “Backup” von deiner jetzigen URL (und ggf. Domain/Benutzername/Kennwort) in einer Textdatei anzulegen, um zum jetzigen Zustand zurückkehren zu können.
Tatsächlich aber bin ich weiterhin erstaunt, dass eine so nahe liegende Funktionalität nicht einfach bereits in IPv64.net integriert ist. Ich stelle aber natürlich hier keine Ansprüche - was da ist, ist ja schon extrem gut.