Re: [dnsext] caches, validating resolvers, CD and DO

[Nicholas Weaver <[e-mail]>]

On Mar 30, 2011, at 8:22 AM, Mark Andrews wrote:
>> OH GOD NO!
>> 
>> The problem is that the forwarding or caching nameservers are a security =
>> disaster.  They lie, cheat, and manipulate results with reckless =
>> abandon. =20
> 
> And w/ dnssec you detect this.

Until they strip DNSSEC information.  You MUST validate locally....

>> Thus probably the best default policy for DNSSEC validation is:
>> 
>> Validate on the client (sending all requests with DO and CD!
> 
> You don't need CD to validate.
> 
>> Don't let =
>> the resolver in between validate, you can't trust it anyway so why have =
>> it waste cycles?). 
> 
> Because you want it to sort out when a authoritative server has stale
> DNSSEC data, authoritative servers that are not dnssec enabled, .....
> It's much easier for the recursive server handle this directly and
> give the stub resolver answers that have been successfully validated.


You want the end client to have its own policy on what to do on DNSSEC failure, not be dependent on the resolver's policy, and thus validating clients really should use CD with every request.


EG, I'd WANT clients to be able to visit www.dnssec-failed.org IFF the client is able to contact the root, .org, and Comcast's DNS servers directly.

That way, the client knows that it can trust the DNS information to exactly the same degree that it can trust the rest of its network traffic.


>> If local validation successful, accept.
>> 
>> If failed (For any reason, including no DNSSEC information at all [1]), =
>> the client MUST contact the authorities directly (NOT through the =
>> intermediary systems) and accept the results without validation [2].
> 
> That's nice when you can do it, but there are lots of enviroments
> where you can't.  We need to make those deployment senarios work.
> Failures are not alway malicious.

You notice that the proposed policy ONLY causes a failure IFF:

a)  There is an actual DNSSEC failure-to-validate (not simply "no DNSSEC").  
AND
b)  The client is prohibited from contacting authoritative DNS servers directly.