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

[Peter Koch]

Jinmei,

> 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.

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

> 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.

-Peter