Subject: [dnsext] ENT wildcard derived from insecure delegation + Opt-Out NSEC3

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 31 Jan 2013 20:55:36 -0800

I have a question related to the recent errata for RFC5155 on
empty non terminal:
http://www.rfc-editor.org/errata_search.php?rfc=5155&eid=3441

What if the empty non terminal is a wildcard?  For example,

example. ;; zone origin, has SOA, NS, matching NSEC3 etc
;; x.example. ;; empty, covered by opt-out NSEC3
;; *.x.example. ;; empty and wildcard, covered by opt-out NSEC3
child.*.x.example. IN NS ns.example.com. ;; insecure, no DS, opt-out

and query is y.x.example./A.  What should be returned in this case?

Section 7.2.5 of RFC5155 states:

   If there is a wildcard match for QNAME, but QTYPE is not present at
   that name, the response MUST include a closest encloser proof for
   QNAME and MUST include the NSEC3 RR that matches the wildcard.  This
   combination proves both that QNAME itself does not exist and that a
   wildcard that matches QNAME does exist.  Note that the closest
   encloser to QNAME MUST be the immediate ancestor of the wildcard RR
   (if this is not the case, then something has gone wrong).

In this case, the closest encloser proof is NSEC3 that matches
example. and NSEC3 that covers x.example (that would have Opt-Out).
But there's no "NSEC3 RR that matches the wildcard".  Also, the
closest (provable) encloser to QNAME (= example.) is not the immediate
ancestor of the wildcard (RR), which is x.example.

Is this case included in the discussion that led to the errata?  I
re-read the dnsext archive but couldn't be sure (as far as I can see
the wildcard-related discussions at that time were about different
issues than this one).  Or is this case excluded by some other rules?

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.