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

[JINMEI Tatuya / 神明達哉]

At Fri, 4 Feb 2011 20:46:54 +0100,
Peter Koch <pk at DENIC.DE> wrote:

First, this point:

> {btw, woul "reject" mean to reject/ignore the RRSet or the whole zone?}

It means rejecting the whole zone to be loaded if it includes a
wildcard name with the RRs in question:

dns_master_load: jinmei.zone:55: *.nswild.jinmei.org: invalid NS owner name (wildcard)
zone jinmei.org/IN: loading from master file jinmei.zone failed: invalid NS owner name (wildcard)
zone jinmei.org/IN: not loaded due to errors

> > 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.
> 
> the NS RRSet owned by a wildcard might make sense in the delegating zone,
> the hard part would probably be implementing a delegated zone with "*" at
> the leftmost label.  So, when you whether to accept or reject, the question
> is whether acceptance can lead to an unambiguous implementation.

According to RFC4592, DNSSEC brings a "paradox".  We may be able to
find an unambiguous behavior if the delegating/delegated zones are
unsigned, but for BIND 10 I think it makes sense to be compatible with
BIND 9.  Rejecting such a case at loading will make the rest of the
implementation simpler and more predictable, and since most of (at
least initial) users of BIND 10 would also be BIND 9 users who
shouldn't have a problem with its behavior, we won't see much push
back by having the same restriction.

For NSEC3 and DNAME, your response below seems to suggest the same
conclusion I mentioned in my other response in this thread:
 - NSEC3 + wildcard is meaningless, but wouldn't be specifically
   harmful (so it's okay to simply accept it)
 - DNAME + wildcard is harmful (so it rather makes sense to reject it
   at loading time)

> > 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 ....)
> 
> Since NSEC3 RRs can only have a particular shape directly underneath
> the zone level, multi-label owner names might not make sense at all.
> Especially since NSEC3 RRs do not bring their "owners" into existence
> and thus cannot be queried for.  The only purpose these would have is that
> of a subliminal channel travelling with the zone during XFR.  The wildcard
> owner should not be special in any way.
> 
> > 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.
> 
> My recollection is that DNAME at a "*" owner can lead to conflicting
> semantics, inducing a paradox.  Assume *.example.org DNAME example.de,
> then an explicit query for no.good.example.org would result in a DNAME
> no.good.example.org DNAME example.de.  However, asking for
> no.good.example.org A might not even triger the DNAME since
> "no.good" is _not_ below(!) "*" and thus DNAME doesn't cover.
> There were other difficulties that made wildcard DNAME RRs extremely
> unpredictable.

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