Hi Peter, On extending dyndns2, the bulk syntax you showed addresses real user needs. The draft takes a different approach, building on JSON from the start, with TXT support integrated rather than separate, while still offering legacy compatibility for existing clients (Section 8).
For context deSEC handles aACME DNS-01 through the REST API at desec.io/api/v1/, separate from the dyndns interface at update.dedyn.io. The draft puts IP updates and TXT management under the same protocol (/.well-known/apertodns/v1/), same auth, same path structure. You said dyndns2 is "insufficiently specified/documented/maintained" and that writing a standard would be reasonable. That's what the draft (draft-ferro-dnsop-apertodns-protocol-01.txt) tries to do.I'd value your feedback. Best regards, Andrea Ferro > Il giorno 19 gen 2026, alle ore 16:58, Peter Thomassen > <[email protected]> ha scritto: > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
