Hi Mark, Thank you for the various points and m advice that, I really appreciate. Your points on TSIG and SIG(0), I hadn’t fully considered the SIG(0) bootstrap flow where the device generates the keypair and exports the KEY record. That’s a cleaner provisioning model, especially if manufacturers pre-generate device-specific keys.
I’ll be testing this approach against the current HTTP-based implementation to evaluate the trade-offs. I also agree on IPv4 scalability. The protocol treats IPv4 and IPv6 as first-class citizens, with native support for both in a single atomic update. CGNAT realities make dual-stack support even more important now. Appreciate you taking the time. Best regards, Andrea Ferro > > >> >>> On 19 Jan 2026, at 19:55, Andrea Ferro <[email protected]> wrote: >>> >>> Hi Mark, >>> >>> Thank you for the detailed feedback. >>> You’re right that RFC 2136 UPDATE forwarding is well-defined (Section 6), a >>> provider could accept UPDATE and translate to their backend. And DoH wire >>> format could technically carry UPDATE messages. >>> >>> However, I’d like to understand how you’d address these practical gaps: >>> • >>> Router DNS codee consumer CPE devices run dnsmasq, which is a stub >>> resolver/forwarder, it has no RFC 2136 UPDATE construction code. OpenWRT’s >>> ddns-scripts shells out to the external nsupdate binary. Adding UPDATE+TSIG >>> support would require significant new code. >> >> One always has to write code AT BOTH ENDS. We already have well tested code >> to process UPDATE requests in DNS servers by multiple vendors. That’s one >> end dealt with, it just has to be enabled. There are already standalone >> command line tools that can send update requests using TSIG or SIG(0) as the >> authenticator. >> >>> • Key distribution RFC 2845 explicitly states “No provision has been >>> made here for distributing the shared secrets.” GSS-TSIG solves this via >>> Kerberos, but consumer devices aren’t domain-joined. How would a provider >>> provision TSIG keys to millions of users? >> >> TSIG is really nothing more than a username (expressed as a domain name) and >> a password (shared secret) with an algorithm identifier thrown in. You use >> the device's fully qualified name for the username. >> >> If one goes down the SIG(0) route the device generates a public key pair >> using a specified algorithm, saves it to internal storage, then displays the >> KEY record for that key. This is cut-and-pasted into the zone at the >> device's name. This is the bootstrap step. The manufacture could generate >> device specific keys. >> >>> • The EDNS option i couldn’t find an existing EDNS option that replaces >>> 0.0.0.0/:: with requester IP. This would require a new specification, >>> correct? >> >> If one goes down that route. One could just use the existing “what is my >> ip” services and construct the UPDATE request without the option. One could >> also just use the IP addresses that are assigned to the device via DHCP / >> SLAAC or have been negotiated by the device with the CGNAT. There are a >> number of existing protocols to do this. For this to work to work you >> really want the ISP giving you address that can be reached from the public >> internet, i.e. one that is NOT behind a CGNAT. You shouldn’t need to use a >> “what is my ip” service. >> >> Note none of this scales with IPv4 as there are not enough address in the >> world for every CPE device to have its own unique IP address. ISP’s need to >> get off their collective backsides and deliver IPv6. >> >>> I’m genuinely open to exploring RFC 2136 over HTTPS if there’s a path >>> forward on authentication. What would you suggest? >> >> >>> Best regards,Andrea Ferro >>> >>> >>> So just promote RFC 2136. These boxes already have DNS code in them. >>> >>> It really isn’t hard to construct an UPDATE request. RFC 2136 has been >>> used for decades now between DHCP servers and DNS servers but there is >>> no requirement that UPDATE requests be processed on a nameserver, >>> UPDATE requests are able to be forwarded. >>> >>> RFC 2136 has also been used for decades with GSS-TSIG with Active >>> Directory. >>> >>> All this seem to add is a built in "what is my IP address” service >>> and adding an EDNS option which says to replace 0.0.0.0 and :: with >>> the requester’s IP address would suffice to achieve the same thing. >>> >>> Is there any real difference between a CPE box and everything else >>> that uses RFC 2136 today. Is it just NIH coming into play? >>> >>> If you really must use HTTPS then just encode the request as is done >>> for DoH. >> >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: [email protected]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
