Skip to content
Snippets Groups Projects

policies and sub-queries

    • Closed Issue created by Vladimír Čunát @vcunat

    Policies are currently only applied to full requests, i.e. when begin happens for layers. We do copy the flag and server list when creating sub-queries, but:

    • not everywhere, e.g. the dns64 module is broken in this respect;
    • the subquery might be for a name that the policy should apply differently, e.g. users attempting to handle different parts of the DNS tree differently. A similar situation is on CNAME jumps, as those may also lead to a different part of the tree.
    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items ...

    • Activity

    • Vladimír Čunát mentioned in commit 0b748e0e

      mentioned in commit 0b748e0e

    • Vladimír Čunát mentioned in issue #218

      mentioned in issue #218

    • Vladimír Čunát mentioned in issue #203 (closed)

      mentioned in issue #203 (closed)

    • Petr Špaček mentioned in issue #205 (closed)

      mentioned in issue #205 (closed)

    • Petr Špaček
      Petr Špaček @pspacek ·
      Contributor

      Example from user kmarty commented on Nov 7, 2016 taken from https://github.com/CZ-NIC/knot-resolver/issues/33

      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
...

      Comments from vcunat on Nov 7, 2016:

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

      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).

      Comments from kmarty commented on Nov 7, 2016: 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

      Comment from vcunat commented on Nov 7, 2016: The difference can be big, sure, but both ways seem valid to me.

      Comment from vavrusa commented on Nov 9, 2016: 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.

    • Petr Špaček added major usability labels

      added major usability labels

    • Petr Špaček removed bug label

      removed bug label

    • Petr Špaček mentioned in merge request !573 (closed)

      mentioned in merge request !573 (closed)

    • Tomas Krizek mentioned in merge request !771 (merged)

      mentioned in merge request !771 (merged)

    • Vladimír Čunát
      Vladimír Čunát @vcunat ·
      Author Owner

      One approach has been suggested by Marek but I can't say I really like it, as a long-term solution at least.

      One issue is that evaluating policy rules is not cheap ATM, and this approach would cause that to run much more often. A hook for starting sub-queries (struct kr_query) would probably be much better in this respect, and that should still cover all CNAME jumps (also NS records not simply taken from glue, etc.)

    • Stéphane Bortzmeyer
      Stéphane Bortzmeyer @bortzmeyer ·

      Why a solution to this problem is important for Knot: https://medium.com/nextdns/cname-cloaking-the-dangerous-disguise-of-third-party-trackers-195205dc522a

    • Vladimír Čunát mentioned in issue #523 (closed)

      mentioned in issue #523 (closed)

    • Petr Špaček
      Petr Špaček @pspacek ·
      Contributor

      Executing policies on all requests will be costly.

      I wonder if there is an easy way to make this in-depth filtering configurable so the cost is paid only be people who want this in-depth filtering.

    • Petr Špaček
      Petr Špaček @pspacek ·
      Contributor

      An example how this blocking can be achieved is available in mailing list archives: https://lists.nic.cz/pipermail/knot-resolver-users/2019/000228.html

      EDIT after years:

      Edited by Vladimír Čunát
    • Petr Špaček mentioned in issue #535

      mentioned in issue #535

      • Kisuke
        Kisuke @Kisuke-CZE ·

        Just ran into this issue last week. Tried to use Knot Resolver in a testing environment. Purpose was to find out if BIND can be replaced with Knot Resolver. The answer is sadly NO.

        This is kinda big issue when I have domain which exists only in internal DNS tree (so I must replace part of DNS tree in Knot Resolver). When internal domain has some CNAME to an external domain, resolver cannot fully resolve it for a client.

        Full example follows.

        Let's have this authoritative DNS server configuration in /etc/knot/knot.conf:

        server:
    rundir: "/run/knot"
    user: knot:knot
    automatic-acl: on
    listen: [ 10.11.2.38@53 ]

log:
  - target: syslog
    any: info

database:
    storage: "/var/lib/knot"


template:
  - id: default
    storage: "/var/lib/knot"
    file: "%s.zone"
    serial-policy: dateserial

zone:
  - domain: example.localdomain

        And zone data in /var/lib/knot/example.localdomain.zone is this for example:

        ;; Zone dump (Knot DNS 3.2.4)
example.localdomain.           	1800	SOA	dns-auth01.example.localdomain. hostmaster.example.localdomain. 2023012300 10800 3600 864000 10800
example.localdomain.           	1800	NS	dns-auth01.example.localdomain.
example.localdomain.           	1800	NS	dns-auth02.example.localdomain.
example.localdomain.           	1800	MX	50 smtp01.example.localdomain.
example.localdomain.           	1800	MX	50 smtp02.example.localdomain.
lyncdiscover.example.localdomain.	3600	CNAME	webdir.online.lync.com.
smtp01.example.localdomain.     	1800	A	10.11.150.108
smtp02.example.localdomain.     	1800	A	10.11.150.109
dns-auth01.example.localdomain.        1800    A       10.11.2.38
dns-auth02.example.localdomain.        1800    A       10.11.2.39
dns-rec-testing.example.localdomain.        1800    A       10.11.2.42
;; Written 269 records
;; Time 2023-01-23 13:25:22 CET

        Now let's configure resolver for client in the way to resolve everything, but resolve local domain via our authoritative server. So try to create /etc/knot-resolver/kresd.conf:

        -- Network interface configuration
net.listen('0.0.0.0', 53, { kind = 'dns' })

-- Load useful modules
modules = {
	'hints > iterate',  -- Allow loading /etc/hosts or custom root hints
	'stats',            -- Track internal statistics
	'predict',          -- Prefetch expiring/frequent records
}

log_level('info')

-- Cache size
cache.size = 100 * MB

-- Set resolving paths for internal domains
internalDomains = policy.todnames({
      'example.localdomain'  
      })

policy.add(policy.suffix(policy.FLAGS({'NO_CACHE'}), internalDomains))
policy.add(policy.suffix(policy.STUB({
      '10.11.2.38'
      }), internalDomains))

        Also tried this variant (and it does not help):

        -- Network interface configuration
net.listen('0.0.0.0', 53, { kind = 'dns' })

-- Load useful modules
modules = {
	'hints > iterate',  -- Allow loading /etc/hosts or custom root hints
	'stats',            -- Track internal statistics
	'predict',          -- Prefetch expiring/frequent records
}

log_level('info')

-- Cache size
cache.size = 100 * MB

trust_anchors.set_insecure({
  'example.localdomain'
   })

-- Set resolving paths for internal domains
internalDomains = policy.todnames({
     'example.localdomain'  
     })

policy.add(policy.suffix(policy.FORWARD({
      '10.11.2.38'
      }), internalDomains))

        Now we can try to query the resolver with dig @dns-rec-testing.example.localdomain lyncdiscover.example.localdomain And we got answer like this:

        ; <<>> DiG 9.16.1-Ubuntu <<>> @dns-rec-testing.example.localdomain lyncdiscover.example.localdomain
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52377
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;lyncdiscover.example.localdomain.		IN	A

;; ANSWER SECTION:
lyncdiscover.example.localdomain.	3600	IN	CNAME	webdir.online.lync.com.

;; Query time: 8 msec
;; SERVER: 10.11.2.42#53(10.11.2.42)
;; WHEN: Út led 24 13:08:16 CET 2023
;; MSG SIZE  rcvd: 86

        If I use alternative configuration with policy.FORWARD I got SERVFAIL because QUERY for webdir.online.lync.com was sent to my authoritative server which refused it of course (since it's not authoritative for domain lync.com).

        I believe this is related to this issue with subrequests.

        Edited by Kisuke
      • Vladimír Čunát
        Vladimír Čunát @vcunat ·
        Author Owner

        Our FORWARD and STUB always assume that the target is a resolver (trusted for the whole DNS tree), not an authoritative server, so CNAMEs returned from them are assumed to be fully resolved (i.e. in this case pointing to NODATA).

        But anyway, the new declarative policy plans do include your use case which Unbound calls stub-zone. (And also a possibility to add in-resolver CNAME records that get followed.)

      • Please register or sign in to reply
    • Vladimír Čunát
      Vladimír Čunát @vcunat ·
      Author Owner

      I believe this can be closed now. See #535 (comment 295494)

    • Vladimír Čunát closed

      closed

    Please register or sign in to reply