Subject: rfc4035: missing text on empty-non-terminal proof

From: Roy Arends <[email-masked]>
Date: Wed, 11 May 2005 12:33:11 +0200 (CEST)

WG,

RFC4035 lacks an example of 'empty non-terminal' (ENT) proof, nor does
section 5.4 (Authenticated Denial of Existence), second bullet handle the
case where a security-aware resolver encounters a NODATA because of ENT.

Since this particular NODATA proof is different then normal NODATA proof,
I've written a small erratum for section 5.4, listed below, and a addendum
to section B.3 and C.3 (respectively labeled: B.3.1 and C.3.1).

Comments are welcome,

Thanks,

Roy

5.4.  Authenticated Denial of Existence

**original text at second bullet:
   o  If the requested RR name would appear after an authenticated NSEC
      RR's owner name and before the name listed in that NSEC RR's Next
      Domain Name field according to the canonical DNS name order
      defined in [RFC4034], then no RRsets with the requested name exist
      in the zone.  However, it is possible that a wildcard could be
      used to match the requested RR owner name and type, so proving
      that the requested RRset does not exist also requires proving that
      no possible wildcard RRset exists that could have been used to
      generate a positive response.

**suggested text for second bullet:

   o  If the requested RR name would appear after an authenticated NSEC
      RR's owner name and before the name listed in that NSEC RR's Next
      Domain Name field according to the canonical DNS name order
      defined in [RFC4034], then no RRsets with the requested name exist
      in the zone.  If the name listed in that NSEC RR's Next Domain
      Name field is a subdomain of the requested RR name, then the
      requested RR name is an empty non-terminal.  Since the requested
      RR name implicitly exists, there is no need to prove the existence
      of a possible wildcard match.  However, if the name listed in that
      NSEC RR's Next Domain Name field is not a subdomain of the
      requested RR name, it is possible that a wildcard could be used to
      match the requested RR owner name and type, so proving that the
      requested RRset does not exist also requires proving that no
      possible wildcard RRset exists that could have been used to
      generate a positive response.

B.3.1.  No Data Error, Empty Non-terminal

   A "no data" response for an empty non-terminal.  The NSEC RR
   proves that the name implicitly exists.  It exists because a
   subdomain exists.

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   y.w.example.        IN A

   ;; Answer
   ;; (empty)

   ;; Authority
   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
                              1081539377
                              3600
                              300
                              3600000
                              3600
                              )
   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
                              20040409183619 38519 example.
                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
                              jV7j86HyQgM5e7+miRAz8V01b0I= )
   x.w.example.   3600 NSEC   x.y.w.example. MX RRSIG NSEC
   x.w.example.   3600 RRSIG  NSEC 5 3 3600 20040509183619 (
                              20040409183619 38519 example.
                              aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK
                              vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E
                              mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI
                              NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e
                              IjgiM8PXkBQtxPq37wDKALkyn7Q= )

   ;; Additional
   ;; (empty)

C.3.1.  No Data Error, Empty Non-terminal

   The query in Appendix B.3.1 returned an NSEC RR that proves that the
   requested name implicitly exists.  The value of the Next Owner Name
   of the NSEC is a subdomain of the QNAME.  The negative reply is
   authenticated by verifying the NSEC RR.  The NSEC RR is authenticated
   in a manner identical to that of the MX RRset discussed above.  Since
   the NSEC record proves the existence of the requested name, there is
   no need to prove existence of a wildcard RR.

--
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: Samuel Weiler <[email-masked]>
Date: Thu, 12 May 2005 16:07:58 -0400 (EDT)

> to section B.3 and C.3 (respectively labeled: B.3.1 and C.3.1).

As a purely editorial matter, I've been trying to describe and fix the
deficiencies of the bis docs without actually rewriting them in place.

Being as this is the second issue with the non-existence proof
section, though, I'm wondering if something more invasive may be
needed in this case.  The other issue is documented in Section 6 of
dnssec-bis-updates-00 (you can see the discussion that led to this in
the namedroppers archives from March 9-10) -- I'd be delighted to have
specific suggestions as to how present both of these most clearly.

Here's the text:

   6.  Clarifications on Non-Existence Proofs

   RFC4035 Section 5.4 slightly underspecifies the algorithm for
   checking non-existence proofs.  In particular, the algorithm there
   might incorrectly allow the NSEC from the parent side of a zone cut
   to prove the non-existence of either other RRs at that name in the
   child zone or other names in the child zone.

   A parent-side delegation NSEC (one with the NS bit set, but no SOA
   bit set, and with a singer field that's shorter than the owner name)
   must not be used to assume non-existence of any RRs below that zone
   cut (both RRs at that ownername and at ownernames with more leading
   labels, no matter their content).

-- Sam