Subject: NCACHE mandatory for DS?

From: Lars-Johan Liman <[email-masked]>
Date: Tue, 18 Sep 2001 15:42:21 +0200 (MEST)

Something occured to me, while reading section 2.1.1 of =D3lafur's
draft-ietf-dnsext-delegation-signer-01.txt. He mentions the potential
problems of NS and DS having different TTLs, and thereby causing extra
queries for (timed out) DS records.

Please, help me think here. Won't this be the general case, so to
speak?

What if there is no DS RR for the child zone (it's insecure!)? Then a
DS-aware resolver will go look for one. It doesn't find it. Oh-well,
insecure child zone - no big deal. Next time around it will find the
NS RR in the cache, but not the DS RR (not because of TTL timeout, but
because of non-existence!) - so it goes looking for one, doesn't find
it, oh-well, insecure child zone - no big deal. Next time around -
same thing, and again, and again.

This is of course strongly mittigated by negative cacheing, but if you
_don't_ have that, you're going to have a steady stream of DS queries
for every normal query to an insecure zone, right? Or is there some
other mechanism, that I've misplaced in my memory, that kicks in to
prevent this behaviour? There is no NULL key to cache ...

Is there reason to make NCACHE mandatory in DS-aware resolvers? Is
there even reason to recommend icky tweaking of the negative TTL for
non-existing DS RRs, to match the corresponding NS RRs?

				Cheers,
				  /Liman
#----------------------------------------------------------------------
# Lars-Johan Liman		! E-mail: [email-masked]
# Senior Systems Specialist     ! HTTP  : //www.autonomica.se/
# Autonomica AB, Stockholm 	! Voice : +46 8 - 615 85 72
#----------------------------------------------------------------------

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Derek Atkins <[email-masked]>
Date: 18 Sep 2001 12:14:17 -0400

Wouldn't the NXT record (or otherwise) show that the DS record should
not exist anyways?  Or is the resolver not smart enough to notice that
before requested a non-existent/non-cached record?

-derek

PS: (I suppose this just pushes the onus onto the NXT record instead
of the DS record, or the SEC record, for insecure zones).

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Roy Arends <[email-masked]>
Date: Tue, 18 Sep 2001 19:51:12 +0200 (CEST)

Whoops, replying to myself.

On Tue, 18 Sep 2001, Roy Arends wrote:

> On 18 Sep 2001, Derek Atkins wrote:
>
> When the initial query-response is cached, it has either the set NS,DS,SIG
> cached or the set NXT SIG cached for the qname and qtype. If the first set
> is cached, and the DS expires, there is no other way then specifically
> querying for DS, since it has no NXT cached.

To be complete: the NS,DS,SIG set is only when the child is secured. When
the child is unsecure, the set NS,NXT,SIG will do the trick, since NXT
signals the absence of DS. This is also mentioned in the draft.

Regards,

Roy Arends
Nominum

---

From: Roy Arends <[email-masked]>
Date: Tue, 18 Sep 2001 19:44:23 +0200 (CEST)

Regards,

Roy

> > non-existing DS RRs, to match the corresponding NS RRs?

-------------
0-14-023750-X dcrpt ths 43.0D.01 01.05.0C 84.18.03 8A.13.04 2D.0B.0A

---

From: Jim Reid <[email-masked]>
Date: Tue, 18 Sep 2001 10:53:11 -0700

>>>>> "Liman" == Lars-Johan Liman <[email-masked]> writes:

    Liman> Is there reason to make NCACHE mandatory in DS-aware
    Liman> resolvers?

Perhaps. But since the DNS implementations which will presumably
implement DS already support negative caching, the question is moot.