It appears that Ben Schwartz <[email protected]> said: >-=-=-=-=-=- > >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. > >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 honestly don't recall the details of the discussion but I think it's at least as likely that we meant that the magic can happen at the local cache so you don't need per device setup like you do for .onion or .alt. I keep seeing a lot of assumptions about how devices will work with precious little support for them. My personal unsupported assumption is that the number of devices in the "we use the cache but don't believe what it says" camp is small enough not to matter. R's, John _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
