> On Apr 17, 2018, at 3:58 PM, admin--- via Exim-dev <exim-dev@???> wrote:
>
> Per the discussion starting
> https://lists.dns-oarc.net/pipermail/dns-operations/2018-April/017449.html
> we should trust that the resolver is doing the right thing, following CNAME
> chains itself - meaning that a CNAME return from a CNAME lookup will always
> be an infinite loop and should be treated as NODATA. The limited loop we
> have can be removed so we do not hammer the resolver.
Specifically, the relevant guidance is in:
https://tools.ietf.org/html/rfc6604#section-3
which explains that the RCODE for a response (with qtype != CNAME) in which the initial qname leads to a CNAME indicates the status of the query for the requested qtype at the final CNAME in the chain. This means (modulo DNSSEC failures, which lead to ServFail):
1. If the final name has data for the requested type,
it must be present in the response (modulo truncation,
which should lead to TCP retries...). The RCODE is then NOERROR
2. If the final name has no data of the requested type, the RCODE
is still NOERROR, and no data of the requested type is provided.
(thus effectively NODATA).
3. If the final name does not exist, the RCODE is NXDOMAIN
4. If the resolver exceeded its recursion limit the RCODE is SERVEFAIL
5. If there's a CNAME loop, the RCODE is typically SERVFAIL, but some
nameservers return the looping CNAMEs and NOERROR, only reported
with BIND when the final CNAME is a direct loop (x -> x).
This means that the DNS client can always infer all it needs from a single
response, and should make iterative queries for each (or any) returned
CNAMEs. Instead it should be willing to iteratively parse the original
response chasing CNAMEs within the response to find the requested data.
Note that the order of RRsets in the response is not guaranteed, and in
theory the answer may come before the CNAMEs and the CNAMEs might not be
in order (neither "pathology" is common, but sadly one must be prepared).
--
Viktor.
