Subject: validating a qtype=* response

From: David Blacka <[email-masked]>
Date: Thu, 19 May 2005 14:55:54 -0400

It occurred to me that is isn't totally obvious how a DNSSEC validator 
should validate a (non rcode=3) response to a qtype=* (or qtype=ANY, if 
you will) query.

I can think of 2 approaches:

1. Verify any answer section rrsets (that match qname+qclass, that is). 
     If there are no answer section rrsets, validate via a authority 
section NSEC that qname is, in fact, an empty-non-terminal.  Validate 
the authority section as normal.

2. Don't validate it at all, don't set the AD bit.

Opinions?  #1 makes the most sense to me, but I see an appeal in #2 
(less work, what is the qtype=* query used for anyway?).

Does this need additional clarification?  I'm thinking that this sort of 
thing might go into Sam's bis-updates document, but it could've been 
obvious to everyone else.

-- 
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Thu, 19 May 2005 16:01:53 -0400

I'm going to top-post this since it's a general opinion.

 From what I see, the AD bit is set when the sender thinks all data in 
the Answer and Authority sections are authentic.  I didn't see any 
mention of relevant.  I also didn't see any mention of "complete."

On the receiver side, the AD bit is only of value if the channel 
between the receiver and the sender is secure - TSIG'd, IPSEC'd, 
guns&dogs around the facility.  The protocol elements can't "know" if 
the channel is secure though, so you can't programatically code that 
assumption in.

IMHO, if a record set is not germane to the query, then the response 
message is suspect.  For all queries other than qtype=* you can tell 
if the response message is complete (with DNSSEC).

You might think that, with the NSEC record you can tell - but no, not 
really.  The qtype=* isn't qtype=ALL, it's qtype=ANY.  If you ask a 
"cache" there is no requirement it go find the other records. 
(Especially if it doesn't offer to do  recursion for you.)  IOW, if 
the cache excludes a certain RRSet listed in the NSEC record (or even 
the NSEC), the cache might not be lying.

I would take option #1 - but I don't get the empty non-terminal bit. 
There's no law stating that a query can't be made for an empty 
non-terminal's "any" records.  Is it possible that a non-empty 
non-terminal's descendent may have been the object of a previous 
query and so the cache may have "constructed" a tree including the 
now queried-for-name?  (Maybe a dumb question.)

At 14:55 -0400 5/19/05, David Blacka wrote:
>It occurred to me that is isn't totally obvious how a DNSSEC validator should
>validate a (non rcode=3) response to a qtype=* (or qtype=ANY, if you will)
>query.
>
>1. Verify any answer section rrsets (that match qname+qclass, that is).     If
>there are no answer section rrsets, validate via a authority section NSEC that
>qname is, in fact, an empty-non-terminal.  Validate the authority section as
>normal.
>
>Opinions?  #1 makes the most sense to me, but I see an appeal in #2 (less
>work, what is the qtype=* query used for anyway?).
>
>thing might go into Sam's bis-updates document, but it could've been obvious
>to everyone else.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

---

From: David Blacka <[email-masked]>
Date: Thu, 19 May 2005 16:39:07 -0400

Edward Lewis wrote:

> non-terminal's "any" records.  

My thinking was that if a NODATA response comes back from a qtype=* 
query, then either qname is a ENT or the server should have recursed 
(and found rrsets), but this could be wrong.  Does qtype=* imply no 
recursion?

Should a NODATA response also be accepted as valid, then?

---

From: Edward Lewis <[email-masked]>
Date: Thu, 19 May 2005 17:06:20 -0400

At 16:39 -0400 5/19/05, David Blacka wrote:
>Edward Lewis wrote:
>
>>  I would take option #1 - but I don't get the empty non-terminal bit. There's
>>no law stating that a query can't be made for an empty non-terminal's "any"
>>records.
>
>My thinking was that if a NODATA response comes back from a qtype=* query,
>then either qname is a ENT or the server should have recursed (and found
>rrsets), but this could be wrong.  Does qtype=* imply no recursion?

Answering the last question - no.   What I was referring to can be seen by:

     dig chia.arin.net any @f.gtld-servers.net

I offer this a cache that isn't willing to go look for you, but is 
happy to tell you what it already knows.  You'll see the A record for 
chia.arin.net in the answer, but not the AAAA it owns.

>Should a NODATA response also be accepted as valid, then?

Let's say this is in the zone (meaning, if I asked an auth server):

$ORIGIN example.

...

label-a          A  127.0.0.1
label-a        TXT  "A non-empty non-terminal"
label1.label-a   A  127.0.0.1
label2.label-a   A  127.0.0.1

-----end of the zone data

Assume there's a caching/recursive server I am using and issue these 
queries against it (right after start up):

dig label1.label-a  A
dig label2.label-a  A
dig label-a ANY

...I would expect that either the cache recurses as it hasn't seen 
data for label-a before OR the cache returns NODATA as it knows the 
name exists but has no data for it.

The latter option might be the only one for unwilling-to-recurse caches.

dig label-a A

...I would expect recursion to kick in, getting the A and returning it

dig label-a ANY

...returns the cached A record.  (Assuming TTL is long enough.)

dig label-a TXT

...gets and returns the TXT record

dig label-a ANY

...returns the cached TXT and A record.

---

From: Matt Larson <[email-masked]>
Date: Fri, 20 May 2005 08:52:31 -0400

(Taking us off topic for this thread...),

On Thu, 19 May 2005, Edward Lewis wrote:
> >Does qtype=* imply no recursion?
> 

The situation you describe regarding a cache's behavior is valid, but
that isn't what's happening here: f.gtld-servers.net is an
authoritative-only name server with no iterative resolver component
and therefore no cache.  The A record for chia.arin.net is present
because it's glue (for the arin.net zone and perhaps others).  ARIN
could register an AAAA record for chia.arin.net as glue through its
registrar and then that record would be returned, too.

Matt
--
Matt Larson <[email-masked]>
VeriSign Naming and Directory Services

---

From: Edward Lewis <[email-masked]>
Date: Fri, 20 May 2005 10:10:02 -0400

>registrar and then that record would be returned, too.

Exactly.  I'm using it as an example of a cache not fetching (and not 
required to fetch) the other data sets because of a qtype=* query. 
I.e., the fact that the AAAA record is "omitted" is not a security 
issue, it's an artifact of the protocol.

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 23 May 2005 18:47:57 -0400 (EDT)

I like option #1, also clarifying that NXDOMAIN and NODATA both need
non-existence proofs (1+ NSEC RRs).

> 2. Don't validate it at all, don't set the AD bit.

Given that our current signaling mechanism for validation results (the
AD bit) is so coarse, option #2 worries me.  Can that unvalidated
RRset be cached?  Can a resolver give out the (unvalidated) A record
received in response to qtype=* when answering qtype=A?  Can it use
that (unvalidated) A record when chasing a referral?  This sounds like
it could lead to cache poisoning problems if not handled very
carefully.

-- Sam

---

From: David Blacka <[email-masked]>
Date: Tue, 24 May 2005 09:04:48 -0400

Edward Lewis wrote:
> required to fetch) the other data sets because of a qtype=* query. I.e., 
> the fact that the AAAA record is "omitted" is not a security issue, it's 
> an artifact of the protocol.

Huh?

This isn't an example of a "cache not fetching" anything.  There is no 
cache involved in your example.

I think that it is well understood by this WG that qtype=* won't cause a 
cache to attempt to fetch "all" records of the qtype/qclass.  But what 
is a caching resolver required to do when there are zero records 
matching qname/qclass in its cache?  How does this affect validation?

---

From: David Blacka <[email-masked]>
Date: Tue, 24 May 2005 09:15:14 -0400

> non-existence proofs (1+ NSEC RRs).

I like option #1, too.  But we need to understand the NODATA case, I think.

> it could lead to cache poisoning problems if not handled very

I don't think that this is as worrisome as you think. 1) Caches already 
need to be able to distinguish between validated an unvalidated rrsets 
(think CD=1, think signed rrsets that couldn't be validated due to chain 
of trust).  2) If a validating resolver were to use this unvalidated A 
rrset in a different response, it should attempt to validate that rrset 
then, or choose not to use it in a non CD=1 context.  3) Can it use an 
unvalidated rrset when chasing a referral? I don't see why not.  4) It 
is true that a cache will have to be careful to avoid poison, but it has 
to do that anyway.

That being said, I don't necessarily see any reason NOT to validate that 
qtype=* response, other than I'm not exactly certain how it should be done.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 24 May 2005 16:14:28 +0200

On Tue, 24 May 2005 09:04:48 -0400

>  matching qname/qclass in its cache?  How does this affect validation?

Sending back an NOERROR packet with an empty answer section, _without_
the NSEC to proof it, ad bit set.

Any client that would want to "proof" this answer would need to take
into account that it queried QTYPE="*" and that a completely empty
packet is one of the things that can be returned.

I'd think...

-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
---------------------------------| JID: olaf at jabber.secret-wg.org

---

From: Edward Lewis <[email-masked]>
Date: Tue, 24 May 2005 11:01:32 -0400

At 9:04 -0400 5/24/05, David Blacka wrote:

>is a caching resolver required to do when there are zero records matching
>qname/qclass in its cache?  How does this affect validation?

For the first question - it seems that BIND (as an example DNS 
implementation) will recursively issue the query if recursion is 
available.

For the second question - each individual RRSet in the answer ought 
to be validated of course.  This includes pertinence to the question 
asked - in this case, just the name and type have to be exact 
matches.  There is a dilemma over the setting of the AD bit though.

On the one hand, the AD bit is supposed to indicate the "security" of 
the records in the answer and authority section.  On the other hand, 
DNSSEC promises "data integrity."  The difference is the records that 
might "fall out" of the answer section in a qtype=* answer.

The qtype=* processing never promised data integrity - so I don't 
think it is fair to expect that DNSSEC will promise this now.

So, my expectation would be to set the AD bit if all the present 
RRSets are pertinent (and germane) and pass the 
authentication/integrity checks as if the RRSet was standing alone in 
a request for its type.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: David Blacka <[email-masked]>
Date: Tue, 24 May 2005 15:13:39 -0400

Edward Lewis wrote:
> implementation) will recursively issue the query if recursion is available.
> 
> For the second question - each individual RRSet in the answer ought to 
> be validated of course.  This includes pertinence to the question asked 
> - in this case, just the name and type have to be exact matches.  There 
> is a dilemma over the setting of the AD bit though.
> 
> The qtype=* processing never promised data integrity - so I don't think 
> it is fair to expect that DNSSEC will promise this now.

Agreed.

> So, my expectation would be to set the AD bit if all the present RRSets 
> are pertinent (and germane) and pass the authentication/integrity checks 
> as if the RRSet was standing alone in a request for its type.

Fair enough.  This is the positive response case, and I think that it is 
reasonable.  Let's look at negative responses.

RCODE=3 (Name Error) responses to qtype=* look to be no different from 
the normal case.

NOERROR/NODATA responses to qtype=* are questionable, in my mind.  And 
the central question is this: must a NOERROR/NODATA response to a 
qtype=* query have a validated NSEC in authority section proving that 
qname is an empty non-terminal to be considered valid?

Another way of asking this question is: are (full/caching/recursive) 
resolvers required to recurse on a qtype=* query if no records with 
qname+qclass are present in the cache (even if a child of qname *is* 
present in the cache)?

---

From: Mark Andrews <[email-masked]>
Date: Wed, 25 May 2005 05:42:44 +1000

> qname is an empty non-terminal to be considered valid?

	This is the correct response to a empty non-terminal.  One
	can cache this response and validate this response.
 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 24 May 2005 16:37:14 -0400

Apologies in advance for this being somewhat disoriented...

At 15:13 -0400 5/24/05, David Blacka wrote:
...
>Let's look at negative responses.
...
>qname+qclass are present in the cache (even if a child of qname *is*

You'll never get a NOERROR/NODATA response for qtype=* queries of 
leaf nodes.  So this boils down to cases of non-terminals.

Since we are talking about resolvers (as in RFC 1034 5.3's definition 
here), the scripture we want is in section 5.3.3, beginning with:

#   1. See if the answer is in local information, and if so return
#      it to the client.
#
#   2. Find the best servers to ask.

For step 1, here's a head-scratcher.  Is the existence of a 
non-terminal name inferred by the presence of data for any of its 
descendents?

An answer is in local information if it has been asked for before 
(within the TTL).  Local information could be positive answers or the 
negative cache.

If the non-terminal is inferred (the head scratching question), then 
NOERROR/NODATA is appropriate, but this can't be supported with any 
records from the cache.  For this reason I don't think "inferred 
names" ought to be in the cache.  Answering about things you don't 
know about is like synthesizing wild cards in the cache.

If the non-terminal is empty, then if it is "in local information" it 
will be in the negative cache.  (I.e., someone asked for it, and got 
no answer records.)  A query of qtype=* will return NOERROR/NODATA 
with the negative cache "proof."

If the non-terminal has data (at least as it is present in the 
cache), then there won't be a NOERROR/NODATA return.

In other cases, the non-terminal is not known and you resume with step 2.

So - in summary, what I am saying is that you should only return 
NOERROR/NODATA for a qtype=* when the name is a previously sought 
empty non-terminal, in the negative cache.  The existence of names 
ought never be inferred by a cache, if a name is not explicitly in 
local information, and recursion is permitted, the server ought to 
recurse.