One of the more controversial additions to the BIND name server in version
9.8.0 was a feature called Response Policy Zone Rewriting which allows
operators of recursive DNS servers (e.g. servers running at your ISP or in
your corporate environment) to rewrite answers returned by authoritative DNS
servers. (Paul Vixie had spoken about RPZ in Taking Back the DNS mid last
year.) This is basically what Unbound can implement on a per-installation
basis with its local-zone
and local-data
directives, with the twist that
BIND servers can replicate RPZ zones (from master to slaves) thereby offering
their content to a larger population of name servers. There are two steps
required for setting up and enabling RPZ:
- Create an RPZ zone
- Enable RPZ in BIND
An RPZ zone is a zone master file, which clients do not have to query directly
– the zone file is used by named
.
$TTL 60
@ IN SOA localhost. root.localhost. (
2 ; serial
3H ; refresh
1H ; retry
1W ; expiry
1H) ; minimum
IN NS localhost.
www.yahoo.com CNAME .
weather.yahoo.com CNAME *.
stocks.yahoo.com CNAME www.google.com.
ad.yahoo.com A 127.0.0.1
Note the values of rdata differ; this is what instructs BIND how to
answer a query for a particular name. (RPZ is documented in the BV9ARM.)
We configure the zone in named.conf
allowing our other BIND servers to
transfer the zone. (Note that the zone does not need to be delegated, so you
can use any convenient name.)
zone "rpz" {
type master;
file "rpz.db";
allow-query { none; };
allow-transfer { ... ; };
};
And finally, we enable our caching BIND servers to use the Response Policy Zone:
response-policy { zone "rpz"; };
Let me show you some of the replies I get from querying a BIND server for some of the names we’ve added to our RPZ zone. We start off by querying for the address of www.yahoo.com: the server returns an NXDOMAIN code indicating the domain does not exist, and the AUTHORITY section of the answer gives us an indication where the answer originated from.
dig www.yahoo.com
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
;; AUTHORITY SECTION:
rpz. 60 IN SOA localhost. root.localhost. 2 ...
When we query our server for weather.yahoo.com the response is slightly different: we just get no data returned.
dig weather.yahoo.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; AUTHORITY SECTION:
rpz. 60 IN SOA localhost. root.localhost. 2 ...
When we query for stocks.yahoo.com, the client gets data from the Google name servers:
dig stocks.yahoo.com
;; ANSWER SECTION:
stocks.yahoo.com. 60 IN CNAME www.google.com.
www.google.com. 604134 IN CNAME www.l.google.com.
www.l.google.com. 222 IN A 74.125.43.105 ....
And when we query for ad.yahoo.com the response contains our configured address:
$ dig ad.yahoo.com
;; ANSWER SECTION:
ad.yahoo.com. 60 IN A 127.0.0.1
;; AUTHORITY SECTION:
rpz. 60 IN NS localhost.
BIND applies the Response Policy when a server is queried recursively only. SURBL is, to my knowledge, one of the first to provide data via an RPZ zone. (Overview.) If you want some more examples, check the BIND Administrator Reference Manual (Bv9ARM) for version 9.8.0. You may also want to read RPZ, un moyen simple de configurer un résolveur DNS BIND pour qu’il mente (in French) by Stéphane Bortzmeyer, from whom I got the inspiration for this posting’s title.