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

From: "Scott Rose" <[email-masked]>
Date: Wed, 2 Jun 2004 08:13:41 -0400

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 :)

1.  Caches generating negative responses using NSEC RRs recieved from
unrelated queries.
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.

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.

Of course, I'm not sure how NSEC2 changes things just yet, but case 2 would
still hold - wildcards aren't affected here.

Scott

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of David Blacka
> Sent: Tuesday, June 01, 2004 3:42 PM
> To: [email-masked]
> Subject: Re: protocol-06 section 4.5
>
>
> On Tuesday 01 June 2004 1:42 pm, Scott Rose wrote:
> > If memory serves me right...
> >
> > The concern was having over-eager caching servers generate new responses
> > from stored NSEC RRs.  In some cases, the queried name, type
> may have been
> > updated, and the NSEC no longer valid.  For example:
> >
> > query for b.foo.com  get:
> > a.foo.com NSEC c.foo.com CNAME
> >
> > then someone queries for <a.foo.com  IN  A> and gets back the
> same cached
> > NSEC RR (that shows a.foo.com doesn't have an A RR associated
> with it).  In
> > this case it is correct, but in some cases, the NSEC RR for
> a.foo.com may
> > be out of date.  Caching servers also now know a wildcard RR
> when they see
> > it, so they may also be tempted to generate positive wildcard responses
> > from cached RRs.
>
> I have a hard time seeing what you are describing as a serious
> problem.  I'm
> not saying that I believe that there isn't a serious problem
> here, but that I
> don't think that we have described it yet.
>
> Right now (ignoring caches doing wildcard synthesis for the moment), what
> you've described is a cache that is, essentially, doing
> preemptive negative
> caching.  Unless the NSEC record is actually lying to you, the
> only problem I
> see for this is that, after a zone change, downstream clients
> will not see
> the zone change (assuming an RRset was added, not removed) for
> the duration
> of the NSEC TTL.
>
> > It might be able to be re-written as:
> >
> > "caching security aware name serves MUST NOT use cached NSEC RRs to
> > generate negative responses for queries unless those queries matched
> > previous queries.  Also, caching server MUST NOT generate their own
> > positive wildcard matches using previously cached wildcard RRs.
> >
> > That text might be more confusing though.  It would need to be made very
> > clear (more clear than above).
>
> This is sort of language I would like to see for section 4.5.  However, I
> think we need to justify it.
>
> --
> 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/>
>

--
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: "Scott Rose" <[email-masked]>
Date: Wed, 2 Jun 2004 13:27:17 -0400

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

I can agree that it probably won't break things, but it could cause some bad
corner cases (NSEC re-use) and contradicts some long standing DNS principles
(auth servers generate wildcard responses).  But not setting strict
guidelines might lead to a resolver too clever for its own good.

Right now, the text says responses SHOULD be stored as an atomic entry.
Maybe it should be changed to SHOULD NOT generate non-existant
responses/wildcard expansions instead of MUST NOT?

Personally, I like MUST NOT (especially with wildcard expansion) - it keeps
things consistant and reduces some of the complexity that could come from
caches doing wacky things with data.

Scott

> Sr. Engineer    VeriSign Applied Research
>
> --

---

From: "Scott Rose" <[email-masked]>
Date: Mon, 14 Jun 2004 16:04:38 -0400

> On Monday 14 June 2004 3:32 am, Olaf M. Kolkman wrote:
> > > 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.
> >
> > I like this.
>
> 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.
>

That may be good enough.  We can also add something along the lines stating
that caches are not able to generate positive wildcard (and negative)
responses with complete accuracy, so it is best up to the cache to contact
the authoritative server and be as transparent as possible.  Or something
like that.

Scott