Hi Andrea, I have often wished for a standard way to do this kind of thing. It has always seemed crazy to see devices like consumer home gateways having to hand-pick from a large list of ddns providers, each with their own protocols, in order to provide this kind of functionality. The ability so select an arbitrary, interoperable provider (and potentially to discover one, based on some suitable heuristic) always seemed like an obvious thing to want.
The closest I ever found was wide-area bonjour (as described in this page, which I sense has not been updated in a long time, <https://dns-sd.org/ClientSetup.html>). This worked for me quite nicely on Mac OS X up until some point 10-15 years ago when it didn't. I remember opening my laptop in random IETF meetings and having my remote backup minions connect successfully over ssh to rsync copies of my data back home. Back in those days this even seemed like a safe and sane thing to do. I had a quick skim through your draft, and the immediate question that sprang to mind was: what is your goal, here? If the goal is to document an existing, useful protocol in the RFC series, there are other avenues for that: you could find an AD willing to sponsor it or you could try the ISE. I presume your goal is to create a stable reference that encourages interop? Have you considered why the RFC series is a good place for this, compared to (say) a web page that you maintain yourself? What was your thinking? If the goal is to take an existing protocol as a starting point but then hand over change control to an IETF working group, understanding that they might well change it in ways you would probably not have done yourself, then finding a working group willing to adopt it is a good first step. Is that what you are doing? If a working group is the right venue for this, why dnsop? I'm not saying dnsop would be the wrong place necessarily, but I'm interested in your thinking. Your protocol is certainly DNS-adjacent but it's not really concerned with the operation of the DNS protocol, more in the provisioning of the namespace. To be clear I am asking these questions because I am interested in your answers, not because I am criticising your instincts or dislike your draft. I'm sure both your instincts and your draft are magnificent. :-) Joe > On 13 Jan 2026, at 13:03, Andrea Ferro <[email protected]> wrote: > > Hi DNDOP, > > My name is Andrea Ferro. I recently submitted an I-D proposing a standardized > protocol for consumer Dynamic DNS services. > > There is also an TXT version available at: > https://www.ietf.org/archive/id/draft-ferro-dnsop-apertodns-protocol-00.txt > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ferro-dnsop-apertodns-protocol/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ferro-dnsop-apertodns-protocol-00.html > > The motivation is simple: consumer DDNS has been around for 25+ years > (ddclient, inadyn, countless routers and IoT devices), but there's never been > a formal specification. Everyone just reverse-engineered the dyndns2 protocol > and built their own variations. This has led to inconsistent implementations, > fragmented IPv6 support, and vendor lock-in. > > The draft proposes a RESTful alternative using well-known URIs (RFC 8615), > JSON, and bearer tokens. It's designed to be provider-agnostic - any DDNS > service can implement it. > > I have a working implementation in production at apertodns.com, so this isn't > just theoretical. > I'm looking for feedback on whether this is appropriate work for DNSOP, and > whether there's interest in adoption. Happy to present at a future session if > useful. > > > Best regards, > Andrea Ferro > [email protected] > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
