Strange behaviour with multiple FORWARD policy and CNAME across them

[kmarty]

Hi, I'm trying to make something similar to unbound's cfg:

forward-zone:
    name: "zone-a"
    forward-addr: 192.168.1.4

forward-zone:
    name: "zone-b"
    forward-addr: 192.168.1.5

So I set this to kresd:

modules = {'policy'}

policy:add(policy.suffix(policy.FORWARD('192.168.1.4'), {todname('zone-a')}))
policy:add(policy.suffix(policy.FORWARD('192.168.1.5'), {todname('zone-b')}))

Expected behaviour (as made by unbound):

root@unbound:~# dig @::1 A a.zone-a
...
;; ANSWER SECTION:
a.zone-a.       300 IN  CNAME   b.zone-b.
b.zone-b.       300 IN  A   192.168.1.1
...

But Knot resolver does it ... strange :-/ :

root@kresd:/# dig @::1 A a.zone-a
...
;; connection timed out; no servers could be reached

with 'verbose(true)' I got:

root@kresd:/etc/init.d# /usr/sbin/kresd --addr=127.0.0.1#53 --addr=::1#53 --config=/etc/knot-resolver/kresd.conf --verbose /run/knot-resolver/cache
[system] interactive mode
> verbose(true)
true
> [plan] plan 'a.zone-a.' type 'A'
[resl]   => querying: '192.168.1.4' score: 1425 zone cut: '.' m12n: 'a.zone-A.' type: 'A' proto: 'udp'
[iter]   <= rcode: NOERROR
[iter]   <= cname chain, following
[plan] plan 'b.zone-b.' type 'A'
[resl]   <= server: '192.168.1.4' rtt: 1 ms
[resl]   => using root hints
[resl]   => querying: '2001:dc3::35' score: 10 zone cut: '.' m12n: 'zONe-B.' type: 'NS' proto: 'udp'
[resl]   => querying: '202.12.27.33' score: 10 zone cut: '.' m12n: 'zONe-B.' type: 'NS' proto: 'udp'
[resl]   => querying: '2001:500:9f::42' score: 10 zone cut: '.' m12n: 'zONe-B.' type: 'NS' proto: 'udp'
[resl]   => querying: '199.7.83.42' score: 10 zone cut: '.' m12n: 'zONe-B.' type: 'NS' proto: 'udp'
[wrkr]   => server: '2001:dc3::35' flagged as 'bad'
[wrkr]   => server: '202.12.27.33' flagged as 'bad'
[wrkr]   => server: '2001:500:9f::42' flagged as 'bad'
[wrkr]   => server: '199.7.83.42' flagged as 'bad'
[resl]   => querying: '2001:7fd::1' score: 10 zone cut: '.' m12n: 'zonE-B.' type: 'NS' proto: 'udp'
[resl]   => querying: '193.0.14.129' score: 10 zone cut: '.' m12n: 'zonE-B.' type: 'NS' proto: 'udp'
[resl]   => querying: '2001:503:c27::2:30' score: 10 zone cut: '.' m12n: 'zonE-B.' type: 'NS' proto: 'udp'
[resl]   => querying: '192.58.128.30' score: 10 zone cut: '.' m12n: 'zonE-B.' type: 'NS' proto: 'udp'

Am I doing something wrong which causes kresd forget forwarding zone 'zone-b' or what? (All tests were made in network isolated from Internet)

Simple query which doesn't go across zones works:

root@kresd:/# dig @::1 A b.zone-b
...
;; ANSWER SECTION:
b.zone-b.       300 IN  A   192.168.1.1
...

root@kresd:/# dig @::1 CNAME a.zone-a
...
;; ANSWER SECTION:
a.zone-a.       300 IN  CNAME   b.zone-b.
...

root@kresd:/# dig @::1 A direct-a.zone-a
...
;; ANSWER SECTION:
direct-a.zone-a.    300 IN  CNAME   direct.zone-a.
direct.zone-a.      300 IN  A   2.2.2.2
...

root@kresd:/# dig @::1 A direct-b.zone-b
...
;; ANSWER SECTION:
direct-b.zone-b.    300 IN  CNAME   direct.zone-b.
direct.zone-b.      300 IN  A   3.3.3.3
...

(Jestli je mozny psat cesky, tak bych byl rad. Ale nejspis ne, takze se omlouvam za kostrbatost - I'd be glad to write it in czech, but it is probably not allowed so I'm sorry)

[vcunat]

Right, some unexpected interaction between the modules, apparently. The policy isn't applied when following CNAME.

Your English seems very well understandable to me; all active devs do understand Czech, but English is preferred as it's generally more accessible.

[vcunat]

Yes, confirmed: as the module is written now, the policy rules are only applied to a full request and not at all during iteration (including CNAME followups).

@vavrusa: is that how the module was intended? I suppose we would better at least provide a switch that makes the policies apply in each step, to support such setups (e.g. easier switching from other resolvers).

[kmarty]

Ehm, maybe I'm wrong, but... kresd is a DNS resolver. It is his job. There is/should be nothing like "support for easier switching". It simply resolve or not. It results to difference like:

root@unbound:~# nc a.zone-a 25
220 b.zone-b ESMTP Exim 4.84_2 Mon, 07 Nov 2016 22:16:31 +0100
QUIT
221 b.zone-b closing connection

and:

root@kresd:~# nc a.zone-a 25
a.zone-a: forward host lookup failed: Host name lookup failure : Resource temporarily unavailable

[vcunat]

The difference can be big, sure, but both ways seem valid to me.

[vavrusa]

The policy rules are applied for ingress by default, but it makes sense to run them for outbound queries too. There's a hook for outbound queries now, it's just not utilised for filter rules. Not sure what is the use case you're trying to solve - internal zones that are linked together via CNAMEs are odd (maybe you have a reason though), and you can always work around that by not using the CNAME records.

[pspacek]

Merged with https://gitlab.labs.nic.cz/knot/knot-resolver/issues/217, closing. Please continue discussion on Gitlab.