[Pdns-users] Are queries towards RPZ domains supposed to use the packet cache?

[sthaug at nethelp.no]

I have previously used PowerDNS recursor and RPZ while treating all
query sources equally. This works fine.

I'm now trying to use RPZ to block copyright type domains selectively
based on source IP from the query, by using Lua discardPolicy. I'm
seeing an unexpected interaction with the packet cache.

Environment: FreeBSD 12.1-STABLE, PowerDNS recursor 4.2.0 installed
from FreeBSD package.

Contents of lua-config-file:

rpzFile("/usr/local/etc/pdns/copyright.zone", {policyName="copyright"})

Contents of copyright.zone:

$TTL 300
@ SOA localhost. nobody.localhost. 42 1d 12h 1w 3h
@ NS localhost.
;
thepiratebay.se A 10.11.12.13
*.thepiratebay.se A 10.11.12.13
...

Contents of lua-dns-script:

badips = newNMG()
badips:addMask("193.75.110.130/32")

function prerpz(dq)
    pdnslog("prerpz called")
    if badips:match(dq.remoteaddr) then
        pdnslog("prerpz match IP to skip copyright domain check")
        dq:discardPolicy("copyright")
    end
    return false
end

Right after starting PowerDNS recursor (i.e. empty packetcache):

- If I query from 193.75.110.130 with an empty packetcache, the RPZ
check is skipped, as expected, and I get

thepiratebay.se.        3600    IN      SOA     a.ns14.net. curdsadns.internetx.de. 2018070501 43200 7200 1209600 432000

- If I query from a different IP with an empty packetcache, the RPZ
policy is used, and I get

thepiratebay.se.        300     IN      A       10.11.12.13

This all seems fine. However, if the packetcache already contains
the reply to the query above (either the RPZ policy reply or the
actual reply from for instance a.ns14.net), this reply is handed
out to *all* query addresses. I.e. it appears as if the RPC policy
check (or the skipping of same, from discardPolicy) happens after
the packetcache is consulted. This is highly visible in the logs
by using "trace=on" in the recursor.conf file.

Example 1: Packetcache contains:

thepiratebay.se.        3600    IN      SOA     a.ns14.net. curdsadns.internetx.de. 2018070501 43200 7200 1209600 432000

because it was queried from 193.75.110.130 right after startup.
Subsequent queries, whether they come from 193.75.110.130 or a
different IP, show hits in the packetcache:

Feb 10 14:54:48 x pdns_recursor[32563]: 3 question answered from packet cache tag=0 from 193.75.110.130:39453
Feb 10 14:54:50 x pdns_recursor[32563]: 3 question answered from packet cache tag=0 from 193.75.110.130:47250
Feb 10 14:55:10 x pdns_recursor[32563]: 3 question answered from packet cache tag=0 from 193.75.110.134:37866
Feb 10 14:55:13 x pdns_recursor[32563]: 3 question answered from packet cache tag=0 from 193.75.110.134:10022

and in the replies one can see that TTL counts down:

thepiratebay.se.        3598    IN      SOA     a.ns14.net. curdsadns.internetx.de. 2018070501 43200 7200 1209600 432000
thepiratebay.se.        3596    IN      SOA     a.ns14.net. curdsadns.internetx.de. 2018070501 43200 7200 1209600 432000

etc.

Example 2: Packetcache contains

thepiratebay.se.        300     IN      A       10.11.12.13

because it was queried from a different IP than 193.75.110.130
right after startup. Subsequent queries, whether they come from
193.75.110.130 or a different IP, show hits in the packetcache:

Feb 10 15:04:04 x pdns_recursor[32627]: 3 question answered from packet cache tag=0 from 193.75.110.134:53118
Feb 10 15:04:06 x pdns_recursor[32627]: 3 question answered from packet cache tag=0 from 193.75.110.134:53282
Feb 10 15:04:12 x pdns_recursor[32627]: 3 question answered from packet cache tag=0 from 193.75.110.130:65401
Feb 10 15:04:14 x pdns_recursor[32627]: 3 question answered from packet cache tag=0 from 193.75.110.130:29779

and in the replies one can see that the TTP counts down:

thepiratebay.se.        298     IN      A       10.11.12.13
thepiratebay.se.        296     IN      A       10.11.12.13

etc.

My question is basically: Is this behavior expected? I find it highly
surprising, since it basically means that the RPZ functionality (and
whether it works or not) depends on packetcache contents.

A small twist on the above behavior: If the query contains a DNS
cookie (e.g. if generated by newer versions of dig), it seems the
packetcache is not consulted - which means that RPZ works the way
I want. But I cannot depend on DNS cookies always being set...

Steinar Haug, AS2116