Hello Paul, I've got some good news and some bad news. The bad news is that the current stable Knot Resolver 5 is not able to reliably chase CNAMEs when forwarding, as you've discovered. The good news is that Knot Resolver 6 - currently in a sort of "early-access" / "beta" state - has been reworked to cover exactly this case. It can be done by using the 'authoritative' option in 'forward'. Of course, whether you want to use v6 or not depends on how critical the infrastructure you're running is. Mainly, some breaking changes to the configuration may happen between versions. The configuration format has also changed considerably (from Lua to YAML - with Lua being optionally available for expert tweaks) between 5 and 6. Here is the documentation for v6 covering the topic: https://www.knot-resolver.cz/documentation/latest/config-forward.html Best regards -- Oto Šťáva | Knot Resolver team lead | CZ.NIC z.s.p.o. PGP: 6DC2 B0CB 5935 EA7A 3961 4AA7 32B2 2D20 C9B4 E680 On 8/2/24 4:47 PM, Paul Furtado wrote: Hello, I am attempting to migrate some internal bind servers to knot+knot-resolver. We have knot acting as the authoritative server for internal views of our public zones and we're attempting to use Knot Resolver to forward to Knot to provide recursive resolution on the internal network. In this configuration, when Knot is resolving a CNAME record from an internal stub zone, it doesn't chase the target of the CNAME for the client. To demonstrate, here are two example zones served by knot: # zone1.com test-a 30 IN A 192.168.1.1 # zone2.com test-cname 30 CNAME test-a.zone1.com. With these configured as stubs in Knot Resolver, if you query test-cname.zone2.com, knot resolver won't chase it across zones to get the A record value like it would for non-stub zones. Both Bind9 and Unbound chase this as expected. Is there any way to configure Knot Resolver to do the same? Thanks! - Paul -- --