Subject: [dnsext] Comments on draft-ietf-dnsext-dnssec-bis-updates-09

From: Florian Weimer <[email-masked]>
Date: Sun, 06 Sep 2009 14:35:56 +0000

Section 4.8 doesn't make sense to me.  In practice, it's not
observable if a caching resolver sets the CD bit on upstream queries
because the need for upstream queries is not predictable.  If the
purpose of this section is to mandate distinct caches for CD=0 and
CD=1 (or turn of caching completely for CD=1), then it needs to be
clarified.

I would like to see a permission to synthesize negative answers from
NSEC/NSEC3 replies.  This could be used to stop certain in-protocol
reflective denial-of-service attacks, at least for small zones.  (Such
attacks already seem to happen.)

---

From: Mark Andrews <[email-masked]>
Date: Tue, 08 Sep 2009 17:29:03 +1000

> CD=1 (or turn of caching completely for CD=1), then it needs to be

The point is to be able to get answers which would normally be
blocked by validating recursive servers regardless of the number
of validating recursive servers are in the path.

> attacks already seem to happen.)

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Florian Weimer <[email-masked]>
Date: Tue, 08 Sep 2009 19:22:06 +0000

> of validating recursive servers are in the path.

But RFC 4035 says this in section 3.2.2:

|  If the resolver side implements a BAD cache (see Section 4.7) and the
|  name server side receives a query that matches an entry in the
|  resolver side's BAD cache, the name server side's response depends on
|  the state of the CD bit in the original query.  If the CD bit is set,
|  the name server side SHOULD return the data from the BAD cache; if
|  the CD bit is not set, the name server side MUST return RCODE 2
|  (server failure).

The latter case appears to be the relevant one to me, so I still don't
see how the advice in section 4.8 of the draft matters in practice.

If you want to achieve what you said, you need CD-specific caching (or
uncached processing of CD=1 queries).

---

From: Mark Andrews <[email-masked]>
Date: Wed, 09 Sep 2009 12:37:26 +1000

> see how the advice in section 4.8 of the draft matters in practice.

You still need to make upstream queries to populate either the
normal cache or a BAD cache (assuming you have one).  Anything in
a BAD cache would have had CD=1 on the upstream query because to
enter the BAD cache it had to fail validation and to validate you
make CD=1 queries.