Subject: Moving DS into the parent (was: How does a sever for child answer a DS query.)

From: Sam Weiler <[email-masked]>
Date: Wed, 18 Sep 2002 15:12:46 -0400 (EDT)

So far we've found two gothcas[1] from having the DS record looking
like it belongs in the child zone, yet declaring the parent to be
authoritative for it.  We can work around both, but I'm worried that
there may be more out there (here, have some more FUD).  Perhaps a
better answer is to move the DS into the parent zone:

in .com:
	microsoft.com	   NS ...   ;; .com is not authoritative
	_ds_microsoft.com  DS ...   ;; .com is authoritative
or
	microsoft._ds_.com DS ...   ;; .com is authoritative

Yes, this is gross, but it keeps the semantics unchanged, which keeps
any similar problems from popping up later when it may be too late to
fix them.

Issue: the NXT chain.  If _ds_microsoft.com gets it's own NXT and
SIG(NXT), zones get bigger.  If you include it as part of
microsoft.com's NXT (and have the DS bit refer to something with a
different name), that still leaves both parent and child with NXTs
with matching names, which may lead to more problems of the same sort.

-- Sam

[1] Both gotchas come into play when a legacy (non-DNSSEC-aware) cache
is between the DNSSEC-aware authoritative server and client.

Last Tuesday, Olafur wrote:

> DS is the first real record that can only exist at the parent thus
> this issue has never been explored.
>
> In the early years of DS deployment non DS aware resolvers/caches
> will blindly send DS queries to the child servers, thus is it
> important that the answer returned have no negative implications for
> future queries for records from the child zone.

There's also an issue with cache timeouts: if the DS times out before
the NS, a legacy cache can't find the DS, which limits child NS TTLs
to the DS TTL set by the parent.

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