Subject: [DNSOP] Definition of "validating resolver"

From: Paul Hoffman <[email-masked]>
Date: Sun, 8 Mar 2015 12:21:49 -0700

Greetings again. Paul Wouters noticed an inconsistency in the terminology draft, and upon investigation, I believe it is a problem (hopefully fixable) with the definitions in RFC 4033. RFC 4033 and 4035 use the term "validating resolver" in a few places. However, RFC 4033 never defines that. RFC 4033 *does* define "security-aware resolver":

   Security-Aware Resolver: An entity acting in the role of a resolver
      (defined in section 2.4 of [RFC1034]) that understands the DNS
      security extensions defined in this document set.  In particular,
      a security-aware resolver is an entity that sends DNS queries,
      receives DNS responses, supports the EDNS0 ([RFC2671]) message
      size extension and the DO bit ([RFC3225]), and is capable of using
      the RR types and message header bits defined in this document set
      to provide DNSSEC services.

My personal interpretation is that "validating resolver" is a synonym for "security-aware resolver". Do others agree? If not, how would you differentiate them?

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Sun, 8 Mar 2015 15:51:49 -0400 (EDT)

> My personal interpretation is that "validating resolver" is a synonym for "security-aware resolver". Do others agree? If not, how would you differentiate them?

I agree :)

Two other issues I noticed when trying to rewrite my draft to stick to
terms in this document is:

"DNS Forwarder" is the only term prefixes with "DNS". I'd wish we could
just use "Forwarder".

I see no term for "Recursive Server" - there is one for Authoritative
Server. And the term "Resolver" oddly means something else (which after
reading it in the DNS Terminology draft, just makes me weep.

Paul

---

From: Ralf Weber <[email-masked]>
Date: Sun, 8 Mar 2015 15:31:57 -0700

Moin!

On Sun, Mar 08, 2015 at 12:21:49PM -0700, Paul Hoffman wrote:
> Greetings again. Paul Wouters noticed an inconsistency in the terminology
> draft, and upon investigation, I believe it is a problem (hopefully
> fixable) with the definitions in RFC 4033.  RFC 4033 and 4035 use the term
> "validating resolver" in a few places.  However, RFC 4033 never defines
> that.  RFC 4033 *does* define "security-aware resolver":
> 
> My personal interpretation is that "validating resolver" is a synonym for
> "security-aware resolver".  Do others agree?  If not, how would you
> differentiate them?
I was told that the difference is that a security aware resolver does
not validate, but instead relies on the "Validating Stub Resolver" to 
protect the user. So it would handle all the DNSSEC processing to the
authoritative and would store the records with signatures in the cache,
but it wouldn't check if they are valid. 

The people who told me that interpreation of the RFC never did deploy DNSSEC
and thankfully most of the people who did and deployed DNSSEC used
validating and security aware resolvers. I don't think it makes sense to
deploy a caching resolver without validation.  So would be ok if we define
it as you suggest.

So long
-Ralf

---

From: Tony Finch <[email-masked]>
Date: Mon, 9 Mar 2015 10:45:14 +0000

Paul Hoffman <[email-masked]> wrote:
>
> My personal interpretation is that "validating resolver" is a synonym
> for "security-aware resolver". Do others agree? If not, how would you
> differentiate them?

No, "security-aware" means that the doftware understands the special
semantics of RRSIG, NSEC, DS, etc. but does not necessarily validate. It
is clear from RFC 4033 that validation is separate from security awareness
because of "Non-Validating Security-Aware Stub Resolver".

For instance, by default, BIND is a security-aware validating resolver.
(Except it can't validate anything until you configure a trust anchor.)
You can turn off validation with "dnssec-validation no" and switch it into
security-oblivious mode with "dnssec-enable no".

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Faeroes: Southwest 5 or 6, becoming cyclonic then northwest later, 7 to severe
gale 9, perhaps storm 10 later. Very rough or high. Occasional rain. Moderate,
occasionally poor.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Mar 2015 09:11:12 -0400

> but it wouldn't check if they are valid. 

Doesn't this create an opportunity for a DoS attack based on poisoning the cache with a record that won't validate?   So I am in violent agreement with your conclusion. :)

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 9 Mar 2015 06:59:14 -0700

Thanks, but I'm having a hard time grokking this. It seems other on the list are as well.

On Mar 9, 2015, at 3:45 AM, Tony Finch <[email-masked]> wrote:
> semantics of RRSIG, NSEC, DS, etc. but does not necessarily validate.

What does "understand" mean in that sentence?

> It

Maybe. Note that this is the only defined term with "non-validating" in it. Was this possibly an artifact of the world-view that Ralf mentioned?

> security-oblivious mode with "dnssec-enable no".

If you turn off validation with "dnssec-validation no", in what way is it security-aware any more?

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Mon, 9 Mar 2015 14:29:32 +0000

> What does "understand" mean in that sentence?

The software has to implement the parts of DNSSEC which are incompatible
with security-oblivious DNS.

RRSIG records are part of the RRset they sign, not a separate RRset of
their own.

Proof of nonexistence requires returning NSEC(3) records in responses.

DS records have to be queried at the parent not the zone apex.

etc.

> > It is clear from RFC 4033 that validation is separate from security
> > awareness because of "Non-Validating Security-Aware Stub Resolver".
>
> Maybe. Note that this is the only defined term with "non-validating" in
> it. Was this possibly an artifact of the world-view that Ralf mentioned?

Maybe. I agree with most of what Ralf said. However while we may not think
it makes sense to deploy a non-validating resolver, a large proportion of
the resolvers out there are non-validating and security-aware.

> it security-aware any more?

It matters wrt the protocol support that is provided to downstream
clients.

All upstream servers of a validator have to be security-aware or the
validator will not work. So if I turn off validation on my recursive
server and flush its cache, I can still use a validating stub. The stub
will make DO=1 queries so the server will return the RRSIG and NSEC
records that the stub needs to be able to validate. If I turn off DNSSEC
support in my recursive server, my stub can no longer validate the
responses because the necessary information is not returned.

Obviously a non-validating recursive server isn't a good setup from the
DNSSEC point of view, but there is an important distinction between
working (security-aware but vulnerable to cache poisoning) and completely
broken (because security-oblivious).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Tyne, Dogger, Fisher, German Bight, Humber: South veering west 5 to 7,
occasionally gale 8, except in Humber. Moderate or rough, becoming very rough
in Fisher. Rain for a time. Moderate or good.

---

From: Willem Toorop <[email-masked]>
Date: Mon, 09 Mar 2015 15:45:53 +0100

I'd like to maintain the term exactly as specified in RFC4033
(understanding DNSSEC but not validating), because it comes in use when
talking about validating stubs.

Some network operators don't know or care about DNSSEC and do not equip
their network's resolver with a trust anchor.  Such a resolver is
obviously not validating, but if it is a modern resolver it is very
likely to be security-aware.

An application using a validating stub can leverage such a resolver to
get DNSSEC answers from the cache which it can then validate itself.
For example to get an authenticated TLSA and bootstrap an encrypted channel.

I have presented measurements on the amount of security-aware resolvers
in RIPE ATLAS in the context of this use case at ICANN50:

https://london50.icann.org/en/schedule/wed-dnssec/presentation-dnssec-validation-deployment-25jun14-en.pdf

Though in the research we called those DNSSEC-aware instead of
security-aware.

-- Willem

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Mar 2015 11:13:39 +1100

> For example to get an authenticated TLSA and bootstrap an encrypted channel.

Which works most of the time as there are very few attacks and the
resolvers do a pretty good job of dealing with the broken authoritative
servers and poorly configured firewalls that block legitimate
replies.  If you want reliable DNSSEC then these resolvers also
need to validate.

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

---

From: Florian Weimer <[email-masked]>
Date: Thu, 12 Mar 2015 17:20:24 +0100

* Ted Lemon:

> Doesn't this create an opportunity for a DoS attack based on
> poisoning the cache with a record that won't validate?

Yes, but that's inherent to DNSSEC and not specific to this
configuration.  For instance, you might cache bad glue records, which
also prevents using DNSSEC to see that they are bad.