Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 02 Jun 2004 14:50:46 +0200

>1.  Caches generating negative responses using NSEC RRs recieved from
>unrelated queries.
>
>  
>
(...)

>I think the 1 is also a problem, but maybe not serious.  There could be
>cases where a resolver could get 2 different answers from 2 different
>security aware caches if one used old NSEC RRs, and one got the
>authoritative data from a zone that was updated.  It is up to the WG to
>decide if we should say that caching resolvers MUST NOT generate negative
>responses from cached NSEC RRs or not.
>
>  
>
I think that there are two issues under 1. The use of NSECs to generate 
NXDOMAIN responses for other queries for other names (and classes) than 
the  QNAME, QCLASS for which the NXEC was stored; the use of NSECs to 
generate NOERROR no-answer responses for qeueries  with only a different 
type than the QNAME, QCLASS, QTYPE for which the NSEC was stored.

The first use is _bad_. That is because NSEC RRs may be automagically 
generated and signed.You would not want to see that NSEC to be used to 
proof the non existence of other RRs. 

Here is an example of a (silly) DNS application to proof why an NSEC 
should not be used to proof the non-existence of other domain names.

ns.rp.secret-wg.org is a "secured reverse polish DNS calculator"  you 
can perform calculations by puting your 'stack' into a set of labels and 
query under the rp.secret-wg.org domain. The answer is provided in a TXT 
RR. Since there will always be an answer for each possible domain in the 
rp.secret-wg.org domain (or a SERVFAIL in case of stack underflow) and 
the namespace is infinite the NSEC RRs
that are automatically genrated to proof the NOERROR no-answer reply 
always points back to the SOA. (You can use the same trick to prevent 
NSEC walks)

The 2 + 2 query provides an NSEC that should not be used to proof that 3 
+ 2 (3.2.+.rp.secret-wg.org) does not exist.

In this particular case you could use the NSEC to proof the nonexistence 
of other types under 2.2.+.rp.secret-wg.org; The current text in 
protocol allows for that.

; <<>> DiG 9.3.0beta3 <<>> @ns.rp.secret-wg.org 2.2.+.rp.secret-wg.org 
ANY +dnssec

;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42620
;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 2048
;; QUESTION SECTION:
;2.2.+.rp.secret-wg.org.		IN	ANY

;; ANSWER SECTION:
2.2.+.rp.secret-wg.org.	10	IN	TXT	"4"
2.2.+.rp.secret-wg.org.	10	IN	SIG	TXT 1 6 10 20040801123632 20040602123632 27900 rp.secret-wg.org. pwCKCwxRnQ91wvJAxJ4MHEHsxCf0KLWbe66a7znHrzSL2a1Y2wUNeTRq S0VzGpevrQkcS/9XszlM1/+u90THBQ==
2.2.+.rp.secret-wg.org.	10	IN	A	193.0.4.49
2.2.+.rp.secret-wg.org.	10	IN	SIG	A 1 6 10 20040801123632 20040602123632 27900 rp.secret-wg.org. tLOidlVhtOnDkat7DZRr8gmYyoL3xkZCCsNxGYHqU5SvQ07H/FNULcVs X0uwSLKSA/eNewAOzF3tgmSy108dGg==
2.2.+.rp.secret-wg.org.	10	IN	NXT	rp.secret-wg.org. A TXT SIG NXT
2.2.+.rp.secret-wg.org.	10	IN	SIG	NXT 1 6 10 20040801123632 20040602123632 27900 rp.secret-wg.org. vRhdJMjlR2+TyKGZn8AWZgZdgdHh51zS1oBTwQEIxRpyXd6I3adnPXOY zlbbeNctj8zefFjy8P148Lgz5NAhNQ==

;; Query time: 209 msec
;; SERVER: 193.0.3.29#53(ns.rp.secret-wg.org)
;; WHEN: Wed Jun  2 14:36:36 2004
;; MSG SIZE  rcvd: 435

--
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: Ben Laurie <[email-masked]>
Date: Wed, 02 Jun 2004 14:11:53 +0100

Scott Rose wrote:

> Thinking about this some more, I think we can break things down into
> smaller, semi-related chunks.  Some might be problems, some might be serious
> problems (I've come to recognize the difference :)
> 
> 2.  Caches synthesizing positive wildcard responses from cached wildcard
> RRs.
> 
> I think we agree that 2 is a bad thing, so there should be rule against
> caches doing that.  I don't want to put words in your mouth though, so
> correct me if I'm wrong.  Security aware caching name servers MUST NOT use
> cached wildcard RRs to synthesis postive wildcard matches to queries.
> 
> Of course, I'm not sure how NSEC2 changes things just yet, but case 2 would
> still hold - wildcards aren't affected here.

NSEC2 would have exactly the same issue (or non-issue, as the case may be).

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: David Blacka <[email-masked]>
Date: Wed, 2 Jun 2004 10:40:40 -0400

> should not be used to proof the non-existence of other domain names.

What you are saying (I think) is that, if caches synthesize NXDOMAIN 
responses, then the cache will prevent the user from seeing rapid changes to 
a zone, against the zone publisher's wishes.  Couldn't the zone publisher 
just put 0 TTLs on the NSEC records in that case?

I dimly remember that we determined something more "serious" would result if 
caches synthesize negative answers, but I cannot remember (if I ever knew) 
what it was.  It was something that fell out of the Opt-In discussion, 
however.  I am hoping that we can re-discover it.

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

---

From: David Blacka <[email-masked]>
Date: Wed, 2 Jun 2004 10:32:09 -0400

On Wednesday 02 June 2004 8:13 am, Scott Rose wrote:
> smaller, semi-related chunks.  Some might be problems, some might be
> serious problems (I've come to recognize the difference :)
>

OK, but WHY is this a bad thing?  I would agree that if I were writing a 
resolver, I would not want to be *expected* to synthesis from detected 
wildcards, but if I did, what would be the harm?

I can only think of two things here: 1) if caches synthesized wildcard 
responses, it would stop cold any wildcard "tricks", and 2) it changes some 
fundmental principles of DNS, which might have some un-though-of 
consequences.

> responses from cached NSEC RRs or not.

How is this different from normal negative caching?  If the zone changes 
between two queries, a negative cache entry might block a client from seeing 
the change for a while.  Of course, synthesizing negative answers from NSEC 
records would make this effect much, much more common.

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 2 Jun 2004 16:58:13 +0200

> a zone, against the zone publisher's wishes.

Almost, if the caches synthesize NXDOMAIN responses based on NSECs in 
their cache that do not relate to the current query they will get it 
wrong.

> Couldn't the zone publisher

That would be an operational hack to prevent caches doing something 
they MUST NOT do. (That something being making up answers for questions 
they never asked, since that will in some cases break end-to-end 
consistency).

> however.  I am hoping that we can re-discover it.
Rob and/or Roy presented something at an IETF (San Diego, Salt Lake, 
Yokohama???, I do recall but I cannot find record of that presentation 
either in the minutes or the list archives).

---

From: [email-masked]
Date: Wed, 2 Jun 2004 17:16:07 +0200 (CEST)

> wildcards, but if I did, what would be the harm?

One of the cornercases that Rob and I were dealing with during the opt-in
debate, is the following, say you have:

A   NSEC   H
H   NSEC   K

A caching resolver caches:

A   NSEC   H

A new record F is added, an old record H is removed from the zone. which
now reads

A   NSEC   F
F   NSEC   K

additionally caching resolver caches

F   NSEC   K

Now the cache reads:

A   NSEC   H
F   NSEC   K

and has conflicting NSEC

The first denies F exists.
The second denies H exists.

Say resolver makes 'efficient' use of cached NSEC records, which one
should be returned for a query for F, for G, and for H.

Roy

---

From: David Blacka <[email-masked]>
Date: Wed, 2 Jun 2004 11:20:29 -0400

> their cache that do not relate to the current query they will get it

Well, "wrong" in the sense of your silly RPN example.  I see this as similar 
to what happens if caches synthesizes wildcards: synthesizing negative 
answers from NSEC records stops NSEC games cold.

> they never asked, since that will in some cases break end-to-end

This is circular.  What I'm trying to discover is WHY caches MUST NOT do this.  
If the only reason for not allowing caches to synthesize negative responses 
is to allow zone publishers to play NSEC games (which could be considered an 
operational hack itself), wouldn't 0 TTLs on the NSEC records suffice?

> either in the minutes or the list archives).

Salt Lake, I believe.  I couldn't find a record of it either, other than in my 
fuzzy memory.

---

From: David Blacka <[email-masked]>
Date: Wed, 2 Jun 2004 11:30:36 -0400

> should be returned for a query for F, for G, and for H.

Wouldn't the resolver return F for the query for F, return either NSEC for the 
query for G, and return H if H is in the cache, otherwise return F NSEC K?  
Or, if the cache notices conflicting NSEC records, it might choose to ignore 
both of them and forward the query?

I'll admit the logic for the H case might really suck to implement, but I am 
still having a hard time understanding the case for MUST NOT.

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 2 Jun 2004 11:14:35 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of David Blacka

> fundmental principles of DNS, which might have some un-though-of

Basically yes - a caching resolver should not be allowed to synthesize
wildcard responses (which would be authoritative data) since they might be
incorrect.  DNSSEC allows this to happen (that is, a caching server can
determine if a record is really a wildcard, which it couldn't do before).

By not allowing wildcard synthesis by caching middle boxes, DNSSECbis keeps
wildcard synthesis at the authoritative server.

Scott

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Wed, 02 Jun 2004 12:06:33 -0400

>should be returned for a query for F, for G, and for H.

DNS is a loose consistency DB situations like this are legal, and
expected for a short time (TTL of the Records).
But in most cases the cache does the right think, as lookup in
cache will discover it exists.

IHMO it is would be acceptable for the cache to do any of the following:
         1. QNAME: B use A NSEC H
         2. QNAME: G use F NSEC K
         3. QNAME: H use cached record for H
         4. QNAME: H use F NSEC to deny existence of H
         5. QNAME: F use cached records for F
         6. QNAME: F use A NSEC to deny existence of H
        7. QNAME: B or G or F or H,
                 toss both NSEC records and cached information at F and H.
                 send query to auth server.

But option 7 requires too much work so I do not expect any implementation
do to that.
Remember the BIS documents recommend NSEC TTL be Zone Minimum to
minimize events like these.

         Olafur

         Olafur

---

From: [email-masked]
Date: Wed, 2 Jun 2004 18:34:45 +0200 (CEST)

On Wed, 2 Jun 2004, David Blacka wrote:

> Wouldn't the resolver return F for the query for F,

Why is F more valid than A NSEC H ?

> return either NSEC for the query for G,

Or both, or A or F ?

> and return H if H is in the cache, otherwise return F NSEC K?

The problem is how to define these rules and why is one rule preferred
over the other, etc. Besides this is just one corner case. Another one
would be

A  NSEC  K
F  NSEC  H

(lets not discuss priority rules why one is prefered over the other, or
why/how both can be returned).

Another problem was negative versus positive proof. Positive proof is
cached for TTL seconds, negative proof is cached for SOA minumum field. Is
it okay to construct a negative response from a positive cached NSEC. How
to deal with TTL then ?

Since we concluded at the time that these were meta problems, due to
layering (DNSSEC can be viewed as a layer over DNS), the conclusion was,
in order to stay away from the above cornercase (and not specifying really
weird priority inclusion rules) to cache DNSSEC data (SIG and NSEC) by
qtype/qname/qclass, where the NSEC and SIG where properties of the q-tuple
and not stored as individual RRsets.

> Or, if the cache notices conflicting NSEC records, it might choose to
> ignore both of them and forward the query?
>

Roy

---

From: David Blacka <[email-masked]>
Date: Wed, 2 Jun 2004 12:57:30 -0400

On Wednesday 02 June 2004 12:34 pm, [email-masked] wrote:
> > > One of the cornercases that Rob and I were dealing with during the
> > > opt-in debate, is the following, say you have:
...
> Why is F more valid than A NSEC H ?

Why does that matter?

> why/how both can be returned).

It is true that DNSSEC adds the capability to store contradictory proof 
information.  I think, in reality, it doesn't really matter which record the 
cache uses.

> it okay to construct a negative response from a positive cached NSEC. How

Wouldn't the NSEC record itself have the same minimum TTL?

> and not stored as individual RRsets.

Which I think was overkill.

In my gut, I feel that caches really shouldn't be synthesizing negative 
answers to questions they have never seen, and shouldn't be synthesizing 
wildcards just because they happen to notice one.  But, OTOH, I don't see 
(yet) a justification for "MUST NOT" synthesize.  Maybe the case has been 
made, and I just don't see it yet.

---

From: David Blacka <[email-masked]>
Date: Wed, 2 Jun 2004 12:57:29 -0400

On Wednesday 02 June 2004 12:52 pm, Derek Atkins wrote:
> [email-masked] writes:
> Well, for one thing, SIG(F) will have a newer timestamp than SIG(A
> NSEC H).  

This is a reasonable rule, I think.

> Second, unless A NSEC H was obtained by a query for F, the 
> cache should not associate A NSEC H with F.  I.e., if the cache has A
> NSEC H due to a query for E, it should not carry over that response
> into a query for F.

Why not?  This is what I'm trying to find out.  Why shouldn't the cache carry 
over the A NSEC H from some previous query to the response for F?

---

From: [email-masked]
Date: Wed, 2 Jun 2004 18:59:57 +0200 (CEST)

> Well, for one thing, SIG(F) will have a newer timestamp than SIG(A

As long query happens within the time-delta of both records, both are
valid.

Unless we specify rules on which timestamp is more valid. Here comes
another corner case:

SIG(F NSEC K) 5 - 17
SIG(A NSEC H) 7 - 12

QTIME = 8

Sure, SIG(A NSEC H) has a later inception time, but an earlier expire.
We either need to specify all the corner case rules, where the problem is
that we don't know what we don't know. Or we avoid it. We do know how to
avoid it.

> NSEC H due to a query for E, it should not carry over that response

Exactly. You'd cache the NSEC as a property of the response for query F.
That is what the doc specifies, and David was asking why this was
neccesary (since it is not clear in the docs why that is).

Roy

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 2 Jun 2004 19:22:30 +0200

> operational hack itself), wouldn't 0 TTLs on the NSEC records suffice?

I think that it is just plain wrong for the caching nameserver to make 
up answers by itself even though it might think it knows what to do 
based on an NSEC available from a previous query. This 'plain wrong' 
translates to MUST NOT.

If I understand you correctly you argue that my reasoning mostly buys 
us a "SHOULD NOT" ?

--Olaf

---

From: David Blacka <[email-masked]>
Date: Wed, 2 Jun 2004 14:22:12 -0400

> If I understand you correctly you argue that my reasoning mostly buys

Yes, although I too would like it to be a MUST NOT.

It occurs to me that, unlike most of the MUSTs and MUST NOTs in the DNSSECbis 
documents, this could not be enforced (the others are generally "enforced" by 
the responses not validating).

---

From: Rob Austein <[email-masked]>
Date: Wed, 02 Jun 2004 15:03:47 -0400

> > > I dimly remember that we determined something more "serious"
> > > would result if caches synthesize negative answers, but I cannot
> > > remember (if I ever knew) what it was.  It was something that
> > > fell out of the Opt-In discussion, however.  I am hoping that we
> > > can re-discover it.
> >

Yokohama, I think, but might have been Salt Lake, it's been a while.
In any case: there was a general issue and a specific issue.

I can try to dig out my notes from that era, but IIRC, the specific
issue was some bad interaction that would result from use the NXT from
a cached positive query to generate a later negative response without
going back to the authoritative name server.  At first blush that
problem would appear to be specific to opt-foo, but given that NSEC
RRs sometimes appear in positive responses for wildcard data, it may
still apply.

The more general issue was that Roy and I (Roy, correct me if I'm
getting this wrong) came to the conclusion that the semantics of all
this stuff is complex and fragile enough that a recursive name server
really ought to stay out of the semantics entirely and just pass the
data it got from the authoritative source along to the verifying
resolver without changing anything other than the TTLs.  This is
basicly just another application of the anti-complexity argument.

IIRC, the text to which David is objecting is a recommendation that
came out of the ISI "DS" workshop in September of, um, 2002?  There
was an Editors' Note in the doc next to that text for a long time
asking the WG whether that recommendation should be in the draft at
all, but apparently nobody ever read that note. :)

So, in sum: I happen to agree with the text in question as it stands
now, but would not object to dropping it entirely.

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 2 Jun 2004 21:08:40 +0200

> the responses not validating).

The MUST NOT in this case is intended to preserve a number of 
end-to-end properties of the namespace.  Essentially if your cache 
follows this behavior you can trust it.  If you cannot trust your cache 
to perform this behavior you are in for inconsistencies and 
troubleshooting headache, if you then have a "MUST NOT" to point to you 
may be able to convince your cache supplier he is doing something 
_bad_.

Would you consent with text that explains the reasoning for the  MUST 
NOT create negative responses using NSECs obtained from other queries.  
Allowing  the exeption of using an NSEC that was stored for the same 
name and class but for another type to proof the nonexistence of a 
given type?

--Olaf

---

From: David Blacka <[email-masked]>
Date: Wed, 2 Jun 2004 15:46:15 -0400

> name and class but for another type to proof the nonexistence of a

I would be happy with either dropping section 4.5 entirely, or with replacing 
it with "MUST NOT create negative responses..." language, or with the same 
language using "SHOULD NOT".

I think that if the new language could contains reasons why, that would be 
much better.

To be clear: I do not think (at all) that caches should be synthesizing 
negative responses or wildcards.  Nor do I think that the caching scheme 
outlined in the current section 4.5 won't work or doesn't present some decent 
advantages to more complex schemes.  I just didn't think that the DNSSECbis 
documents should be in the position of telling implementers how to implement 
their cache so explicitly and without justification.

---

From: David Blacka <[email-masked]>
Date: Wed, 2 Jun 2004 15:57:14 -0400

On Wednesday 02 June 2004 3:03 pm, Rob Austein wrote:
> > Salt Lake, I believe.  I couldn't find a record of it either, other than
> > in my fuzzy memory.
>

What I've been trying to figure out is if we discovered actual breakage.  That 
a user of a cache might have to wait the minimum TTL (or NSEC TTL) in order 
to see a change to a zone is undesirable, but not, IMHO, breakage.  If your 
notes indicate something more serious than this, then the WG should see them.  
If anyone disagrees with my not characterizing this as "breakage", please say 
so.

> basicly just another application of the anti-complexity argument.

I would certainly agree that there are many reasons why a cache SHOULD NOT be 
synthesizing answers, not the least of which is that it is comparatively hard 
to do.

> now, but would not object to dropping it entirely.

I am curious if you disagree with any of the criticisms of the text that I 
posted to start this thread?

---

From: Rob Austein <[email-masked]>
Date: Thu, 03 Jun 2004 00:01:01 -0400

> posted to start this thread?

Universal translator dropped out on "stifles resolver innovation", but
I mostly agree with the rest of your specific criticisms.  I happen to
think that the overall reduction in system complexity if everyone were
to follow this this particular bit of implementation advice makes the
advice worthwhile; YMMV.

Other comments:

1) "Less efficient caching strategy" is a known cost of this approach.
   Well, it was known to me, and I think to Roy, at least.  I would
   have said that I thought it was known to all the folks who were at
   the ISI DS workshop that recommended this approach, but you (David)
   were also there and this appears to have surprised you, so maybe
   this was not as widely understood as I thought.  In any case, if we
   don't just drop this text entirely, we'll need to make it harder to
   miss this point.  Send text. :)

2) SHOULD (as opposed to MUST) was deliberate.

3) Text of the Editors' Note that the WG (apparently) never noticed
   buried in -protocol-01 (March 2003):

      Editors' note: This is implementation advice which came out of
      discussions at various workshops and investigations into possible
      implementation issues with the (as yet unsettled) opt-in proposal.
      All of this advice has been discussed in WG meetings, and as far
      as the editors know these recommendations are not controversial,
      but it is up to the WG to decide whether this sort of
      implementation advice belongs in this document.

   'Nuff said.

---

From: Don Stokes <[email-masked]>
Date: Thu, 03 Jun 2004 17:14:09 +1200

>always points back to the SOA. (You can use the same trick to prevent 

Um, but if I have:

	example.	SOA 	...
			...
	a.example.	NSEC example. ...
	b.example.	NSEC example. ...

what's to stop me forging replies for queries to b.example with
a.example's (signed) NSEC record, thereby "proving" that b.example does
not exist when it does?  

I thought that was the whole point of NSEC chaining.

-- don

---

From: [email-masked]
Date: Thu, 3 Jun 2004 09:49:52 +0200 (CEST)

On Thu, 3 Jun 2004, Rob Austein wrote:

>    Well, it was known to me, and I think to Roy, at least.

Yes. A more efficient caching strategy was in the order of "premature
optimization is the root of all evil" [1]

>    I would have said that I thought it was known to all the folks who
>    were at the ISI DS workshop that recommended this approach, but you
>    (David) were also there and this appears to have surprised you, so
>    maybe this was not as widely understood as I thought.  In any case,
>    if we don't just drop this text entirely, we'll need to make it
>    harder to miss this point.  Send text. :)

Roy

[1] Hoare, Tony. "We should forget about small efficiencies, say about
97% of the time: premature optimization is the root of all evil." Quoted
in Donald E. Knuth, Literate Programming (Stanford, California: Center
for the Study of Language and Information, 1992), 276.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 3 Jun 2004 15:23:27 +0200

> a.example's (signed) NSEC record, thereby "proving" that b.example does

Good point.... (would you really want to proof that 3+2 does not have
an answer :-) )

The same reasoning applies to Roy's example where a zone is
dynamically updated.  An attacker could use NSECs hanging around from
a previous 'version' of the zone in an active attack. 

In the case of an attack it is not the TTL that applies
but the signature validity period of the SIG over the NSEC: as long as
the signature is valid the NSEC can be reused. So even in the
situation where you have fairly short TTLs you will be subject to
attacks using the "old NSECs" since short signature validity lifetimes
are very difficult to do in large dynamic zones. 

Back to this thread, I think the bottom line is that we would like our
caches to be transperant to changes in the authoritative zone. Is this
a suggestion we can all live with (taking the original text and
extending it with an explanation).,

    A security-aware resolver SHOULD cache each response as a single
    atomic entry containing the entire answer, including the named
    RRset and any associated DNSSEC RRs.  The resolver SHOULD discard
    the entire atomic entry when any of the RRs contained in it expire.
    In most cases the appropriate cache index for the atomic entry will
    be the triple <QNAME, QTYPE, QCLASS>, but in cases such as the
    response form described in Section 3.1.3.2 the appropriate cache
    index will be the double <QNAME,QCLASS>.

    The reason for these recommendations is that between the initial
    query and the expiration of the data from the cache the
    authoritative data could have been changed, for instance through
    dynamic updates. 

    There are two situation for which this is relevant. 

    1. By using the RRSIG record it is possible to deduce an answer is
    synthesized from a wildcard. The security aware caching nameserver
    could store this wildcard data and use it to generate responses to
    for queries other than the name for which the answer was first
    received. 

    2. NSEC RRs received to proof the nonexistence of a name could be
    re-usec by the cache to proof the non-existence of any name in the
    name range it spans.

    Although technically a wildcard to generate answers and an NSEC RR
    can be used to proof the nonexistence of names an types during the
    signature validity period, it seems prudent that that caches do not
    block newly appeared data. Caches following this recommendation
    will have a consistent view on the namespace.

I am sure that native speakers can do a better job.

-- Olaf
   (No hats)

PS. I argued for MUST NOT language earlier in this thread. But because
of the attack vector mentioned by Don allows for this "plain wrong
behaviour" I now think SHOULD NOT language is more approriate.

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

---

From: Derek Atkins <[email-masked]>
Date: Wed, 02 Jun 2004 12:52:17 -0400

Well, for one thing, SIG(F) will have a newer timestamp than SIG(A
NSEC H).  Second, unless A NSEC H was obtained by a query for F, the
cache should not associate A NSEC H with F.  I.e., if the cache has A
NSEC H due to a query for E, it should not carry over that response
into a query for F.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: David Blacka <[email-masked]>
Date: Wed, 9 Jun 2004 11:46:01 -0400

> extending it with an explanation).,

I think what we are really trying to do is to not introduce any new, 
surprising cache behavior.  That is, even though DNSSEC permits it, we don't 
want caches to suddenly start negative caching differently (and more 
aggressively) or synthesizing wildcards on its own.

>     will have a consistent view on the namespace.

Adding this text is, IMO, better than doing nothing.  However, it doesn't 
really address my original points, which are, essentially, that caching 
entire answers, while elegant, goes too far.

I still think a better solution here is to explain what caches SHOULD NOT (or 
MUST NOT) do.  If I can, I will try and submit language like this, and the WG 
can decide which it prefers.

---

From: David Blacka <[email-masked]>
Date: Thu, 10 Jun 2004 17:10:24 -0400

On Wednesday 09 June 2004 11:46 am, David Blacka wrote:

> I still think a better solution here is to explain what caches SHOULD NOT
> (or MUST NOT) do.  If I can, I will try and submit language like this, and
> the WG can decide which it prefers.

Here is what I have come up with:

  The use of DNSSEC exposes more information about a zone than was
  previously available to resolvers.  In particular, DNSSEC exposes
  the existence of wildcard records within a zone via RRSIG records,
  and non-existence of names via NSEC records.  To avoid unexpected
  and undesirable side-effects, a security-aware resolver SHOULD NOT
  make special use of this additional information.

  Security-aware resolvers SHOULD NOT use received NSEC records for
  negative caching purposes beyond that specified by [RFC 2308].  For
  example, if a resolver receives an NSEC record as part of a response
  indicating that a given QNAME did not exist, the resolver SHOULD
  only return that NSEC record when queried directly for the NSEC
  record by name (e.g., via QTYPE=NSEC or QTYPE=ANY), or when
  answering a query for the original QNAME, QCLASS, and QTYPE.

  In addition, security-aware resolvers SHOULD NOT attempt to perform
  wildcard synthesis on behalf of a different authoritative server.

What do you folks think?

---

From: "Scott Rose" <[email-masked]>
Date: Fri, 11 Jun 2004 21:52:31 -0400

I can live with this text in place of the current wording in protocol draft
section 4.5.  It is more straight forward.

Scott

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 14 Jun 2004 09:32:22 +0200

>   wildcard synthesis on behalf of a different authoritative server.

I like this.

But we may want to also put language in that loosens up the reuse of
an NSEC RR to proof NODATA (I remember Mark Andrews arguing for this).

Maybe we can add one sentence to make the point that when an NSEC RR
is provided as a proof for (RCODE=NOERROR && empty answer) (NODATA) it
MAY be reused for other queries to proof the nonexistence of types for
the same QNAME, QCLASS as that it was originally received.

--Olaf
  No Hats

---

From: Ben Laurie <[email-masked]>
Date: Mon, 14 Jun 2004 10:46:52 +0100

> the same QNAME, QCLASS as that it was originally received.

Just to be clear: you mean queries with the same QNAME and QCLASS but 
different QTYPE can be satisfied by a cached NODATA response?

A consequence of this for anyone using the NSEC kludge recently 
discussed is that the kludge MUST NOT be used as a response for a domain 
which exists but does not have the requested QTYPE - instead a correct 
NSEC record must be returned.

And a consequence of that is that the NSEC record will need to have a 
faked next domain. Sigh. But at least this is workable, unlike previous 
proposals that have included faked next domains, since the NSEC will 
only be produced in response to a query involving its owner name.

Cheers,

Ben.

---

From: David Blacka <[email-masked]>
Date: Mon, 14 Jun 2004 13:39:47 -0400

> >   wildcard synthesis on behalf of a different authoritative server.

I'm so glad :-)

Do you like the last sentence?  Because I'm not entirely happy with it myself.

My other self-criticism of this text is that there is no concrete "why" 
language.  There is only a very vague "to avoid unexpected and undesirable 
side-effects" nod in that direction.

The reason why I didn't write any "why" text is that I was having a hard time 
coming up with it.  I could use some help in this area.

> an NSEC RR to proof NODATA (I remember Mark Andrews arguing for this).

I did think of this.  I don't remember Mark arguing for this specifically 
(although he may have).  The main argument I remember was for being able to 
apply negatively cached NXDOMAIN responses to all QTYPEs, which is, of 
course, allowed by both this and the previous language.

However, once I decided that the fundamental driving reason for this specified 
behavior was to not add new negative caching behavior, I decided that reusing 
the NSEC for NODATA responses (that is, same QNAME, QCLASS, different QTYPE) 
would constitute new negative caching behavior.  It would mean that new 
RRsets added to an existing name would face negative caching behavior, and 
thus not be not immediately visible to some subset of resolvers.

> the same QNAME, QCLASS as that it was originally received.

If we did that, we would make the first sentence of the 2nd paragraph be, in 
fact, wrong.  Which would mean that the reasoning behind this text is wrong.  
Which is fine, but then the WG would have to come to agreement about what we 
are trying to accomplish with section 4.5.