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

[Edward Lewis <[e-mail]>]

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 [phone]

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