Subject: DNSSECbis Q-30: DNAME awareness

From: Rob Austein <[email-masked]>
Date: Wed, 24 Mar 2004 14:08:52 -0500

Q-30: Should the DNSSECbis specs require DNAME-awareness?

Approximate text to be added if the WG agrees:

 [To be inserted somewhere in Section 3.x of -protocol]

   A security-aware name server which synthesizes CNAME RRs from DNAME
   RRs as described in RFC 2672 SHOULD NOT generate signatures for the
   synthesized CNAMEs.

 [To be inserted somewhere in Section 4.x of -protocol]

   A validating security-aware resolver MUST treat the signature of a
   valid signed DNAME RR as also covering unsigned CNAME RRs which
   could have been synthesized from the DNAME RR as described in
   RFC-2672, at least to the extent of not rejecting a response
   message solely because it contains such CNAME RRs.  The resolver
   MAY retain such CNAME RRs in its cache or in the answers it hands
   back, but is not required to do so.

Background:

  RFC-2672 recommends that name servers synthesize CNAME RRs based on
  DNAME RRs, for backwards compatability with DNAME-oblivious
  resolvers.  RFC-2672 goes on to suggest that DNSSEC-capable name
  servers might want to keep the zone key online in order to sign
  these synthesized CNAME RRs, for the benefit of security-aware
  DNAME-oblivious resolvers.  This has obvious security issues, and
  also adds some complexity.  In fairness, note that when RFC-2672
  came out, DNSSEC-classic (RFC 2535) had already shipped, so one
  could argue that this was the least bad backwards compatability hack
  available to the author of RFC-2672.

  So the question here is whether there is any need for DNSSECbis to
  support security-aware DNAME-oblivious implementations.
  Specifically, can we eliminate the case of a security-aware
  DNAME-oblivious resolver expecting name servers to synthesize signed
  CNAME RRs from signed DNAME RRs?

  DNSSECbis question Q-27 already covered part of this space, by
  allowing a security-aware recursive name server to set the AD bit
  for responses containing synthesized CNAME RRs.  Q-27 did not,
  however address whether name servers should attempt to sign
  synthesized CNAME records or whether resolvers should expect to
  receive signatures for synthesized CNAME records.

  Whether a validating resolver choses to retain synthesized CNAMEs or
  not appears to be an implementation and local policy choice, since
  CNAME synthesis itself is only a SHOULD in RFC-2672 and thus not
  something on which any DNS-using software can depend.

Deadline and default:

  Per instructions from the WG chairs, this question will time out on
  4 April 2003 with a default action to accept these changes.

--
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: Edward Lewis <[email-masked]>
Date: Fri, 26 Mar 2004 11:33:53 -0500

I like what these words say.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

If time travel were ever to be realized, public key crypto is toast.

---

From: Rob Austein <[email-masked]>
Date: Wed, 24 Mar 2004 14:08:52 -0500

Background:

Deadline and default:

---

From: Edward Lewis <[email-masked]>
Date: Fri, 26 Mar 2004 11:33:53 -0500