[RPZ] RPZ behavior in the presence of DNSSEC signatures and DO=1 queries

Bill Owens owens at nysernet.org
Mon Jan 2 22:47:11 UTC 2012

A little while ago I wrote a blog article making a skeptical comparison between RPZ and PROTECT-IP. Paul Vixie commented on it, offering two points about the differences between them - the very real difference that one is voluntary and the other mandatory, which I completely agree with, and a statement that "RPZ stands aside whenever it sees a DNSSEC-aware client trying to access DNSSEC-signed data". 

The point about DNSSEC rang a bell, because I'd already tested BIND's NXDOMAIN redirection capability and had seen that it does work that way. I was working on a follow-up about what I see as a somewhat dim future for RPZ, based on that behavior, and wanted some examples to show. Surprisingly, I found that BIND, at least in 9.9.0b2, doesn't stand aside:

[turkle:~] owens% dig @ www.isc.org a +dnssec

; <<>> DiG 9.8.1 <<>> @ www.isc.org a +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60310
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

; EDNS: version: 0, flags: do; udp: 512
;www.isc.org.			IN	A

rpz.zone.		60	IN	SOA	rpz.zone. rpz.zone. 2012010201 3600 300 86400 60

;; Query time: 11 msec
;; WHEN: Mon Jan  2 17:39:35 2012
;; MSG SIZE  rcvd: 84

I have an extremely simple RPZ config, about as minimal as possible I think:

options {
. . .
	response-policy { zone "rpz.zone"; };

zone "rpz.zone" {
	type master;
	file "rpz.zone";
	allow-query { localhost; };

And the file itself:
$TTL 300
@		IN	SOA	rpz.zone. rpz.zone. (
				2012010201 3600 300 86400 60 )

		IN	NS	localhost.

www.isc.org	IN	CNAME	.
www.opendns.com	IN	CNAME	.

The opendns.com entry is there to have a non-signed comparison, but both work identically. 

So, now I'm trying to decide between three options: do I have RPZ configured wrong, is the code in 9.9.0b2 not the latest version (seems unlikely), or is it behaving as designed?


More information about the DNSfirewalls mailing list