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

["Jeffrey A. Williams" <[e-mail]>]

nick and all,


-----Original Message-----
>From: Nicholas Weaver <[e-mail]>
>Sent: Oct 26, 2010 1:11 PM
>To: namedroppers WG <[e-mail]>
>Cc: Nicholas Weaver <[e-mail]>
>Subject: Re: [dnsext] Re: need new flag bit in EDNS, "do me no favours" (DMNF)
>
>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
  I was and remain more concerned about section 8.2 see:
http://tools.ietf.org/html/draft-livingood-dns-redirect-03#section-8.2
which suggests without defining that "the valid A record
   contained valid, lawful, non-malicious content, and there would
   otherwise appear to be no valid justification for a redirect to
   occur."  
What is 'Valid and non-malicious content' in such a 
   context?  Would some content in say the WSJ.com's web pages be 
'malicious' or perhaps playboy.com's web pages?  Some would answer yes
other would answer no, but who decides, the service provider by virtue
of their omnipitant wisdoms use of DMNF, the user or perhaps the Apps
browser/developer/provider in their own near omnipitant wisdom? My answer is
the user at the browser level where such security settings options belong.
Seems very recently though that some browser developers are also not wanting
allow for this either, see Google: 
http://www.prnewswire.com/news-releases/google-sued-for-violating-the-privacy-rights-of-millions-of-americans-105719403.html
and Firefox:
http://www.net-security.org/secworld.php?id=10042

>
>
>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.

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

Also agreed here.
>
>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.

spot on IMO.
>
>
>
>
>
Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [e-mail]
Phone: [phone]