Subject: [dnsext] Trying to reading RFC 4035 as a requirements document

From: Edward Lewis <[email-masked]>
Date: Mon, 3 Aug 2009 13:09:18 -0400

I am trying to boil this document into a list of requirements and 
have run across a "MUST NOT" that I can't parse.

"and MUST NOT perform any of the additional processing described below."

The "additional processing described below" seems to be missing or 
has been altered in someway to make me wonder what is to be skipped - 
coming from the perspective of already understanding the protocol.

Following the "offending" use of requirement language (in the same 
paragraph) is a comment that DS's "always require" special 
processing, which is a contradiction with the previous MUST NOT.

The next point is about handling queries that are ambiguous, 
specifically the QNAME, CLASS, NSEC for names owning an NS set.  This 
situation applies DNSSEC or not.

Then there is talk about handling the CD and AD bits in situations 
they are to be ignored.  (Does this mean that without the DNSSEC 
indication in the query, we have to look at these bits? - the old 
double negative conundrum.)

Finally the comment about CNAME synthesis and "server... SHOULD NOT 
generate signatures".  Ignoring a negative requirement - a little 
hard to test.

I have no fix in mind because I'm puzzled about the intent of the 
offending requirement fragment.  Perhaps it should be omitted?

The text for convenience.  "^^^^" underlines the problem.

# 3.  Serving
#
#    ...
#
#    A security-aware name server that receives a DNS query that does not
#    include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
#    treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and
#    MUST NOT perform any of the additional processing described below.
---------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#    Because the DS RR type has the peculiar property of only existing in
#    the parent zone at delegation points, DS RRs always require some
#    special processing, as described in Section 3.1.4.1.
#
#    Security aware name servers that receive explicit queries for
#    security RR types that match the content of more than one zone that
#    it serves (for example, NSEC and RRSIG RRs above and below a
#    delegation point where the server is authoritative for both zones)
#    should behave self-consistently.  As long as the response is always
#    consistent for each query to the name server, the name server MAY
#    return one of the following:
#
#    o  The above-delegation RRsets.
#    o  The below-delegation RRsets.
#    o  Both above and below-delegation RRsets.
#    o  Empty answer section (no records).
#    o  Some other response.
#    o  An error.
#
#    DNSSEC allocates two new bits in the DNS message header: the CD
#    (Checking Disabled) bit and the AD (Authentic Data) bit.  The CD bit
#    is controlled by resolvers; a security-aware name server MUST copy
#    the CD bit from a query into the corresponding response.  The AD bit
#    is controlled by name servers; a security-aware name server MUST
#    ignore the setting of the AD bit in queries.  See Sections 3.1.6,
#    3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits.
#
#    A security aware name server that synthesizes CNAME RRs from DNAME
#    RRs as described in [RFC2672] SHOULD NOT generate signatures for the
#    synthesized CNAME RRs.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 04 Aug 2009 16:03:27 +1000

> "and MUST NOT perform any of the additional processing described below."

	Below is all the extra DNSSEC specific processing. e.g.
	adding RRSIG's to prove the answer or adding NSEC records
	to prove non-existance.

	Note for George.  RRSIG, DNSKEY, and NSEC RRs are expected
	to be returned with DO being clear.  ANY similarly returns
	them with DO being clear and is entirely consistant with
	them being returned with explict queries.  qmail is just
	broken.
 
> processing, which is a contradiction with the previous MUST NOT.

	Which is a comment about how to locate the DS records to
	be returned.  You still don't add RRSIGs / NSEC records.

> situation applies DNSSEC or not.

	No it doesn't.  Prior to DNSSEC answers come from the child
	zone.  Referrals come from the parent zone.  There is no
	ambiguity just mis-implemenations.  With DNSSEC you have
	RRsets (NSEC and RRSIG) which exist in both the child and
	parent zones which are different.  KEY (not DNSKEY) can
	also exist in both the parent and child zone at a zone cut.
 
> generate signatures".  Ignoring a negative requirement - a little 

	Is this better?

  A security aware name server that synthesizes CNAME RRs from DNAME
  RRs, as described in [RFC2672], SHOULD NOT generate signatures
  for the synthesized CNAME RRs despite that being recommended in
  [RFC2672].

	I can't see how this is hard to test.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

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