Subject: Return value for DS query to a child zone

From: Scott Rose <[email-masked]>
Date: Wed, 28 Aug 2002 16:57:44 -0400

A new subject that has been raised at the DNSSEC workshop today:

Scenario:  A authoritative-only server (non-cache) that is DNSSEC aware
and follows the 
DS model of zone signing: foo.bar.  A client queries this server
(foo.bar authoritative server) for:

foo.bar.	IN	DS

Now: what is returned?  foo.bar. does not have the DS record.  "foo.bar.
IN DS" is stored in .bar. with the rest of the glue records for the
foo.bar. delegation.  bar.  is authoritative (and signs) the DS record
for foo.bar.  

possible responses:  
1.  NXDOMAIN  with the foo.bar. NXT RR showing that the DS record is not
in the foo.bar.  zone.  Should the AA bit be set in this response? 
foo.bar is claiming that foo.bar. DS does not exist (and it is
authoritative).

2.  A referral to root (upwards referral) to direct the client to query
root - hoping that eventually the  client will reach .bar and get the DS
record for foo.bar.  However, this may result in a loop in the client
(upward referral does not naturally occur in DNS).  This might end with
any caching server marking the foo.bar. server as lame. 

3.  Some new error code?  (IDUNNO - "The data might exist, I just don't
know where it is, even though I am technically authoritative for that
name...")

4  something else?

Disclaimer - it is hoped that this situation would never happen. 
Following the DNS with DNSSEC model, this should not happen.  One
possible example would be a non-DNSSEC aware parent and a DNSSEC aware
child that believes its parent is DNSSEC aware.  -OR- when a DNSSEC
aware application tries to use a non-DNSSEC aware caching resolver to
service recursive queries (the non-aware resolver would assume DS for
foo.bar. would be in foo.bar. - naturally).  

Scott

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