> 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] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
