Subject: proposed text for 'direct nsec queries'

From: Miek Gieben <[email-masked]>
Date: Tue, 20 Jan 2004 22:04:53 +0100

Hello,

Following up on some discussions on the (tiny) subject of direct queries for
NSEC I propose something like the following text to be included in the drafts.

[this mail is sent to provoke some discussion]

proposed text for protocol-05

Direct Queries for NSEC Records at Delegation Points

When the qtype equals NSEC and the qname equals the delegation point of a zone,
a problem can pop up when a server is both authoritative for the parent and
child. RFC 2535 said that in this case both NSEC's should be returned. It failed
to specify how a resolver should treat these two NSEC's. These two records are
identical except in their rdata. The child NSEC has the SOA bit set, while the
parent has not. Unlike any other RR these two are not a RRset and a resolver
must treat them differently from any other RR type. 

The current spec (2535bis) is silent on this topic and we want to avoid opening
a can of worms when specifying this behavior. The current thinking is that
direct NSEC queries are never required for the normal operation of the DNS (ie
resolving). 

Another problem is correlated to caches. Depending on the server behavior a
cache would either have a child's NSEC or parental NSEC or both. The client can
not specify which NSEC it wants. This is also not specified in 2535.

For these reasons direct queries for NSEC can not be relied upon, therefor the
reply from the server is not specified in this document. Resolvers cannot depend
on the data returned in the answer.

grtz
      Miek

--
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: Jim Reid <[email-masked]>
Date: Wed, 21 Jan 2004 00:31:43 +0000

Miek, I have a couple of comments on your proposed text.

Since we're supposed to be superseding RFC2535, I think the draft
should not refer back to something that's effectively dead. This is
even more important when we know a corner case is being left
unspecified that was also left unspecified in 2535. If 2535 got this
wrong, we should take this opportunity to fix it. As part of the
overall DNSSEC tidy-up and rewrite, I think some clarity is needed
here on (a) what the server should and shouldn't do; and (b) what a
resolver is expected to do with that response. If there's a corner
case because a server is authoritative for the parent and child, the
draft should eliminate it by clearly documenting what the server and
resolver should do and shouldn't do for that case. Or at the very
least the draft should say what the preferred behaviour is. [And why.]
IMO some clarity is needed here: the draft should say what it means
and mean what it says. Your proposed text is too fluffy IMO. It could
be misinterpreted. That might lead to inconsistences in implementation
because it leaves enough wiggle room for a server to do one thing while
a resolver does the other.

Some of the language you suggested looks bad. It's inappropriate for a
standards-track RFC to use phrases like "a can of worms" or "a problem
can pop up". Y'know, like, this doesn't read well, man. Know what I
mean, dude? Sure, 2535 is a can of worms. But it's one that should get
a bullet in the head, if I can mix metaphors.

How about the text below?

Explicit Queries for NSEC Records at Delegation Points

Special consideration will be needed in the case of queries for an
NSEC QTYPE when the QNAME is a delegation point and the server is
authoritative for both the parent and child zones. In these
circumstances the server will have two NSEC records with different
RDATA matching the query. One will be from the parent zone for the
delegation and the other will be from the child zone. These two NSEC
records MUST NOT be treated as an RRset. The server SHOULD (MUST?)
return both NSEC records in response to such queries. When NSEC
records exist above and below a zone cut for some QNAME, a resolver
making an explicit NSEC query cannot specify which of these two NSEC
records it wants. Therefore, a resolver which makes an explicit query
for an NSEC qtype MUST (SHOULD?) be prepared to receive a response
containing both these NSEC records. It cannot know in advance that the
QNAME is a delegation point or if the queried server is authoritative
for both the parent and child zones.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Jan 2004 01:47:24 +0000

> for both the parent and child zones.

miek's proposed text was better.  (note that miek said it was only draft
discussion quality, so it was unfair of jim to question its informality.)

there are too many corner cases to cover if we want to define "proper"
behaviour for queries at delegation points.  for example, what if the
reason were that the server had recursion enabled and had thusly cached
the above-the-cut NSEC RR?  for this reason, a proposal limited to servers
who are authoritative for both the parent and child is not useful.

miek's proposal is in my opinion the correct one in this circumstance.
since there is no protocol necessity for above-the-cut NSEC queries, it
is reasonable to specifically undefine them.  some servers may decide
to answer with delegation responses when queried for anything "at" a
delegation point (other than the DS RRset, which may be required due to
the grandparent problem).  some servers may decide to issue SERVFAIL
when queried for NSEC "at" a delegation point.  if we place a requirement
on it then we have to explain our reasoning and enumerate the cases where
our requirement applies.  if we just say it's undefined, then we're done.

---

From: Jim Reid <[email-masked]>
Date: Wed, 21 Jan 2004 13:08:07 +0000

>>>>> "Paul" == Paul Vixie <[email-masked]> writes:

    Paul> miek's proposed text was better.  (note that miek said it
    Paul> was only draft discussion quality, so it was unfair of jim
    Paul> to question its informality.)

Maybe so. But that discussion would/should lead to agreed text for the
draft that goes to last call. More formal language would be needed
eventually. That process might as well start as the proposed text is
discussed and refined.

    Paul> there are too many corner cases to cover if we want to
    Paul> define "proper" behaviour for queries at delegation points.

Sigh. I fear there may well be too many corner cases. But IMO that
isn't justification for not documenting them.

    Paul> some servers may decide to issue SERVFAIL when queried for
    Paul> NSEC "at" a delegation point.

This worries me. Something smells very bad -- more than DNSSEC usually
smells bad -- if the spec leaves something so wide open that different
implementations could return responses as far apart as NOERROR and
SERVFAIL for the same query, all other things being equal.

    Paul> if we place a requirement on it then we
    Paul> have to explain our reasoning and enumerate the cases where
    Paul> our requirement applies.  if we just say it's undefined,
    Paul> then we're done.

But we'll have done a sloppy job and could well be revisiting the
problem in 5-10 year's time. By which time everyone will have
forgotten what those cases and requirements were. [And then they'll
pop up wackamole-style again, just as they've been doing for the last
umpteen years of DNSSEC development.] If the corner cases are known
about now, they should at the very least be enumerated and
documented. So if the spec is going to say something is undefined, it
should say why the behaviour is undefined.

---

From: Miek Gieben <[email-masked]>
Date: Wed, 21 Jan 2004 14:47:18 +0100

[On 21 Jan, @02:47, Paul wrote in "Re: proposed text for 'direct  ..."]
> discussion quality, so it was unfair of jim to question its informality.)

it was indeed alpha quality :-)

The reason to define explicit server behavior would be: "give back what you've
got" - property of DNS. But this leads to weird corner cases that also need to
be documented, which could lead to even more corner cases. We don't want to 
go there for these weirdo nsec queries.

Therefor I think it is best to define it to 'undefined'. Direct queries for nsec
are not part of the normal resolving process. If a resolver _needs_ an nsec it
will get the nsec in the answer (as part of a nxdomain respons, for instance).

> the grandparent problem).  some servers may decide to issue SERVFAIL

or a 'REFUSED'. The only thing resolvers need to know is that nsec queries are
special and that answers to those queries can not relied up on. And that nsec's
are always alone in a RRset.

regards,
Miek

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Jan 2004 17:47:25 +0000

> isn't justification for not documenting them.

it can be, though, if the corner case you didn't cover ends up being
the one that matters to somebody.  if you deliberately undefine it,
then noone will (sanely) depend on implementation-specific behaviour.

> SERVFAIL for the same query, all other things being equal.

it's not the only thing that's deliberately left undefined.  if you send
a query that makes no sense you will get an answer that makes no sense.
consider the "upward referral" problem, where an authority-only server
receives a query for a zone it doesn't carry.  correct answers range from
SERVFAIL to a list of root name servers (which an authority only server
might not even have).  sometimes the best thing to do is specify the part
you care about and explicitly note the unspecificity of the parts you don't
care about.  asking for NSEC RR's qualifies squarely in this category, and
we are indebted to miek for pointing this out.

> ...  So if the spec is going to say something is undefined, it should
> say why the behaviour is undefined.

i believe that miek's proposed text does that.

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 23 Jan 2004 12:15:38 +0100 (CET)

RFC2535 allows numbers or mnemonics for the flags and protocol fields
in the KEY RR presentation format, but -records drops that for DNSKEY
and requires numbers.  Was that intentional?

-records also allows algorithm mnemonics in the DS presentation
format, but RFC3658 only allows numbers (for both the algorithm and
digest type fields).  Again, was that intentional?

To summarize:

Field               Allowed presentation formats   Different?
                    -records   RFC2535  RFC3658
(DNS)KEY algorithm   either    either
(DNS)KEY flags       number    either                X
(DNS)KEY protocol    number    either                X
DS algorithm         either             number       X
DS digest            number             number
SIG algorithm        either    either

-- Sam

---

From: "Scott Rose" <[email-masked]>
Date: Fri, 23 Jan 2004 08:42:06 -0500

I do not seem to recall any discussion on the list about dropping the
mnemonic option in the presentation format.  Someone please correct me if I
am wrong.  Is there an objection to allowing the algorithm mnemonic in the
presentation formats of the DS/RRSIG and DNSKEY RRs?

Since there is only one protocol value now (3), I feel the mnemonics for
that field could be safely dropped.

Scott

---

From: Brian Wellington <[email-masked]>
Date: Fri, 23 Jan 2004 16:43:11 -0800 (PST)

> that field could be safely dropped.

This sounds like an argument for dropping the field, not dropping support
for mnemonics.  If there's only one value, it shouldn't exist at all.
Having a field whose only legal value is '3' is confusing.

Brian

---

From: Samuel Weiler <[email-masked]>
Date: Sun, 25 Jan 2004 23:28:00 +0100 (CET)

After thinking about this more, I like the choices made by -records
now and, even though they are changes, I suggest we adopt them.

The DNSKEY flags mnemonic scheme is acrane.  The BIND signing tools
don't generate DNSKEYs with flags or protocol mnemonics, and I have
yet to hear any of us whine.  I suggest that we drop those.

For the algorithm field, I'd like for DS, RRSIG, and DNSKEY to be
consistent.  Having spent some time arguing about algorithm mnemonics
for the TCR document, I have a bit of a personal attachment to them,
and I'd like to see them stay.  If someone would be so kind as to dig
through the DS discussion from ages past and see why mnemonics were
dropped, that might be useful to us now.

--- Sam

---

From: Paul Vixie <[email-masked]>
Date: Mon, 26 Jan 2004 01:32:56 +0000

> now and, even though they are changes, I suggest we adopt them.

as long as this doesn't set a precedent whereby all small changes which
are improvements are also accepted (which is infinite regress for dnssec)
i agree.

> yet to hear any of us whine.  I suggest that we drop those.

for the record, if bind ends up being wrong, we would fix it immediately.
what i mean is, the above indicates an oversight, not intention, by isc.

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 26 Feb 2004 09:48:32 -0500

My guess is the mnemonics were dropped without thinking.  No one really uses
them, since tools are used to generated, parse, and sign the DNSSEC RRs.  No
one thought about using mnemonics when numbers worked for machines.

Scott