Hi Andrea, Thank you for reaching out dnsop for this work.
I have one comment about “Which path makes sense?” part below. As with current WG charter, DNSOP is responsible for DNS dispatch in the IETF. Here is the relevant charter excerpt: “DNS-related I-Ds that don't have an obvious WG which could adopt them can be submitted to the DNSOP WG for consideration. The DNSOP WG will advise on the appropriate way to progress these I-Ds, for instance by suggesting the most suitable WG or recommending the chartering of a new WG” With that in mind, I suggest that you continue the discussion here in dnsop (including requesting a slot in the DISPATCH part of IETF#125) to hopefully converge on a recommended next step for your draft. Cheers, Med (as DNSOP Area Director) PS: You may look at https://datatracker.ietf.org/group/dconn/about/ for an example of a recently chartered tiny WG to exemplify which kind of changes may happen if the community decodes to take this work. De : Andrea Ferro <[email protected]> Envoyé : mardi 13 janvier 2026 20:08 À : Joe Abley <[email protected]> Cc : [email protected] Objet : [DNSOP] Re: Introducing draft-ferro-dnsop-apertodns-protocol-00.txt 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]<mailto:[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]<mailto:[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]<mailto:[email protected]> _______________________________________________ DNSOP mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
