Subject: Re: nsec++

From: Paul Vixie <[email-masked]>
Date: Thu, 04 Dec 2003 16:39:45 +0000

> ...
> I think we don't want to make the NSEC more difficult than it already is
> (compared to the NXT definition). 
> 
> So I would vote to keep the current NSEC definition as it as and get
> used to the fact is takes up a few more bytes,

it's all just fun and games until microsoft decides to sign zones containing
their private-allocation types (in the 65000 range.)

--
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: Mon, 08 Dec 2003 15:22:45 +0000

>>>>> "Miek" == Miek Gieben <[email-masked]> writes:

    >>    A security-aware recursive name server MUST NOT attempt
    >> to answer a query by piecing together cached data it
    >> received in response to previous queries that requested
    >> different QNAMEs, QTYPEs, or QCLASSes.  A security-aware
    >> recursive name server MUST NOT use NSEC RRs from one
    >> negative response to synthesize a response for a different
    >> query.  A security-aware recursive name server MUST NOT use
    >> a previous wildcard expansion to generate a response to a
    >> different query.

    Miek> I don't "get" the first sentence. does that really say:
    Miek> "don't use the cache"?  If i'm a cache and i've just
    Miek> validated a DNSKEY in response to another query, I cannot
    Miek> use that validated DNSKEY?

No, it doesn't say "don't use the cache". Well, not to this
mother-tongue English speaker anyway. It says "don't use cached data
to compose or fill out an answer to a query you've not resolved". I
think the intention here is to cover things like glue or partial
responses from an authoritative server. If the resolving server has
previously resolved and validated the glue or other stuff that might
be missing from the authoritative server's response, the resolving
server MUST NOT add these things to the reply it returns to its end
client. That's my interpretation of this bit of the draft.

Perhaps the language could be made less opaque?

    Miek> Further more, if this question is answered negatively (A
    Miek> cache can still be used), i'm wondering why is this put in a
    Miek> protocol draft? Isn't this bordering implementation details?

Some clarification is needed on when and how cached data can and
cannot be used. This is an implementation detail that will be critical
to how the protocol gets implemented. :-)

---

From: Jim Reid <[email-masked]>
Date: Tue, 09 Dec 2003 12:23:35 +0000

>>>>> "Miek" == Miek Gieben <[email-masked]> writes:

    Miek> A security-aware recursive name server MUST NOT attempt to
    Miek> answer a query by piecing together non validated, cached
    Miek> data (i.e. glue) it received in response to previous queries
    Miek> that requested different QNAMEs, QTYPEs, or QCLASSes. 

Yes, it is clearer IMO. But I think the security aware server should
do that for all cached data, not just non-validated data. Suppose the
resolver gets a signed answer that says the next name after a.foo is
z.foo. Is it right for the server to infer that no other names exist
between a.foo and z.foo for as long it it caches that answer? If it
then gets a lookup for b.foo, should it respond with the already
cached answer or should it resolve b.foo and return the answer to that
to the client? [Suppose the authoritative servers for foo add b.foo
while the resolving server is still caching that NXT record for a.foo
pointing at z.foo.] There are valid arguments that either of these
options is correct (or wrong). A statement of what's the correct
behaviour for this scenario would be preferable to leaving this
undefined and ambiguous.

How about the text below?

	A security-aware recursive name server MUST NOT synthesise or
	augment responses, for instance to populate the Additional
	Section, using cached data from earlier lookups. Cached data
	MUST NOT be used in a response unless it results from a
	response to an earlier query that exactly matches the QNAME, 
	QTYPE and QCLASS for the current query.

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 10 Dec 2003 16:03:35 +0100

* Bit 0 in the first bitmap in the first window does not encode for any=20
 * RR. Shouldn't this bit get a status of reserved in the draft? Or doesn't
 * it matter if it's 1 or 0.

This is "Silly State" again :-) (that issue is closed)

See
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01851.html

--Olaf
  DNSEXT Chair