> On 2 May 2025, at 15:12, Ben Schwartz <bem...@meta.com> wrote: > > We are comparing two options, and two types of deployments: > > Option A: .internal is provably nonexistent at the root > Option B: .internal is an unsigned delegation at the root > > Type 1: A deployment that controls the stub's DNSSEC configuration > Type 2: A deployment that cannot customize the client's DNSSEC configuration > > For Type 1, options A and B achieve the same security and functionality. > Either way, the deployment can make use of .internal as a signed or unsigned > zone, by configuring stubs with a local positive or negative trust anchor. > > For Type 2, "A" makes .internal empty for validating stubs, whereas "B" > entrusts its contents to the recursive resolver.
Whereas "B" fails the validating stub resolver by allowing .internal to be spoofed. > The ICANN SSAC report suggests that one goal of .internal is to support > devices that can function "without a priori knowledge of the network > environment in which those devices are deployed". This suggests that the > SSAC intends for .internal to be usable in Type 2 deployments. I prefer not to read between the lines what SSAC did or did not intend. > I think the working group could reasonably publish a recommendation that > "root zone owners" (i.e. ICANN) who are reserving "private-use TLDs" (i.e. > .internal) SHOULD use an unsigned self-delegation unless "Type 2" deployments > are clearly out of scope, for the sake of compatibility with non-customized > validating stub resolvers. SAC113 has had no practical impact on the root zone. The .internal domain has never existed in the root zone, and since the root has been signed (approximately 15 years ago) it can now be cryptographically proven not to exist. Given that stub validators exist, mechanisms for adding or removing trust anchors for the root must also exist, especially considering the root key has already been rolled over once. Therefore, it's reasonable to assume a method for deploying negative trust anchors is also available. In environments where customising a client's DNSSEC configuration isn't possible, there's likely a compelling reason for this restriction, and a software limitation alone shouldn't be considered sufficient justification. Warmly, Roy _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
