Hi Joe, Thank you for your thoughtful questions; they have helped me clarify my thoughts. What is my goal? I want to establish a modern, open standard for dynamic DNS updates that can eventually replace the current fragmented landscape. You described the problem perfectly "devices hand-picking from proprietary provider lists, each with their own protocols". The current de facto "standard" is dyndns2, which Dyn documented on their website but never published as a vendor-neutral specification. There's no RFC, just one company's API that others adopted by imitation. This space hasn't seen meaningful evolution in 15 to 25 years, and I believe it deserves a proper, open standard. The protocol specification is published on GitHub as a vendor-agnostic document, intentionally separate from ApertoDNS itself (https://github.com/apertodns/apertodns-protocol). It includes compliance tests. There are already working implementations. I’m not proposing something theoretical, I'm looking to formalize something that already works in production, and ideally see it grow into something the broader community can adopt and build upon. Why am I doing this? Honestly, because I believe connectivity should be accessible to everyone. My guiding principle with ApertoDNS has been "No Walls": no paywalls, no artificial restrictions. I'm not looking for commercial gain. I want to contribute something useful that outlasts any single project or company. Which path makes sense? This is where I'd genuinely appreciate your guidance. Since my goal is maximum adoption, becoming the standard that vendors actually implement,, it sounds like working group adoption might be the stronger path. I'm open to that, but I'll admit I'm uncertain how the process works in practice. If a WG adopts the draft, what typically happens? Do authors remain involved as editors? What kinds of changes are common? I raised this in dnsop because I wasn't sure where else to start. You mentioned dnssd might be more natural. I'm happy to take it there if that's more appropriate. Or if you think ISE is actually the better fit for what I'm describing, I'm open to that perspective too. I appreciate any guidance you can offer. Best regards, Andrea Ferro
> Il giorno 13 gen 2026, alle ore 14:58, Joe Abley <[email protected]> ha > scritto: > > 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]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
