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: <http://example.com:443/>80? https://server.exmaple.com <http://server.exmaple.com:443/>? No love. I go look at the documentation for my (free) Dynamic DNS provider - DuckDNS.org <http://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 <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 <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…. W [0]: I really like the OpenGear - they are relatively cheap (especially on eBay!), and have cellular modems which can be configured to come up if a readability test fails, or you can dial in, etc. They are fast, friendly, and support crash logs. Yes, I know I could pay for a management solution where they are managed as a group, but I'm not prepared to do that for my personal projects… [1]: I also really like DuckDNS - it's free, it has documentation for many many different things, the people running it seem cool (I don't actually know who they are, but the site just feels friendly — if y'all are here, thank you!!!). > Issues include: > 1. what TTL to use. > 2. whether to update A, AAAA or both. > 3. how to delete a record. > 4. how to manage other record types. > 5. what to do when two clients update the same record. > (like my current and old laptop...) > 6. various kinds of v6 addresses. > 7. removing my AAAA record because I have no v6 today (laptop) > 8. timeliness of update, particularly around TXT challenge records (ACME) > > {I'm not saying these issues have not been addressed by more mature > protocols, what I'm saying is that when comparing things to 3007, people do > not compare the same things} > > I have been blessed with historical (swamp) v4, so seldom needed dyndns > service for my *infrastructure*... I've regularly used it to deal with ssh > into laptops/client "servers", etc. including paying a fee. I went back to > 3007 to my own infrastructure. > > As Mark says, TSIG is really just a username/password. There are some > gotchas getting it right. > A problem is that the server has to have all the passwords in plaintext, > or at least all the servers I know do. Maybe there are pre-hash options. > > So a breach discloses everyone's password. > **This is a problem SIG(0) does not have** > > <#part type="text/plain" disposition=inline description=Signature> > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on rails [ > > _______________________________________________ > 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]
