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

[Nicholas Weaver <[e-mail]>]

On Mar 30, 2011, at 6:12 AM, Marc Lampo wrote:

> 
> Mark Andrews <[e-mail]> wrote:
>> 
>> A validating resolver with direct access to the athoritative servers
>> can work around a number of operational errors by being able to
>> retry the query with different servers.
> 
> From the security point of view, letting "resolvers" (on end-user PC's)
> have access to authoritative servers is not a good idea.
> End-users should forward there queries to (internal ?) forwarding or
> caching name servers (only).

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.  

Its not just NXDOMAIN wildcarding, we now have multiple ISPs which use DNS to man-in-the-middle search properties (google, yahoo, bing), redirecting traffic to a unknown THIRD party, for unknown reasons!

Thus end systems should be prepared to bypass these cesspools at the drop of a hat whenever necessary.  The caching/forwarding architecture in DNS has proven itself to be a security disaster, as its has proven to be an active man in the middle on DNS but can not be a MitM on normal traffic.


Thus probably the best default policy for DNSSEC validation is:

Validate on the client (sending all requests with DO and CD!  Don't let the resolver in between validate, you can't trust it anyway so why have it waste cycles?).  

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




This way, DNS is on the same security level as the rest of the traffic: controllable only by a direct MitM.  

And mandating that it still be used in cases of DNSSEC failure is a bad idea:  When DNSSEC fails, and its due to adversarial action, its that caching/forwarding service that is most likely to be responsible.


[1] The "security" policy you desire however can be maintained if the following rule is added on client validation:

IF No DNSSEC information AND Can not contact ANY authority
THEN:
Accept the results from the configured recursive resolver blindly, 

Because you have no choice in the matter as your network is controlled by a direct MitM who's blocking all DNS except through the configured resolvers.


[2] Except for things like key material or other new RRs which are not used to determine which host to contact.