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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to