Wildcard in NS record

Barry Margolin barmar at genuity.net
Fri Oct 19 22:44:04 UTC 2001

In article <9qq8dt$adu at pub3.rc.vix.com>,
Kevin Darcy  <kcd at daimlerchrysler.com> wrote:
>Wildcard NS'es can't legally work, since "delegation cancels the wildcard
>defaults" (I'm quoting from RFC 1034 here).

The other reason why wildcard NS'es don't work is because they aren't
searched for in the resolution algorithm.  From section 4.3.2 of RFC 1034:

         b. If a match would take us out of the authoritative data,
            we have a referral.  This happens when we encounter a
            node with NS RRs marking cuts along the bottom of a
         c. If at some label, a match is impossible (i.e., the
            corresponding label does not exist), look to see if a
            the "*" label exists.
	    If the "*" label does exist, match RRs at that node
            against QTYPE.  If any match, copy them into the answer
            section, but set the owner of the RR to be QNAME, and
            not the node with the "*" label.  Go to step 6.

Notice that NS records are detected in step 3b *before* checking for
wildcards, and that wildcard checking in step 3c only selects records of
the specific type that were being queried for.

> BIND 9 is just enforcing the
>standards that earlier BIND versions should have been enforcing. You'll
>have to delegate each subzone individually.

On a related note, does anyone know what BIND 9 does with wildcard CNAME
records.  We have about a dozen records of the form:

* IN CNAME something.else.com.

We also have a half dozen entries where the wildcard isn't in the terminal

mail.* IN CNAME something.else.com.

Neither of these should work according to my reading of the RFC 1034
algorithm, so when our customers first asked for them I resisted (I had
even programmed our DNS database UI to prohibit them).  One of them showed
me that BIND handled them in the intuitively expected way, so I relented
(and removed the check from the UI).  If you want to see them in action,
look up <anything>.paylessutuado.com or mail.<anything>.hamptoninn.com.  I
hope we won't have to go back and tell these customers to find another
solution when we upgrade our authoritative servers to BIND 9.

Barry Margolin, barmar at genuity.net
Genuity, Woburn, MA
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

More information about the bind-users mailing list