Just picking one of these emails. What’s all the FUD here about?
There is *nothing* new here. CPE boxes have done UPDATE to change their addresses to *non authoritative* servers using UPDATE for at least a decade now. DYN DNS did this. The updates used TSIG for authentication. Mac also does this. There is a SRV prefix registered for finding the update server. Apple registered SRV prefixes at least twice for this _dns-update._tcp, _dns-update._udp in 2019 and there where earlier ones which I can’t find on the current IANA website. https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=dns This one may be a re-registration. They have also registered a one using TLS. Using SIG(0) to update delegations has been part of the protocol since the RFC 2931 was published. The reason UPDATE has a ZONE section is to allow parent zones to be updated. NS and glue records initially. DS once it came into existence. Having a update policy that allows you to update the name derived from the key name and its children is also straight forward. The obvious one is a one to one mapping. It was so obvious that we just implement it approximately 2 decades ago. The original policy set had “self”. We added sub domains of the key a little later. We added record count restrictions by type later still. commit 6e373c502584f9292e964378411d296c8259026b Author: Mark Andrews <[email protected]> Date: Thu Feb 16 01:34:24 2006 +0000 1983. [func] Two new update policies. "selfsub" and "selfwild". [RT #12895] Now the only thing here is to formalise what has been supported for DECADES now by saying everyone should JUST DO IT. I wrote a draft in 2013 https://www.ietf.org/archive/id/draft-andrews-dnsop-update-parent-zones-04.txt about how to do this. It used TSIG but SIG(0) works just as well. Nothing proposed then was new. -- Mark Andrews > On 26 Oct 2023, at 04:21, Johan Stenstam > <[email protected]> wrote: > > > >> On 25 Oct 2023, at 18:58, Joe Abley <[email protected]> wrote: >> >> On 25 Oct 2023, at 18:46, Johan Stenstam >> <[email protected]> wrote: >> >>> I agree. But it is bad to design a system where the key CANNOT be rolled. >> >> I agree. I was just expressing doubt that you can find a single automated >> mechanism that is appropriate to use in all possible compromise scenarios. >> >> For a hopefully rare event that might need careful handling, perhaps a good >> manual plan is actually better. > > I agree with this also. > > And that functionality is already there. If you’re using BIND9 it is your > decision, in the update-policy {} section, whether to allow dynamic updates > to update the key (i.e. roll the key) or only update NS, glue and DS RRsets. > My own code does the same. And in most cases manual fallback in case of a key > compromise is likely the best option. > > Johan > > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
