Recursor RPZ does not follow CNAMEs

[scottg88]

Hi,

I have pdns recursor v4.0.0 installed and I'm testing the RPZ functionality.

With both rpzFile() and rpzMaster() the zone file is loaded correctly and is working, however defined policy actions are not applying. E.g.

rpzFile("/etc/pdns-recursor/example.rpz", {defpol=Policy.Drop})

This returns the IP address from the example.rpz file, not drop the query. Likewise Policy.Custom (e.g. {defpol=Policy.Custom, defcontent="test.example.com"}) does not return the custom response, it returns the IP from the file (or RPZ zone from master with rpzMaster()).

I'm using Centos 7, tried with packages from the v4 repo and the master repo (although at this time it looks like they're the same packages as v4 was just released).

Testing with SpamHaus DBL as well as the example.rpz from the RPZ announcement post:

$TTL 2h; $ORIGIN domain.example.com. @ SOA powerdns.example.net. hostmaster.example.com ( 1 12h 15m 3w 2h) NS powerdns.example.net. ; begin RPZ RR definitions

example.net A 192.168.2.5 *.example.net A 192.168.2.5

Example response with Policy.Drop:

Non-authoritative answer: Name: example.net Addresses: 192.168.2.5 192.168.2.5

Thanks.

[scottg88]

It looks like for rpzMaster I was trying the wrong domain, however rpzFile() does not appear to be working for me.

I am however having an issue still with Policy.Custom - I can see the CNAME being returned via dig, but without the IP address of the CNAME. Applications do not like this, e.g. ping or a web browser.

Examples:

dig dbltest.com

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.3 <<>> dbltest.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40121 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;dbltest.com. IN A

;; ANSWER SECTION: dbltest.com. 23 IN CNAME web.example.com.

;; Query time: 1 msec ;; SERVER: _#53(_) ;; WHEN: Fri Jul 15 13:27:24 AEST 2016 ;; MSG SIZE rcvd: 66

ping dbltest.com ping: unknown host dbltest.com

Example of a normal CNAME (not overriden by RPZ):

dig test.example.com

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.3 <<>> test.example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59458 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;test.example.com. IN A

;; ANSWER SECTION: test.example.com. 86400 IN CNAME web.example.com. web.example.com. 86400 IN A 1.1.1.1

;; Query time: 0 msec ;; SERVER: _#53(_) ;; WHEN: Fri Jul 15 13:29:53 AEST 2016 ;; MSG SIZE rcvd: 79

I have tested with a CNAME where the server would not have to recursively look it up by adding a zone (example.com) to the auth-zones setting and get the same result.

LUA config file:

rpzMaster("", "dbl.rpz.spamhaus.org", {defpol=Policy.Custom, defcontent="web.example.com", defttl=60, policyName="SpamHausDBL"})

[rgacogne]

If I understand correctly, you have two issues:

• the default policy does not override example.net A 192.168.2.5
• pdns does not follow the CNAME returned by your policy

Looking at the code, pdns does not override the local data policy with the default one (ie, only CNAME RR are overridden). After reading the RPZ docs, it looks like a bug to me. For the second one, some stub resolvers are indeed confused by the fact that we don't follow CNAMEs, maybe we could add something like followCNAMERecords at some point.

[Habbie]

On the second point, indeed we cannot expect stub resolvers to follow CNAMEs. I'm not aware of any that even can.

[rgacogne]

The first point should be fixed by #4215

[scottg88]

Thanks to both of you, I will test.

Regarding point 2, what is the expected behaviour for clients receiving the response I'm seeing? Pointing a client directly at pdns recursor configured with CNAME override fails to resolve the returned CNAME itself and behaves as if it got no result (tested in both Centos 7 + Windows 10).

Bind 9.9 configured in the same manner (RPZ with CNAME override) returns the following:

dig @x.x.x.x dbltest.com

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.3 <<>> @x.x.x.x dbltest.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54821 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;dbltest.com. IN A

;; ANSWER SECTION: dbltest.com. 5 IN CNAME web.example.com. web.example.com 1200 IN A y.y.y.y

;; AUTHORITY SECTION: [snip]

;; ADDITIONAL SECTION: [snip A/AAAA for authority section]

;; Query time: 578 msec ;; SERVER: x.x.x.x#53(x.x.x.x) ;; WHEN: Thu Jul 21 08:47:30 AEST 2016 ;; MSG SIZE rcvd: 266

[giganteous]

This problem does not exist on a Mac (mDns responder does chase the cname).