Subject: Re: draft-ietf-dnsext-dnssec-intro-05.txt

From: Olaf Kolkman <[email-masked]>
Date: Mon, 17 Feb 2003 09:52:27 +0100

*   http://www.hactrn.net/ietf/dns/dnssec-editors/draft-ietf-dnsext-dnssec-int
 * ro-05.txt

I cannot get it from there....

(source address ik.dacht.net 193.0.3.28 )

--Olaf

--
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: Paul Vixie <[email-masked]>
Date: Wed, 12 Mar 2003 19:37:46 +0000

> The robustness principal probably applies here.

i'm sure it does but i think i interpret it in the opposite way.

> DS is a DNS infrastructure RR type, we know of no useful purpose that
> DS RRs anywhere other than at delegation points would serve, and at
> least some of us think that reusing existing RR types for
> fundamentally different purposes is a risky thing to do

others of us think that putting in feel-good restrictions whose implementation
status is unlikely to be rigourously tested (either for operability reasons or
interoperability reasons) ultimately does no good (ever) and some harm (often).

> ... therefore:
> 
> a) Zones either SHOULD NOT or MUST NOT include DS RRs anywhere but at
>    delegation points;
> 
> b) Software MUST cope if a zone violates (a).
> 
> I tend to think that (a) should be MUST NOT, on the grounds that it
> probably simplifies the implementation of (b) slightly (software must
> not fall on its face, full stop, but don't expect an implementation to
> do anything useful with a non-delegation DS RR).

i humbly disagree.  we should define what we mean and say that other uses are
undefined.  if we some day think of a reason to use these at non-delegation
points, it'll be wonderful to know that authority servers (both master and
slave) and caching forwarders are willing to pass the data through even though
they have reason to believe that it wasn't at a delegation point.