Weird behaviour in wildcard CNAME - is this feature or bug? Can it be changed?
Ondřej Surý
ondrej at isc.org
Tue Feb 11 15:35:03 UTC 2020
The wildcard doesn’t cover empty non terminals.
The only nonstandard implementation that did this was djbdns and the behavior was considered to be incompatible with rest of the DNS implementations.
Ondrej
--
Ondřej Surý — ISC
> On 11 Feb 2020, at 15:59, Petr Bena <petr at bena.rocks> wrote:
>
> 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
> _______________________________________________
> 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