In message <b67b8708-66d9-4372-b3e4-58fbc3297...@rfc1035.com>, Jim Reid writes: > On 27 Feb 2014, at 07:42, Mark Andrews <ma...@isc.org> 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. > > There may be a need for a reserved suffix. It doesn't have to be > > .HOME. Rewarding bad behaviour leads to more bad behaviour. > > IMO, the draft aims to document existing bad behaviour and explains why > people should stop doing those bad/stupid/wrong things. Or at least > appreciate the consequences. This is a Good Thing. It might even mean > fewer instances of bad behaviour in future. Whether of course the writers > of CPE crapware will ever read this RFC, let alone act on it, is another > matter. At least the IETF will have produced a useful document on the > topic. Which is all it could do. > > BTW, the latest thinking (ie as of yesterday) from ICANN is .home will be > reserved indefinitely: > http://www.icann.org/en/news/public-comment/name-collision-26feb14-en.htm. > It doesn't matter now whether someone wants to call that "rewarding bad > behaviour" or not. That train left the station a long, long time ago. > [And I'm long past caring either way.] So it seems to me ICANN is > acknowledging reality and taking prudent measures for overall security > and stability of the DNS. Too much stuff is already (ab)using .home so > this TLD can't go into the public root for the obvious reasons. reserved indefinitely != insecurely delegated 10.in-addr.arpa is insecurely delegated deliberately to prevent DNSSEC breakages. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop