Weird behaviour in wildcard CNAME - is this feature or bug? Can it be changed?
Petr Bena
petr at bena.rocks
Tue Feb 11 14:58:50 UTC 2020
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
More information about the bind-users
mailing list