DDNS Updater DDNS Updater 2

[QTip]

Das DELETE kommt nicht von meinem Aufruf, es wird einfach die URL nach API aufgerufen. Sind alle Hosts von der gleichen Domain, evtl. mal nach den Besonderheiten beim Aktualisieren in deinem Domainzentrum suchen? Kannst du mal das Debug.log aktivieren und schauen, ob die einzelnen Einträge gruppiert werden. Sollte eigentlich nicht sein, aber schau bitte trotzdem nach. Ansonsten fällt mir noch der Parameter forcehost=1 ein, der lt. API fehlende RR's automatisch anlegen soll. Wäre aber wohl nur ein Workaround...rufe die Protokollverwaltung auf und hänge im Feld "statische Url-Parameter" einfach das "&forcehost=1" hinten dran -> thisipv4=0&thisipv6=0&forcehost=1

*EDIT*: Habe mir grad mehrere Scripte angeschaut (auch die Offiziellen auf deren Seite), in der Url ist auffälligerweise immer forcehost=1 gesetzt. Lt. API ist dieser Parameter keine Pflicht, nur scheint das dann nicht so recht zu funktionieren. Evtl. ist bei denen grad der Wurm drin. Hast du dieses Verhalten zuvor auch schon beobachten können?

 

[saruman]

Besonderheiten hatte ich schon versucht aufzutun, hab allerdings nichts gefunden. regfish loggt auch nur wann welche Aktion erfolgt ist, nicht aber warum (zum Beispiel "IP Adresse ungültig, RR gelöscht" - nicht dass es die Meldung geben würde, war wirklich nur ein fiktives Beispiel).

Debug.log hab ich gestern eingeschaltet und eben runtergeladen. Es sieht so aus als würde der DDNS Updater sofort beim ersten API Call rückmelden dass der RR bei regfish nicht mehr existiert (im return code sieht man auch die Meldung von regfish man möchte doch bitte &forcehost=1 anhängen). Ich bin aber sicher dass der RR vor dem Aufruf noch bestanden hat, hatte die regfish Verwaltung vorher extra geöffnet und konnte das Verschwinden der Einträge nach dem Aufruf auch bestätigen.

Aufgetaucht ist dieses Verhalten vor ein paar Wochen. Bis ich verstanden hatte warum DS cloud plötzlich nicht mehr synchronisiert (eben weil die RRs weg waren) sind aber ein paar Tage vergangen. Ich kann Dir nicht mehr sagen wann genau das Problem zum ersten Mal aufgetreten ist, die Logs bei regfish reichen leider nicht weit genug zurück.

Rein aus Interesse würde ich mal noch einen Case bei regfish aufmachen wollen. Kannst Du mir dazu sagen wo die Aufrufscripte des DDNS Updaters liegen, damit ich denen den genauen Aufruf nennen kann?

BTW: Hab jetzt erstmal &forcehost=1 angehängt. Im ersten Versuch sind nur ein paar der RRs wieder angelegt worden, beim zweiten Aufruf waren dann alle wieder da. Sehr strange alles.

 

[QTip]

Bezüglich der Aufrufscripte ist dies ein wenig schwierig, da die Aufrufurl immer dynamisch erzeugt wird und so nicht greifbar existiert, Scripte liegen in lib/DDNSUpdater/Module. Du benötigst ja eh nur die erzeugte URL, welche ebenfalls im Debug.log steht. Für die vollständige Zeile, solltest du die Anonymisierung deaktivieren.

Entweder haben wir ein Denkfehler, in der API fehlt etwas oder bei regfish ist der Wurm drin. Da alle von mir überprüften Scripte keine Besonderheiten aufwiesen und die Zeile auch keine neues Tag zu Tage brachte, gehe ich von einem Fehler oder Einschränkung bei regfish aus.

 

[saruman]

Jo, stimmt. Im debug.log ists ja drin. *kopfklatsch*

Case bei regfish ist offen, ich bin gespannt.

 

[saruman]

Antwort von regfish ist da:

"[...] ein Delete kann per dynDNS nur ausgelöst werden, wenn Sie keine IP-Adresse in der Variable "ipv4" übermitteln.

Beispiel: https://dyndns.regfish.de/?fqdn=xy.de.&ipv4=&token=xxxx [...]"

Im debug.log von gestern sehe ich bei den IP-Adressen leider nur x.x.x.x - wahrscheinlich weil ich das anonymisiert hatte?

 

[QTip]

Ja, deswegen die x.x.x.x. Es kann sein, wenn nur die ipv6 aktualisiert wird, denn dann wird kein ipv4 mitgeschickt...umgekehrt genauso. Kann aber nicht sein, dass ich beim Aktualisieren von ipv6 eine ipv4 mitschicken muss.

 

[saruman]

Also ich hab eben mal ein bisschen rumgetestet. Erstmal habe ich den Parameter &forcehost=1 aus dem Regfish Aufruf wieder entfernt und das debug.log noch mal ohne Anonymisierung eingeschaltet. Darin kann ich sehen dass IPv4 RR geupdatet werden können wenn sie vor dem gleichnamigen IPv6 RR aktualisiert werden. Wird erst der IPv6 RR aktualisiert führt das anschließende Aktualisieren des gleichnamigen IPv4 Records zur Fehlermeldung der Host existiere nicht.

Resultat ist aber in beiden Fällen gleich: Der RR wurde bei Regfish gelöscht.

Könnte also sein dass Deine Vermutung mit der fehlenden IPv4 Adresse schon in die Richtung geht. Oder ich habe einfach nur die Konfiguration falsch angelegt.

Beim Testen ist mir nämlich noch was aufgefallen: Selbst wenn ich für einen Host nur ein Update der IPv4 Adresse im DDNS Updater 2 angelegt habe, so wird mit forcehost=1 trotzdem auch ein IPv6 RR angelegt. Bug oder Feature? Im Falle eines Features wäre mein Verständnis der Konfiguration falsch, deswegen frage ich.

Ich lege nämlich immer zwei Update-Einträge für ein- und denselben RR im DDNS Updater 2 an, einmal mit IPv4 und einen zweiten mit IPv6. Ist das prinzipiell richtig?

 

[QTip]

Es kann natürlich auch sein, dass man beim Aktualisieren beider IP's nur einen Aufruf machen darf. Der 2. Aufruf, zum Aktualisieren des anderen IP-Types, beeinflusst dann vermutlich den vorherigen Eintrag wieder. Das würde allerdings mein bisheriges Konzept zur Zeit nicht mitmachen, da müsste ich mir etwas zu überlegen.

Funktioniert es, wenn du für jeden Host nur einen IP-Typ aktualisierst und das forcehost=1 dabei weglässt? Wenn ja ist meine obige Vermutung richtig

 

[saruman]

Okay, hab einen Testeintrag bei regfish erstellt (sowohl IPv4 und IPv6, mit demselben Hostnamen) und forcehost=1 wieder gelöscht.

Dann im Updater einen neuen Host angelegt "Benutze IPv6" nicht ausgewählt. Update erzwungen und: Der IPv4 Eintrag wird aktualisiert, der IPv6 Eintrag hingegen nicht angefasst.

Also bei regfish alles wieder zurückgestellt und im Updater im Hosteintrag "Benutze IPv6" ausgewählt. Update erzwungen und nun: Der IPv6 Eintrag wurde aktualisiert, der IPv4 Eintrag gelöscht.

Macht Dich wahrscheinlich grad nicht glücklicher...

Kurze Anmerkung: Bin das Wochenende über unterwegs. Kann mögliche Tests also erst am Montag wieder durchführen.

 

[QTip]

Hm, ok, also bezugnehmend auf die Antowort vom regfish Support "[...] ein Delete kann per dynDNS nur ausgelöst werden, wenn Sie keine IP-Adresse in der Variable "ipv4" übermitteln." vermute ich, das die das DELETE nur an ipv4 gekoppelt haben. Deshalb wird die IPv6 bei Aktualisierung von nur IPv4 nicht angerührt, umgekehrt aber die IPv4 entfernt. Bei Aktualisierung von IPv6 muss eine IPv4 mitgeschickt werden, sonst wird sie gelöscht. Welche IP steht dann in IPv4, wenn du bei Aktualisierung von IPv6 forcehost=1 übergibst? Bleibt die "alte" erhalten oder wird die aktuelle öffentliche gesetzt - hierfür am besten die IPv4 zuvor manuell setzen. Wenn dann die ursprüngliche IP erhalten bleibt, dann müssen wir nur forcehost=1 mitschicken, damit die IPv4 nicht gelöscht wird. Allerdings hattest du kein eindeutiges Ergebnis bei deinen Tests mit forcehost=1.

Mein Problem ist, dass pro Eintrag nur ein IP-Typ gesetzt wird. Ich müsste extra Abfragen durchführen, um an die vom 2. Eintrag gesetzte IPv4 zu kommen, damit diese mit der zuvor gesetzten IP identisch ist.

Vielleicht solltest du den Support noch mal fragen wie die sich vorstellen, dass man nur die IPv6 aktualisieren möchte, ohne die IPv4 zu verändern. Ein neues Tag "hostdelete=1" wäre logischer und um die Kopplung mit der IPv4 aufzuheben.

Schönes Wochenende

 

[saruman]

Bei bestehendem IPv4 und IPv6 RR und einem Update mit forcehost=1 _nur_ für den IPv6 Eintrag wird der IPv4 Eintrag gelöscht und der IPv6 Eintrag mit der neuen IPv6 Adresse versehen.

Hab jetzt noch ein wenig mit wget rumgespielt. Ausgangssituation: IPv4 und IPv6 RR existieren mit total sinnlosen Werten (auch zwischen den Tests habe ich diese Ausgangssituation jedesmal wiederhergestellt). Folgende Ergebnisse:

wget -O - "https://dyndns.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv4=0&ipv4=1.1.1.2&ipv6=1111::2222&forcehost=0&ttl=60"
wget -O - "https://dyndns.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv6=0&ipv4=1.1.1.2&ipv6=1111::2222&forcehost=0&ttl=60"
Beide RRs werden aktualisiert.

wget -O - "https://dyndns.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv4=0&ipv4=&ipv6=1111::2222&forcehost=0&ttl=60"
wget -O - "https://dyndns.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv4=0&ipv6=1111::2222&forcehost=0&ttl=60"
wget -O - "https://dyndns.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv6=0&ipv4=&ipv6=1111::2222&forcehost=0&ttl=60"
wget -O - "https://dyndns.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv6=0&ipv6=1111::2222&forcehost=0&ttl=60"
wget -O - "https://dyndns.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv4&thisipv6=0&ipv4=&ipv6=1111::2222&forcehost=0&ttl=60"
wget -O - "https://dyndns.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv4&thisipv6=0&ipv6=1111::2222&forcehost=0&ttl=60"
IPv4 gelöscht, IPv6 aktualisiert.

wget -O - "https://dyndns.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv4=0&ipv4=1.1.1.2&ipv6=&forcehost=0&ttl=60"
wget -O - "https://dyndns.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv6=0&ipv4=1.1.1.2&ipv6=&forcehost=0&ttl=60"
wget -O - "https://dyndns.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv4&thisipv6=0&ipv4=1.1.1.2&ipv6=&forcehost=0&ttl=60"
IPv4 aktualisiert, IPv6 gelöscht.

wget -O - "https://dyndns.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv4=0&ipv4=1.1.1.2&forcehost=0&ttl=60"
wget -O - "https://dyndns.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv6=0&ipv4=1.1.1.2&forcehost=0&ttl=60"
wget -O - "https://dyndns.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv4&thisipv6=0&ipv4=1.1.1.2&forcehost=0&ttl=60"
IPv4 aktualisiert, IPv6 unverändert.

wget -O - "https://dyndns.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv4=0&ipv4=&ipv6=&forcehost=0&ttl=60"
wget -O - "https://dyndns.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv6=0&ipv4=&ipv6=&forcehost=0&ttl=60"
wget -O - "https://dyndns.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv4&thisipv6=0&ipv4=&ipv6=&forcehost=0&ttl=60"
Beide RR gelöscht.

wget -O - "https://dyndns.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv4=0&forcehost=0&ttl=60"
wget -O - "https://dyndns.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv6=0&forcehost=0&ttl=60"
wget -O - "https://dyndns.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv4&thisipv6=0&forcehost=0&ttl=60"
IPv4 gelöscht, IPv6 unverändert.

Status war jedesmal "succeeded".

Anfrage beim regfish-Support, wie man denn _nur_ den IPv6 RR aktualisieren kann ohne den IPv4 RR zu löschen oder zu verändern ist draußen.

 

[QTip]

OK, das Löschen scheint auch bei ipv6=leer zu funktionieren. Hast du zur Aktualisierung der IPv6 mal dyndns6.regfish.de als Updateserver probiert?

 

[saruman]

Damit wirds noch schlimmer:

Beide Aufrufe

wget -O - "https://dyndns6.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv6=0&ipv4=&ipv6=1111::2222&forcehost=0&ttl=60"
wget -O - "https://dyndns6.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&thisipv6=0&ipv6=1111::2222&forcehost=0&ttl=60"

lassen den IPv4 Eintrag zwar unangetastet, allerdings igrnorieren beide den Parameter ipv6=... und setzen statt der angegebenen Adresse lediglich die Adresse des anfragenden Hosts - also das, was bei thisipv6=1 eigentlich geschehen sollte. forcehost=1 ändert daran leider auch nichts.

 

[QTip]

OK, dann gehe ich wirklich von einem Problem bei denen aus, das ist ja nicht mehr mit Logik kontrollierbar.

Danke für deine Mühen.

 

[saruman]

Nichts zu danken, ganz im Gegenteil.

Ich hab das dyndns6.regfish.de Thema mal als Update ins Regfish-Ticket geschoben. Mal sehen ob da was kommt. Wenns interessiert schieb ichs hier auch gern noch hin.

 

[saruman]

Update von Regfish:

"[...] es hat anscheinend historische Gründe, dass bei Aufruf der dynDNS URL ohne Übergabe von "thisipv4=1" oder "ipv4=xxx" der entsprechende Adresszeiger gelöscht wird.

Wie Sie festgestellt haben, ist dies bei Nutzung der URL dyndns6.regfish.de nicht mehr der Fall.

Bitte verwenden Sie in der URL nicht gleichzeitig thisipv6 und ipv6. Durch Entfernen von "thisipv6=0" in der URL funktioniert der Aufruf wie von Ihnen gewünscht.

"https://dyndns6.regfish.de/?token=$TOKEN&fqdn=foo.bar.de.&ipv6=1111::2222&forcehost=0&ttl=60" [...]"

Kann ich bestätigen. IPv4 müssen also mittels

wget -O - "https://dyndns.regfish.de/?token=TOKEN&fqdn=foo.bar.de.&ipv4=1.1.1.2&ttl=60"

aktualisiert werden, IPv6 aber mit

wget -O - "https://dyndns6.regfish.de/?token=TOKEN&fqdn=foo.bar.de.&ipv6=1::2&ttl=60"

forcehost=1 darf nur gesetzt werden wenn der Host nicht existiert. Und thisipv4/6=1 nur wenn die anfragende IP gesetzt werden soll, nicht aber wenn der Parameter ipv4/6= genutzt werden soll. Die beiden schließen sich also quasi gegenseitig aus.

 

[QTip]

Die beiden Servereinträge für IPv4 und IPv6 existieren schon, nur die beiden thisipv4/6=0 müssen entfernt werden. Nur das nun die API-Beschreibung nicht mehr stimmt, denn dort steht:

3.1.3. Der Parameter "thisipv4"

Der Parameter "thisipv4" (This IPv4) gibt an, ob die IP-Adresse des Anfrage stellenden Computers als neue IP-Adresse genutzt werden soll. Ist der Wert "1", wird also die IP des Anfrage stellenden Computers genutzt, während bei der Übermittlung des Wertes "0" ein weiterer Parameter obligatorisch wird, nämlich "ipv4".

 

[saruman]

Tja, wenns man so einfach wäre. Im CLI mit wget funktioniert das Update der IPv6 Adresse zwar (mit den o.g. Einschränkungen, aber immerhin). Wenn ich im Updater im regfish Protokoll aber thisipv4/6 entferne ("Statische URL-Parameter" ist also komplett leer) und den IPv6 Eintrag aktualisieren möchte machts *plopp* und der IPv4 Eintrag ist wieder weg.

Dass die API von regfish b0rken und rottig ist, ist mir schon öfter aufgefallen. Allerdings sind thisipv4/6 ja nur optionale Parameter, die per Default auf 0 stehen.

Ich hab den Case bei regfish mal weiter belebt... Sorry!

 

[saruman]

Irgendwie hat mich das Thema regfish nicht losgelassen (sorry wenn ich nerve ) und ich hab noch mal ein wenig rumprobiert. Letztlich konnte ich das Löschen des A Records aber nur verhindern indem ich in der Protokollverwaltung jeweils eigene Protokolle für IPv4 und IPv6 angelegt habe und das dann auch in der Anbieterverwaltung weitergeführt habe (beides stell ich bei Bedarf natürlich gerne zur Verfügung).

Mangels Anleitung unter http://www.synology-forum.de/showthread.html?64657-DDNS-Updater-2-Anleitung-Instructions (*hint* ) habe ich mir ein paar Dinge zusammengereimt, bin mir aber nicht sicher ob das so stimmt:

1.) Nur um sicherzugehen (sorry für die Noob-Frage): Ob ein A oder ein AAAA Record eines Hosts aktualisiert wird hängt doch einzig und allein am Haken "Benutze IPv6" (unter Allgemein/Verbindung der Hostkonfiguration)?
2.) In der von Dir mitgelieferten Protokolldefinition für regfish steht in den "Feld zu Url-Parameter Zuordnungen", dass die IP dem URL-Parameter ipv4 zugeordnet werden soll. Sehe ich das richtig, dass dann der Parameter ipv4 immer in der Update-URL auftaucht, egal ob ich IPv4 oder IPv6 updaten möchte?
3.) Oder ersetzt der "Url-Parameter für IPv6 IP" weiter oben in der Protokolldefinition den Parameter ipv4 durch den dort angegebenen Parameter (aufgrund der Erfahrungen mit regfish würde ich behaupten dass bei einem IPv6-Update der Parameter ipv6=... nur angehängt wird, letztlich also beide Parameter im Request auftauchen)?
4.) Muss in der Anbieterverwaltung zwingend ein IPv6 Aktualisierungsserver eingetragen sein wenn ich mir eine IPv6-only-Definition baue oder wird bei einem leeren Eintrag automatisch der unter AKtualisierungsserver" eingetragene Host genutzt? Kann evtl. auch einfach der Aktualisierungsserver leer bleiben und ich trage einfach nur einen "Aktualisierungsserver IPv6" ein?

Jetzt aber wieder raus in die Sonne, schönes Restwochenende allen. Und QTip: Danke für ausdauerndes Supporten.

 

[QTip]

sorry, bin aber leider noch nicht dazu gekommen, die angekündigte Anleitung zu erstellen

zu 1.) Oberfläche: Die Checkbox "Benutze IPv6" ist nur sichtbar bzw. auswählbar, wenn in der Grundkonfiguration "nur IPv6 (DS-Lite)" oder "IPv4 und IPv6 (Dual Stack)" gewählt wurde und in der Anbieterverwaltung "IPv6 möglich" gesetzt ist. Gleichzeitig werden alle Anbieter ausgefiltert, welche den entsprechenden IP-Type nicht bedienen können.
Backend: Hier bestimmt der Schalter IPv6, ob das Feld "Url-Parameter für IPv6 IP" für die Aufnahme der IP und "Aktualisierungsserver IPv6" als Aktualisierungsserver verwendet wird, wenn gefüllt. Auch der zu verwendene IP-Typ wird hiermit eingestellt, da nur ein IP-Feld in der Hostkonfiguration existiert.
Ob A oder AAAA Eintrag verwendet wird, hängt von den gesendeten Parametern der API ab, also z.B. ipv6= bei regfish.de oder type=aaaa bei cloudflare.com.

zu 2.) Das Feld "Url-Parameter für IPv6 IP" wurde erst später von mir eingebaut und ist nur als optionales Feld zu sehen. Dies entstand damals aus dem Umbau und Zusammenführung der IPv4/IPv6 Protokolle. Da nicht jeder Anbieter separate Felder für IPv4 und IPv6 IP's benutzt, musste ich mir eine Lösung einfallen lassen.

zu 3.) Es ist immer nur einer der beiden Einträge in der Url vorhanden. Ist IPv6 nicht gefüllt, dann wird der default Parameter aus der "Feld zu Url-Parameter Zuordnungen" ebenfalls für IPv6 verwendet.
Habe es grad noch mal getestet...
IPv4:

http://dyndns.regfish.de/?thisipv6=0&thisipv4=0&ipv4=1.2.3.4&token=xxx&fqdn=xxx.regfi.sh.

IPv6:

http://dyndns6.regfish.de/?thisipv6=0&thisipv4=0&ipv6=1.2.3.4&token=xxx&fqdn=xxx.regfi.sh.

zu 4.) "Aktualisierungsserver IPv6" ist optional und wird in Abhängigkeit der IPv6 Konfiguration des Hosts benutzt (siehe 1.), wenn vorhanden ersetzt er den "default Aktualisierungsserver" für IPv6 Anfragen, der "default Aktualisierungsserver" muss konfiguriert sein

Da es mit getrennten Protokollen funktioniert, kann es nur an den statischen Parametern liegen, da immer beide mitgesendet werden.
Du könntest auch noch probieren, in der Anbieterverwaltung den HTTP Methode von POST auf GET umzustellen.