Hi Warren, Michael, Thank you both, this exchange highlights exactly why standardization matters. That's what I thought when I started all this.
Michael raises an important point about real-world edge cases: copy-paste errors, TTL conflicts, services changing APIs. These are exactly the scenarios the draft tries to address. The modern API provides JSON responses, structured error codes, configurable TTL (60-86400s), explicit record deletion via null values, and documented last-write-wins semantics for conflict handling. Warren's use case is also covered: the legacy /nic/update endpoint (Section 8) accepts inline credentials for constrained devices like OpenGear. The draft aims to serve both, simple for those who need simple, modern for those who need proper error handling, TXT/ACME support, and bulk updates. I take all the feedback and responses I receive from all of you at DNSOP seriously. Thank you for this exchange. Best regards, Andrea Ferro ApertoDNS > Il giorno 23 gen 2026, alle ore 16:38, Warren Kumari <[email protected]> ha > scritto: > On Wed, Jan 21, 2026 at 8:44 AM, Michael Richardson <[email protected]> > wrote: > -------- > <#multipart sign=pgpmime> > Are you replying from the address you want us to use? support@ ?? > [email protected] <[email protected]> wrote: > The DoH angle is interesting. RFC 3007 over HTTPS with proper authorization > could be a cleaner long-term approach, though it would require more > complexity on the client side It's very interesting. The current HTTP-based > design prioritizes simplicity for embedded devices and existing DDNS client > ecosystems. > It's not simpler. The complexity is either not addressed, or is just hidden. > The fact that historical dyndns services *could* be used with a one-line CURL > failed to address most of the real world complexity. For many, they are > comparing 3007 vs that one-liner (in their head), even when the one-liner had > faded into fiction. > Well, maybe. It depends on the use-case… > I have quite a few sites that I help manage for friends and family. These are > basically all on "residential broadband" type services, and so have dynamic > IPv4 addresses, which change regularly, possibly gratuitously. > In order to manage these I have a web of point-to-point VPNs, and some > hub-to-spoke VPNs, and some similar. All I need is a mostly up to date > mapping of name → IPv4 address, and a combination of curl and "DynDNS style" > solutions is working perfectly for this, and has for many years. > I don't need to set the TTL, update anything other than an address, delete > records, devconflict updates (if I have multiple sites trying to update a > record I have bigger issues!), ACME, etc. > Sure, some people might need that, and that's worth solving too — but my > actual day to day experience looks like: > I'm setting up a new OpenGear termserver[0] on a cable link. I'd like to be > able to find it in the future, so I can reach it at 3:00AM without faff. > OpenGear supports the following protocols: > dyns.cx > dyndns > gnudip > ods > tzo > 3322 > For each of these it wants: > DDNS Server ("The format is server address:port") > DDNS Hostname > DDNS Username > DDNS Password > Interval > <Some other bits which I ignore> > I try these various protocols with a fairly random selection of parameters. > OpenGear's UI implies it wants server.example.com:443, so I try that. No > love. No useful error either. > I futz with things. > server.example.com:80? > https://server.exmaple.com? > No love. > I go look at the documentation for my (free) Dynamic DNS provider - > DuckDNS.org[1]. It has documentation for: > OS: > Linux cron, linux bsd cron, linux netcat cron, linux GUI, DotNet Core Script, > mono windows-gui, windows-script, windows-powershell, windows-c#, osx, > osx-homebrew ,osx IP Monitor, osx-ios, RealDNS, android pi, raspbmc ec2. > Routers > openwrt, tomatoUSB, mikrotik, fritzbox, dd-wrt, allied telesis, technicolor > tg582n, zte h108n, pfSense, freenas, EdgeRouter, smoothwall, synology > hardware. > Standards > GnuDIP.http, DynDns, inadyn, DNSOmatic. > Great! Both things support GnuDIP and DynDNS. I'll try the DynDNS option…. > Gah. There are 2 version of the documentation: > https://nouser:[email protected]/nic/update?hostname=wk-ts1&myip=1.1.1.1&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG > v3 version > http://nouser:[email protected]/v3/update?hostname=wk-ts1&myip=1.1.1.1 > I have no idea which DynDNS my terminal server supports, but one starts with > http:// and the other with https:// - I guess that that means that > www.duckdns.org:443 or www.duckdns.org:80 were correct… No idea why things > failed… but let's try just paste the entire bit after the password from the > first version into the "DDNS Server ("The format is server address:port")" > box. An error…. But now it is a different error… > I try the second variation…. And now I'm not even getting an error. Perhaps I > worked? Nope. > I poke around randomly. Eventually, after about an hour it starts working. > I'm too afraid of the whole thing to even look at the settings in case it all > stops working again. > Yes, in this case the OpenGear documentation could have been clearer, and > yes, the error messages which I sometimes got could have been more > descriptive…. But this general see of issues occurs with basically every > different set of CPE / hardware that I try. > Simply having one of the well known "standards", like DynDNS, which seems to > be the most supported by the set of hardware and CPE that I've encountered, > be better defined and documented would go a massive way towards making things > more useable. > I agree that this only solves a small part of the problem, and yes, many of > your issues below would be nice to solve eventually — but the code quality > and complexity on many bits of CPE argues for solving the dirt simple > solutions first — which, AFAICT, is basically "a one line CURL" which is well > defined….
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
