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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Nicholas W
eaver writes:
> 
> On Mar 30, 2011, at 6:12 AM, Marc Lampo wrote:
> 
> >=20
> > Mark Andrews <[e-mail]> wrote:
> >>=20
> >> 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.
> >=20
> > =46rom 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. =20

And w/ dnssec you detect this.
 
> 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!

And w/ dnssec you detect this.
 
> 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!

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

> This way, DNS is on the same security level as the rest of the traffic: =
> controllable only by a direct MitM. =20
> 
> 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,=20
> 
> 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.=
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]