Re: [DNSOP] DNSSEC, additional special names & draft-chapin-additional-reserved-tlds-00.txt

[Jim Reid <[e-mail]>]

On 27 Feb 2014, at 11:55, Mark Andrews <[e-mail]> wrote:

> 
> In message <[e-mail]>, Jim Reid writes:
>> On 27 Feb 2014, at 07:42, Mark Andrews <[e-mail]> wrote:
>> 
>>> DNSSEC will eventually be on by default and squatting like this will
>> have negative consequences.
>> 
>> Er, no. Vendors who pluck domain names out of the ether and use them in
>> their products will by definition not have the DNS clue required for
>> deploying a viable DNSSEC. Besides, in the case of CPE, they won't even
>> *need* DNSSEC because the offending domain names (router.home or
>> whatever) get looked up on the internal net. Most likely those names will
>> be used by web browsers that do not have a validating resolver and are
>> already relying on the CPE for DNS. Those lookups will almost never go to
>> the outside, far less validate a signed referral for .whatever from the
>> root.
> 
> And the moment you have a validating brower / app they *will* break.

And this is a problem because... ?

I doubt there will ever be validating browsers/apps for accessing CPE from the inside. They have no need for DNSSEC because everything's on the local net. But let's assume they do. The Netgear app could have a TA for .netgear (say) embedded in it. A more likely scenario is the software hard-wires a locally scoped IP address to the device and doesn't bother with DNS at all. Most CPE is already doing that as a fall-back in case local (unsigned) DNS is broken.

> reserved indefinitely != insecurely delegated

Not delegated at all == ???

> 10.in-addr.arpa is insecurely delegated deliberately to prevent DNSSEC
> breakages.

Sure. But that's in a part of the name space where end client behaviour is known, stable and predictable.

Are you suggesting IANA has to insert provably insecure delegations for every possible string that someone, somewhere might be informally using as a TLD? Good luck with that.