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.

Continued…