Hi Andrea,
On 1/14/26 20:59, Andrea Ferro wrote:
- IPv6 was not part of the original design: Dyn's own documentation states that
"certified update clients only support dynamic updates to IPv4 host records"
[1]. IPv6 support was added later through various non-standard extensions, some providers
use a myipv6= parameter, others require separate endpoints, others rely on
connection-based auto-detection. This fragmentation causes ongoing interoperability
issues, as documented in ddclient issues #607 [2], #769 [3], and #715 [4].
Interesting, thanks for the pointers.
We've been running the dyndns2 protocol for more than 10 years at deSEC, and
while there is the occasional ddclient configuration issue (or bug, in older
versions), we haven't encountered issues with IPv6 support (neither single- nor
dual-stack), despite our service having been integrated in various CPE devices.
the IPv6 fragmentation problem, for example, cannot be solved without breaking
backward compatibility with some existing implementations.
If you can pinpoint the specific compatibility here, I'd appreciate to learn.
(But perhaps let's do it off-list, as this would get more off topic.)
bulk update support - features that cannot be retrofitted into the legacy
protocol without breaking existing implementations.
We're currently implementing bulk support and are almost done [1].
It looks like (newlines for readability):
/?hostname=example.com,sub.example.com # update those names ...
&myipv4=<ipaddr> # with this IPv4 address
&myipv6=<ip6addr> # and this IPv6 address
&myipv6:sub.example.com=2001:db8::/64 # except only update the prefix
for sub.example.com [2]
&myipv4:example.com=preserve # and in fact don't update A
for this name (only AAAA)
Now this is a somewhat pathological example (as in, not really useful). But,
we're not developing these features speculatively; each of the features
showcased (bulk updates, prefix updates, exceptions) has been requested
repeatedly by our users.
My point really is that the dyndns2 protocol can indeed be extended like that.
(Similar things could be done for authentication, preferred response content
type etc.)
That said, I agree that dyndns2 is insufficiently
specified/documented/maintained (and our extensions currently are not much
better in that regard). Writing up a standard about it would be a reasonable
thing to do.
Best,
Peter
[1]: https://github.com/desec-io/desec-stack/pull/1141
[2]:
https://desec.readthedocs.io/en/latest/dyndns/update-api.html#:~:text=In%20some%20cases,value%20is%20ignored.
--
Like our community service? 💛
Please consider donating at
https://desec.io/
deSEC e.V.
Möckernstraße 74
10965 Berlin
Germany
Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
