Weird behaviour in wildcard CNAME - is this feature or bug? Can it be changed?

Mark Andrews marka at isc.org
Tue Feb 11 14:06:52 UTC 2020


Yes, this is standard behaviour.  It falls out of this section of RFC 1034
which is part of STD 13 (DNS).  Work the algorithm by hand with the records
you said existed in the zone.

4.3.2. Algorithm


The actual algorithm used by the name server will depend on the local OS
and data structures used to store RRs.  The following algorithm assumes
that the RRs are organized in several tree structures, one for each
zone, and another for the cache:

   1. Set or clear the value of recursion available in the response
      depending on whether the name server is willing to provide
      recursive service.  If recursive service is available and
      requested via the RD bit in the query, go to step 5,
      otherwise step 2.

   2. Search the available zones for the zone which is the nearest
      ancestor to QNAME.  If such a zone is found, go to step 3,
      otherwise step 4.

   3. Start matching down, label by label, in the zone.  The
      matching process can terminate several ways:

         a. If the whole of QNAME is matched, we have found the
            node.

            If the data at the node is a CNAME, and QTYPE doesn't
            match CNAME, copy the CNAME RR into the answer section
            of the response, change QNAME to the canonical name in
            the CNAME RR, and go back to step 1.

            Otherwise, copy all RRs which match QTYPE into the
            answer section and go to step 6.

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

            Copy the NS RRs for the subzone into the authority
            section of the reply.  Put whatever addresses are
            available into the additional section, using glue RRs
            if the addresses are not available from authoritative
            data or the cache.  Go to step 4.

         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 not exist, check whether the name
            we are looking for is the original QNAME in the query
            or a name we have followed due to a CNAME.  If the name
            is original, set an authoritative name error in the
            response and exit.  Otherwise just exit.

            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.

   4. Start matching down in the cache.  If QNAME is found in the
      cache, copy all RRs attached to it that match QTYPE into the
      answer section.  If there was no delegation from
      authoritative data, look for the best one from the cache, and
      put it in the authority section.  Go to step 6.

   5. Using the local resolver or a copy of its algorithm (see
      resolver section of this memo) to answer the query.  Store
      the results, including any intermediate CNAMEs, in the answer
      section of the response.

   6. Using local data only, attempt to add other RRs which may be
      useful to the additional section of the query.  Exit.



> On 12 Feb 2020, at 00:45, Petr Bena <petr at bena.rocks> wrote:
> 
> But, is this behaviour consistent with other DNS software (microsoft DNS etc.), or is this specific only to BIND9?
> 
> Is there any standard / documentation that explain how or why is this happening? Because it just doesn't make any sense to me.
> 
> On 11/02/2020 14:39, Tony Finch wrote:
>> Petr Bena <petr at bena.rocks> wrote:
>>> Why is this? Is that normal or a bug?
>> It's because wildcards in the DNS are crazy and totally abnormal, but
>> sadly ossified tradition means it cannot be considered a bug. (It's also
>> intimately tied up with the subtle semantics of NXDOMAIN, and rigidly
>> enforced by DNSSEC.) It's annoying because it makes wildcards a lot less
>> useful than one might hope.
>> 
>> https://tools.ietf.org/html/rfc4592 - The Role of Wildcards in the Domain Name System.
>> https://tools.ietf.org/html/rfc8020 - NXDOMAIN: There Really Is Nothing Underneath.
>> 
>> Tony.
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org



More information about the bind-users mailing list