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

[Mark Andrews <[e-mail]>]

In message <a06240800c69cc735ef53@[10.31.200.165]>, Edward Lewis writes:
> 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."

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

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

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

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

	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.

> 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 [phone]
> 
> As with IPv6, the problem with the deployment of frictionless surfaces is
> that they're not getting traction.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>