Re: [dnsext] Re: need new flag bit in EDNS, "do me no favours" (DMNF)

[Nicholas Weaver <[e-mail]>]

Why would the misbehaving DNS authorities bother?

They either have clean opt-outs (eg, Comcast's is reasonably enough and permanent: it changes the DHCP config so that in the future you get a clean resolver.  Only if you change your cable-modem does this need resetting), or DELIBERATELY unclean opt-outs (Verizon's 'change your DNS resolver settings', Bell canada's for a while was even worse: it added a cookie which simply caused the wildcard page to display a fake browser error page!)


So in the former case, this is unnecessary, and in the latter case, why would they bother?  They've made a deliberate decision to make it hard and hostile.



Additionally, the comment elsewhere that "we have a 'don't bother me': use DNSSEC and/or local resolution" is correct.  

Comcast's is supposedly going away as they turn on DNSSEC (because its fundamentally incompatible in their opinion, http://www.dnssec.comcast.net/faq.htm#faq7 
http://tools.ietf.org/html/draft-livingood-dns-redirect-03#section-8.1
).


And I've argued repeatedly that the DNSSEC validation for "normal" records (A, AAAA, MX, etc) should be on the client as follows:

IF the chain validates, accept the record from the cache.

If, for any reason (no sig, broken sig, no root, whatever) the validation fails, do an independent fetch bypassing the recursive resolver.

And this policy eliminates the problem of the lying recursive resolver, AND creates an incentive for people to deploy DNSSEC without the penalties of deploying DNSSEC incorrectly.