Hi Andrea, I think it's clear that the Dyn style of update protocols are widely-deployed and that it would be better to have a single, good protocol than to have to implement ten different protocols on every home gateway that ships and ask people to choose between them during setup.
My personal opinion is that this is a nice piece of work to bring to the IETF. It fits a pragmatic need and there's a clear benefit to interoperability. My other personal opinion is that this style of update protocol has very little to do with the DNS protocol, and that dnsop is probably not the right place to find people to work on it. There are several different organisations that provide services for these kinds of protocols, and no shortage of client implementations. Perhaps if you all banded together you could find the energy to form a nice, tightly-scoped working group to produce a specification and running code. Joe > On 19 Jan 2026, at 09:57, 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. > 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? > 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?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. > _______________________________________________ > 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]
