2 Srp
2024
2 Srp
'24
17:33
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 <http://zone1.com>
test-a 30 IN A 192.168.1.1
# zone2.com <http://zone2.com>
test-cname 30 CNAME test-a.zone1.com <http://test-a.zone1.com>.
With these configured as stubs in Knot Resolver, if you query
test-cname.zone2.com <http://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
--