[bind10-dev] NS/NSEC3/DNAME at wildcard

[JINMEI Tatuya / 神明達哉]

I've been looking at the wildcard implementation of BIND 9, and
noticed:
 - it rejects loading NS RR at a wildcard name (e.g. *.example NS ns.example)
 - it rejects loading NSEC3 RR at a wildcard name

According to Section 4.2 of RFC4592, "Operationally, inclusion of
wildcard NS RRSets in a zone is discouraged, but not barred."  But it
may make sense to reject it because it would cause troubles.

RFC5155 doesn't say anything about the case where the owner name of
NSEC3 is a wildcard, but it's syntactically impossible if the NSEC3 is
generated as specified in RFC5155, so it may also be okay to reject
it.  (BTW, for this reason I'd even reject empty non terminal
wildcards with NSEC3, e.g., foo.*.example. NSEC3 ....)

On the other hand, BIND 9 accepts DNAME RR at a wildcard name.  Both
RFC4592 and draft-ietf-dnsext-rfc2672bis-dname-21 discourage such
usage as strongly as they do so for NS at a wildcard.  So, if the
reason BIND 9 rejects NS+wildcard was "because it's harmful even if
it's not prohibited", it seems to me the same argument should apply to
the DNAME case.

Now, what should we do for BIND 10?  My initial feeling is to keep the
same behavior as BIND 9 for NS and NSEC 3 based on the least
astonishment principle (even though it's "too strict" according to the
protocol standards).  I'm not so sure about the case of DNAME and
empty non terminal NSEC3, but I'm inclined to reject them as a natural
extension of the (seeming) BIND 9 policy.

In any event, these are very minor cases and users probably just don't
care.  But if someone has a specific opinion or suggestion (with
reasons), please let me know (on this list).

Thanks,

---
JINMEI, Tatuya