Ich nehme an, dass im Kundencenter von selfhost, erst die Hostnamen angelegt werden müssen.
So liest sich das tatsächlich ... nur wurde ja auch schon von erfolgreichen Updates berichtet, sowohl für die IPv4- als auch die IPv6-Adresse - nur eben nicht für beide gleichzeitig. Das würde - in meinen Augen - ja dafür sprechen, daß beide Einträge bei
selfhost.de in deren Web-Interface korrekt angelegt sind.
Wobei dieses Stochern im Nebel ja ebenfalls nicht erforderlich ist ... es gibt in den Support-Daten (gerade eben anhand einer 07.51-Labor-Version noch einmal von mir geprüft) ja auch einen Abschnitt
dyndns, in dem das Protokoll der Aktionen des
ddnsd von AVM zu finden ist und darin wird auch haarklein aufgelistet, welche Prüfungen erfolgen und welche Updates versucht werden und das auch mit dem jeweiligen HTTP-Inhalt (Request + Response).
Da würde man also auch die jeweiligen Antworten des HTTP-Servers (carol.selfhost.de) sehen können ... falls der die Updates (es sollte beim verwendeten Format ja zwei davon geben) positiv quittiert, dürften die notwendigen Einstellungen bei
selfhost.de auch stimmen.
Ich halte es nämlich nicht für unmöglich, daß tatsächlich auch mit den URLs in #32 ein Update funktionieren kann ... bei mir schickt jedenfalls der
ddnsd auch bei JEDEM Update-Versuch einen HTTP-Header für die "basic auth" mit (den man im Protokoll dann "maskieren" sollte, wenn man es anderen zeigt, ebenso wie den eigenen Host-Namen und ggf. auch die (konkreten) IP-Adressen, aber mit Augenmaß) und diesem Header kann (bzw. wird) der Prozessor für den CGI-Request ebenfalls den Benutzernamen entnehmen (das Kennwort wurde - wenn
REMOTE_USER gesetzt ist - bereits zuvor vom HTTP-Server geprüft und für richtig befunden) und solange dann in der QueryString keine Werte für
username und
password gesetzt werden, braucht es auch keine (eigene) Prüfung der Berechtigung(en) - spannend wäre hier ggf. noch, was bei widersprüchlichen Angaben im HTTP-Header und in der QueryString passiert bei
selfhost.de.
Ist dann obendrein im Benutzerkonto für den verwendeten Account (identifiziert anhand des Benutzernamens) nur ein einziger Host-Name (bzw. eine Subdomain, das ist ja "DNS") konfiguriert, könnte sogar dieser eine als Fallback verwendet werden, wenn in der QueryString die korrekte Angabe (nach der Auskunft des Supports ja
hostname und nicht
host) dieses Wertes fehlt. Für mich ist es also keineswegs sicher, daß man mit dem Aufbau der URLs aus #32 KEIN gültiges Update bewirken kann ... sollte das so sein, würde ich aber auch vom DynDNS-Update-Service eine passende Antwort erwarten und auf solche Antworten (alles außer
good oder
nochg sollte ein Problem darstellen:
https://help.dyn.com/remote-access-api/return-codes/) reagiert der
ddnsd von AVM m.W. auch entsprechend - wobei auch hier wieder nicht festgelegt ist, wie auf eine Antwort "200 OK" im HTTP-Protokoll und meinetwegen ein (gleichzeitiges)
badauth im HTTP-Content zu reagieren wäre; deshalb gibt es häufig auch Einstellungen für die "erwarteten" Antworten (was bei AVM aber auch nicht der Fall ist, auch nicht bei "benutzerdefiniert").
Denn es gibt eben auch keinen RFC für DynDNS-Updates per HTTP-Request - zumindest kenne ich keinen. Als Referenz kann man ggf. auf den DynDNS-Daemon von OpenWRT zurückgreifen, wobei dort für
selfhost.de auch nur ein Mechanismus für IPv4-Updates hinterlegt ist:
https://github.com/openwrt/packages...files/usr/share/ddns/default/selfhost.de.json (bei IPv4 + IPv6 sähe das z.B. so aus:
https://github.com/openwrt/packages...files/usr/share/ddns/default/duckdns.org.json).
Aber da kocht auch jeder Programmierer so eines CGI-Prozessors mehr oder weniger sein eigenes Süppchen und daher kann man dort auch die jeweiligen Antworten (für den Erfolgsfall) hinterlegen:
https://github.com/openwrt/packages...ts/files/usr/share/ddns/default/ddnss.de.json - dabei gibt es aber auch keine standardisierte Angabe für IP-Adressen und deren Formate.
Im "ursprünglichen" API (damals noch dyndns.org, heute dyn.org) war das "Aufzählen" von IP-Adressen mit Kommata zwischen den Adressen vorgesehen (
https://help.dyn.com/remote-access-api/perform-update/), womit sich der Wert auch wieder leicht (durch einen einzigen zusätzlichen Aufruf, der beim Fehlen eines Kommas im Wert auch keine (negativen) Auswirkungen hat) in ein Array überführen ließ.
Aber daraus ergibt sich auch sofort wieder die nächste Frage ... bei einem Router in einer Kaskade, der seinerseits nur eine "nicht-routbare" IPv4-Adresse auf seiner WAN-Seite hat, wird ja auch gerne darauf zurückgegriffen, daß der DynDNS-Provider gar nicht die IP-Adresse aus der QueryString eines Requests verwendet, sondern die Adresse, von der das Update bei ihm erfolgt und auch hier ist m.W. NICHTS geregelt, was bei widersprüchlichen Angaben am Ende in der DNS-Zone einzutragen wäre.
Schon ein Update mit einer IPv4-Adresse in der QueryString, das als HTTP-Request per IPv6 beim Server ankommt, dürfte bei vielen dieser Anbieter äußerst unterschiedliche Reaktionen hervorrufen und zu unterschiedlichen Ergebnissen führen, solange man das nicht über Parameter in der QueryString noch genauer festlegen kann. Ähnliches gilt für ein Update, wo in der QueryString eine andere IPv4-Adresse (die bereits erwähnte, nicht zu routende) angegeben ist und der Provider am Ende dennoch die IP(v4)-Adresse, von der der Update-Request kam, verwendet.
Nur müßte man für eine Fehlersuche ohne Glaskugel eben auch mal das Protokoll (hier) zeigen ... mit den bereits erwähnten "Maskierungen", was Host-Namen, IP-Adressen und - sofern vorhanden - auch im
Authorization: Basic ...-Header und (falls auch MyFRITZ! verwendet wird für DynDNS) auch den Benutzernamen in einem
Authorization: Digest ...-Header anbelangt. Der Rest sollte "unkritisch" sein im Hinblick auf "persönliche Daten" (auch der Rest in einem Digest-Header, der halt "kryptisch" aussieht) ... also kein Grund, damit hinter dem Berg zu halten.
Was man halt nur "von Hand" hinbekommen kann, ist die SYSTEMATISCHE Prüfung, was ein (einzelnes) Update wirklich bewirkt - dazu müßte man eben mit
wget und
dig (bzw.
nslookup) erst ein Update (und zwar MIT Anzeige der HTTP-Ausgabe inkl. aller Header) ausführen (lassen) und danach das Ergebnis in den DNS-Daten prüfen ... und zwar sowohl für irgendwelche IPv4- als auch IPv6-Adressen und nicht nur für die Einträge, für die man dabei Änderungen "erwartet" (also auch dann IPv4 überprüfen, wenn man ein IPv6-Update ausgeführt hat). Denn das macht der
ddnsd von AVM am Ende auch (soweit ich das bisher gesehen habe) - er überprüft immer (zeitverzögert nach dem Update) BEIDE Formate von IP-Adressen, wenn er Updates ausgeführt hat.
Der "implizite" Wert des MyFRITZ!-DynDNS für
touchtime (die Angabe, wann ein erneutes Update erfolgen soll, auch wenn sich die Adresse(n) seit dem letzten erfolgreichen Update nicht geändert hat/haben) ist - nebenbei bemerkt - auch nur 86400 Sekunden (also ein Tag), wobei nicht der Zeitpunkt der Verifikation als Start gilt, sondern tatsächlich der Zeitpunkt des Updates. Beim "benutzerdefinierten" Service könnte es sogar darauf hinauslaufen, daß es solche Updates (für nicht geänderte Adressen) gar nicht mehr gibt (ab 07.5x), denn der (über das GUI nicht änderbare) Wert für
touchtime bei diesem Eintrag stand bisher immer auf
touchtime = 0w; - was diese (automatische) Erneuerung der Registrierung deaktiviert(e).
Es gibt aber immer noch auch (DynDNS-)Provider, die für korrekte Funktion ein Update innerhalb eines vorgegebenen Zeitraums erwarten ... dann muß man - sofern der eigene (Internet-)Provider keine Zwangstrennung vornimmt - sich irgendwie selbst darum kümmern, daß solche Updates irgendwann auch mal erfolgen; notfalls durch Editieren der
touchtime in der
ar7.cfg. Die Notwendigkeit regelmäßiger Updates entfällt (in aller Regel) nur dann, wenn man sich einen kostenpflichtigen Account bei einem Provider zulegt - dann interessiert sich niemand dafür, ob die Subdomain auch tatsächlich genutzt wird, solange die Zahlungen regelmäßig eingehen. Aber bei kostenlosen Accounts ist es auch heute noch Usus (exemplarisch:
https://www.noip.com/de-DE/remote-access), daß regelmäßig das Interesse an dieser Subdomain "erneuert" werden muß (entweder durch Update oder irgendwie anders per GUI o.ä.).
Ich bin aber nicht wirklich sicher, wie sich das beim
ddnsd geändert hat, als AVM die ganzen vordefinierten Provider abgeschafft und parallel dazu "versäumt" hat, ein paar weitere Werte (
livedelay - die Zeitspanne, die zwischen "online" und einem Update gewartet wird, damit mehrfache Neustarts nacheinander nicht das Update-Limit per Zeitintervall reißen, was bei vielen (DynDNS-)Providern auch noch gilt - und
touchtime) wenigstens als "zusätzliche Einstellungen" zugänglich zu machen (EDIT: über das Variablen-Interface (Lua oder auch
ctlmgr_ctl) lassen die sich schon heute setzen, nur fehlt eben die Umsetzung im GUI).
Meinen "Test-Boxen" kann man dabei nicht trauen, denn die haben i.d.R. eben KEINE öffentlichen (IPv4-)Adressen und das prüft AVM zumindest mal ab und zeigt es dann auch an, wenn man dennoch einen DynDNS-Service einrichten will in der Box. Für einen "richtigen" Test ist es aber (für mich) auch noch zu früh - für solche Änderungen (in den Neuigkeiten steht dazu auch nur:
- Änderung Vordefinierte Auswahl von DynDNS-Anbietern durch eine allgemeine Einstellmöglichkeit ersetzt) lohnen sich Test meines Erachtens erst dann, wenn es tatsächlich eine Release-Version gibt und das ist (für die bei mir vorhandenen FRITZ!Box-Modelle) bisher nur bei der 7590 überhaupt der Fall.
