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

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Mar 2011 17:23:35 +1100

I don't think we have the sematics of these bits quite right
yet.  In normal operations a validating resolver taking to
a cache should just set DO.  This will result in DNSSEC records
being returned and in most cases these will validate.  This
also permits caches to do their jobs correctly.

When these do not validate or SERVFAIL is returned, the validating
resolver should then re-issue the query with CD set and a EDNS
option indicating which upstream servers have been tried.  This
option is initially empty.  The cache will then behave as a proxy
for this query (excluding the EDNS option) adding the responding
server's address to the EDNS option.  If there are no more addresses
to try, SERVFAIL (new rcode?) is returned along with the EDNS option
from the query.

If the cache is using another cache the entire query/response is
proxied.  The intent is for the validating client to talk through
intermediate caches to the cache talk directly to the authoritative
servers.  The EDNS option maintains a list of authoritative server
addresses for the zone that have been tried.  This list is passed
back and forth between the validating resolver and the cache talking
to the authoritative server.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Alex Bligh <[email-masked]>
Date: Wed, 30 Mar 2011 07:42:32 +0000

--On 30 March 2011 17:23:35 +1100 Mark Andrews <[email-masked]> wrote:

> option indicating which upstream servers have been tried.

Why "should"? Effectively the validating resolver is handing off
DNSSEC validation to the upstream server here isn't it? It might not
want to trust the upstream server, particularly if it's already
got records that don't validate.

-- 
Alex Bligh

---

From: Paul Vixie <[email-masked]>
Date: Wed, 30 Mar 2011 07:02:51 +0000

> From: Mark Andrews <[email-masked]>
> Date: Wed, 30 Mar 2011 17:23:35 +1100
> ...
> resolver should then re-issue the query with CD set and a EDNS option
> indicating which upstream servers have been tried.  This option is
> initially empty.  The cache will then behave as a proxy for this query
> (excluding the EDNS option) adding the responding server's address to
> the EDNS option.  If there are no more addresses to try, SERVFAIL (new
> rcode?) is returned along with the EDNS option from the query.

objection. this assumes that the reason for servfail is upstream (which
it may not be), assumes that the upstream server identities are
unambiguous from the client's point of view (which in the case of nat
may not be true), and assumes that the client knows better than the
server how to avoid failure.  since your proposal assumes new protocol
elements to be implemented in all servers and some clients, i think it
would be better to add something that solves the actual problem.  the
server in this case should consider using michael graff's hybrid blast
protocol, send the query to the first upstream, and if it fails then
resend it to all upstreams in parallel.  this would get the upstream
transaction timeout down into the downstream client's timeout window.

the wire change i would like is wholly different.  since clients should
not need to add caches when they add validation, i'd like the chain of
rrsig and dnskey to be sent from the recursive server to the stub,
everything it takes to validate the answer.  to do this, a new EDNS
option would allow the client to express its closest trust point.  so if
the client already knows (in a current-transaction cache that is not
shared with other applications or transactions on the client host) it
has a valid dnskey for google.com and it's asking for www.google.com
then the only RRSIGs or DS/DNSKEY's it needs are for www.google.com
and www.l.google.com.

> to the authoritative server.

again, if we're going to change the servers by adding support for some
new wire element, let's just make the server do the right kind of failure
avoidance.  and if we're going to add a new wire element let's have it be
one that lets cacheless stub validation work.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Paul Vixie <[email-masked]>
Date: Wed, 30 Mar 2011 07:05:33 +0000

> Date: Wed, 30 Mar 2011 07:42:32 +0000
> From: Alex Bligh <[email-masked]>
> ...
> DNSSEC validation to the upstream server here isn't it? ...

i loved it when dan kaminsky said, i'm not going to trust the starbucks
resolver to introduce me to my bank.  so, to the above, no.  a validating
resolver has a trust anchor (probably the root key and RFC5011 support)
and is going to be setting CD and doing its own crypto.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Mar 2011 18:11:05 +1100

> got records that don't validate.

You can have different clocks and different sets of trust anchors.

The upstream could be treating a zone as insecure but you have a
trust anchor.  The upstream won't filter stale responses for you
so it won't cope with a authoritative server with stale data and a
number of other operational errors that you can work around with
direct access to the authoritative servers.

Mark

---

From: Michael Richardson <[email-masked]>
Date: Wed, 30 Mar 2011 07:34:20 +0000 (UTC)

> then the only RRSIGs or DS/DNSKEY's it needs are for www.google.com

I'd like to see this too.
A place where I think this is super useful with is lldns/bonjour, for the 
adhoc disconnected case.  I claim to be bob.exaqmple.com on the wire, and 
when I do that I include the chain of rrsig/dnskey from . (or whatever anchor 
point you say you already have).

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Mar 2011 19:10:29 +1100

> and is going to be setting CD and doing its own crypto.

DO=1 is ALL you require to do your own authentication 99.99999999%
of the time.

CD=1 is ONLY needed when the upsteam is doing DNSSEC and its concept
of the current time and/or its set of trust anchors differ to yours.

CD=1 doesn't help you when the upstream is treating the zone the
answer comes from as insecure.

CD=0 DOES NOT mean you are not authenticating.

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.

A validating resolver behind a cache does not have this recovery
path.  The EDNS option is designed to give it that recovery path.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 30 Mar 2011 09:34:36 +0000

> direct access to the authoritative servers.

Hmmm. I think I understand.

And none of these errors that you can work around with "direct"
access to the authoritative servers are ones that
will end up in the BAD cache? As you'll still see these I think.
RFC4035 s3.2.2
>    If the CD bit is set,
>    the name server side SHOULD return the data from the BAD cache;

Isn't the real answer here just to be a full recursive resolver
and *really* access the authoritative nameservers directly?

I take it you are suggesting that the reissued query should always
have DO set as well as CD.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Mar 2011 19:46:00 +1100

> and *really* access the authoritative nameservers directly?

There are plenty of sites that only allow the recursive server talk
to the world.  As much as I would like to say "go direct to the
source" it is not practical.

As for the "bad cache" the only reason for that is we provided bad
advice of "set the CD if you intend to validate".  CD really needs
to be set less often.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 30 Mar 2011 08:57:02 +0000

> Date: Wed, 30 Mar 2011 19:10:29 +1100
> 

as long as you're planning to ignore the AD bit, sure.  but i still think
that we should be able to ask the recursive validator for a longer chain
since the transaction-level cache will otherwise have to be built up over
many round trips.

> CD=0 DOES NOT mean you are not authenticating.

so noted.

> can work around a number of operational errors by being able to retry
> the query with different servers.

i'd like to consider the validating nonrecursive noncaching case first,
since that's the closest analogue to how dns works today.  if i'm in a
hotel room or coffee shop behind NAT and/or firewall and the only UDP/53
destination i can reach is the isp's recursive caching dnssec-aware name
server then i'd like to be able to get everything i need for trustworthiness
of an answer (www.yourbankhere.com IN AAAA) in a single round trip.

> path.  The EDNS option is designed to give it that recovery path.

i think that any state held in the validating nonrecursive noncaching
initiator that has to do with the authority servers would be a mistake.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Tony Finch <[email-masked]>
Date: Wed, 30 Mar 2011 12:19:18 +0100

> retry the query with different servers.

Is this the kind of thing you'd implement in an every-day stub resolver or
is it just for dig jockeys?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Biscay: Southwest 5 or 6. Moderate or rough, occasionally very rough later in
north. Occasional rain. Moderate or good.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Mar 2011 22:39:27 +1100

In message <[email-masked]>, Tony Fi
> is it just for dig jockeys?

Every day validating stub resolver.  Dig is a diagnotic tool and
would only implement this if it was explicitly told to.  You want
dig to see the errors.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Mar 2011 22:54:46 +1100

In message <[email-masked]>, Paul Vixie writes:
> as long as you're planning to ignore the AD bit, sure.

And in the general case you do ignore the AD bit.  If you are trusting the
AD but you don't need to set DO, AD=1 in the query is enough assuming the
server understands AD=1 which you should know if you are going to trust AD.

> but i still think

Which is orthogal to this issue.
 
> of an answer (www.yourbankhere.com IN AAAA) in a single round trip.

Which is a seperate issue.

> initiator that has to do with the authority servers would be a mistake.

The state is not held anywhere.  It's passed back and forward.

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 30 Mar 2011 14:01:04 +0200

> then the only RRSIGs or DS/DNSKEY's it needs are for www.google.com

Note that this makes the assumption that that is actually the trust
point that has a validatable chain, and not a failing one while there is
a higher trust point that would lead to succesful validation (yes yes,
this may or may not be good or bad or local policy or whatever, cue
discussion for multiple chains where some fail).

> one that lets cacheless stub validation work.

i would also like to see something like this, btw.

Jelte

---

From: "Marc Lampo" <[email-masked]>
Date: Wed, 30 Mar 2011 15:12:16 +0200 (CEST)

>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).
Only then one can implement security on DNS traffic flows.
Otherwise the firewall rule is : "any(internal)" to "any(external)" for
port 53 : allow
Which I'd disrecommend ... sorry.

Marc Lampo

---

From: Mark Andrews <[email-masked]>
Date: Thu, 31 Mar 2011 00:47:55 +1100

In message <005301cbeedc$e9653150$bc2f93f0$@[email-masked]>, "Marc Lampo" write
> Which I'd disrecommend ... sorry.
 
Please go re-read the proposal.  You have not understood it.

Mark

---

From: Edward Lewis <[email-masked]>
Date: Wed, 30 Mar 2011 09:53:01 -0400

For those only reading the mail list (i.e., not attending the 
in-person meeting), can you give some context to this?  I suspect 
this is a follow on to a meeting discussion.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 30 Mar 2011 07:37:52 -0700

> 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.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Thu, 31 Mar 2011 02:22:41 +1100

In message <[email-masked]>, Nicholas W
eaver writes:
> >=20
> >>=20
> >=20
> > =46rom the security point of view, letting "resolvers" (on end-user =
> PC's)
> 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.
> 
> 
> 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 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:
> 
> 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.=

---

From: "Marc Lampo" <[email-masked]>
Date: Wed, 30 Mar 2011 17:23:19 +0200 (CEST)

-----Original Message-----
From: Mark Andrews [mailto:[email-masked]] 
Sent: 30 March 2011 05:23 PM
To: Nicholas Weaver
Cc: Marc Lampo; 'Tony Finch'; [email-masked]
Subject: Re: [dnsext] caches, validating resolvers, CD and DO

...

> Failures are not alway malicious.

Most (if not : all) (DNSSEC validation) failures I have seen myself, up
till now,
were indeed *not* malicious.
They were because of failing management on the authoritative NS side ...

This being said :
contacting them directly would simply yield the same validation error.

Marc

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 30 Mar 2011 11:18:13 -0700

> And w/ dnssec you detect this.

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

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

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

---

From: Derek Atkins <[email-masked]>
Date: Thu, 31 Mar 2011 09:56:43 -0400

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

I disagree.  I run a local network in my house and run local caching
recursive resolvers.  I have all my hosts on my network resolve through
my local caches.  I run all my machines, therefore I trust my cache.  I
see no reason to *require* all my machines to bypass the local cache.
Moreover, in my case I see no reason to require all my machines to
perform local validation.  I trust myself.

Therefore, calling it a MUST is wrong.

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

I agree in principle, however that policy can also be "trust the caching
recursive resolver."  Saying that the client MUST validate does not
allow for this trusting policy.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 31 Mar 2011 07:27:42 -0700

> allow for this trusting policy.

Good point, however, the default policy should still be a must, since your configuration is rather unusual:  DNSSEC enables DNS to not trust the recursive resolver, and the default policy should take advantage of this.

Defaults should provide maximum safety and maximum interoperability for the majority of the clients.