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

[Petr Bena]

Hello,

I fail to see that:

for example test.prod.app.pcp.cn.prod

step 2) search the available zones - the zone in question here is 
pcp.cn.prod which is found

step 3) no matching name is found but *.prod.app exists inside of 
pcp.cn.prod which is returned

However, with payis.test.prod.app.pcp.cn.prod

step 2) search the available zones - the zone in question here is 
pcp.cn.prod which is found

step 3) no matching name is found, *.prod.app exists inside of 
pcp.cn.prod but NXDOMAIN is returned instead?

Why?

How this algorith is broken if something under or above the requested 
record is existing?


On 11/02/2020 15:06, Mark Andrews wrote:
> 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