This is indeed related to the CNAME classification change in 1.7.1.
After that change responses for the minimised queries can be treated as
CNAME responses. Unbound has a limit in number of CNAMEs to follow to
prevent loops, that limit is 8. Because the nameserver here gives CNAMEs
for for some of the minimsed CNAME targets, the number of received
CNAMEs passes the maximum and Unbound stops resolving.
I committed a fix that only counts CNAME for the full name, not for the
On 11-06-18 23:31, Håkan Lindqvist via Unbound-users wrote:
> I ran into and issue where it appears that Unbound 1.7.1 fails to
> resolve some Akamai CDN names if qname-minimisation is enabled
> (consistently responds with SERVFAIL).
> 1.7.0 did not exhibit the same behavior with identical configuration.
> A couple of example names: cdn.samsung.com
> <http://cdn.samsung.com>, storeedgefd.dsx.mp.microsoft.com
> <http://storeedgefd.dsx.mp.microsoft.com> (eg "dig
> @unbound cdn.samsung.com <http://cdn.samsung.com>")
> With verbosity turned up, the log includes:
> debug: request has exceeded the maximum number of query restarts with 9
> debug: return error response SERVFAIL
> It appears Unbound intentionally aborts, and the limits don't appear to
> have changed since 1.7.0, but maybe the accounting has changed?
> (I'm not sure if the "Fix cname classification with qname minimisation
> enabled." change could be related?)
> I also ran across one other mention of what I believe is the same issue
> Is this a straight up bug or is there some settings (other than
> disabling qname-minimisation) that I just fail to find that can counter
> this new behavior?
> I find it a bit concerning since there's some very high profile
> sites/services using the affected Akamai CDN (with their rather
> enthusiastic CNAME usage) and that 1.7.2 apparently enables
> qname-minisation by default.