Suspecting the issue with 5.1.0 version related to unfit CNAME RR
Hi guys, last night I installed the new version of Knot Resolver (5.1.0) and I see that one of our critical domains is not being resolved properly when I set a policy to forward all requests to specified DNS:
-- forward all traffic to specified Azure IP addresses (selected automatically)
policy.add(policy.all(policy.FORWARD({'168.63.129.16'})))
When I run trace I get the following message:
[65570.01][iter] <= rcode: NOERROR
[65570.01][iter] <= cname chain, following
[65570.02][iter] '1803xxx.group21.sites.hubspot.net.' type 'A' new uid was assigned .03, parent uid .00
[65570.03][cach] => skipping unfit CNAME RR: rank 060, new TTL -908
If I run dig commands against the resolver I have to specify that I am looking for CNAME - then it works:
dig www.mydomain.com @10.64.33.8. - no result then dig -t cname www.mydomain.com @10.64.33.8 - works fine I get result:
;; ANSWER SECTION:
www.mydomain.com. 21 IN CNAME 1803xxx.group21.sites.hubspot.net.
This behavior is different from Knot Resolver 5.0.1 - that version worked fine.
I tried to google this and found this response located at: https://lists.nic.cz/pipermail/knot-resolver-users/2019/000179.html
" Hello.
You seem to be hitting quite a common stumbling point - you see:
On 5/23/19 3:10 AM, B. Cook wrote:
[cach] => NSEC sname: covered by: pccw. -> pe., new TTL 83379
i.e. kresd has a record from the root zone proving that there's no .pcsd TLD, so it answers NXDOMAIN. Usually it doesn't get such a record at start, and it might obtain a positive record that takes precedence, too, so it's easy to get confused... combining contradictory records is just tricky. I expect you can configure these particular TLD names - see docs for details: https://knot-resolver.readthedocs.io/en/latest/modules.html#replacing-part-of-the-dns-tree
--Vladimir "
Unfortunately, the provided link https://knot-resolver.readthedocs.io/en/latest/modules.html#replacing-part-of-the-dns-tree is broken.