{"id":1555,"date":"2017-08-31T15:28:08","date_gmt":"2017-08-31T20:28:08","guid":{"rendered":"http:\/\/lisa.rushworth.us\/?p=1555"},"modified":"2017-08-31T18:07:39","modified_gmt":"2017-08-31T23:07:39","slug":"configuring-and-using-rpz","status":"publish","type":"post","link":"https:\/\/www.rushworth.us\/lisa\/?p=1555","title":{"rendered":"Configuring and Using RPZ"},"content":{"rendered":"

I realized today what, while I had written about why<\/em> response policy zones are useful<\/a>, I never indicated how to configure one! So here’s a quick document outlining how to set it up in ISC Bind. In your named.conf file, add a response policy to your options section:<\/p>\n

\u00a0 \u00a0 \u00a0 \u00a0 response-policy {<\/div>\n
\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 zone “rpz”;<\/div>\n
\u00a0 \u00a0 \u00a0 \u00a0 };<\/div>\n
<\/div>\n
Then add the correspondingly named zone at the end of the file. For purposes of testing, I added a zone as a forward only zone so I could perform a network capture to see what exactly transpires when a name in the RPZ is resolved.<\/div>\n
<\/div>\n
zone “rpz” {<\/div>\n
\u00a0 \u00a0 \u00a0 type master;<\/div>\n
\u00a0 \u00a0 \u00a0 file “rpz.db”;<\/div>\n
\u00a0 \u00a0 \u00a0 allow-query { none; };<\/div>\n
\u00a0 \u00a0 \u00a0 allow-transfer { none; };<\/div>\n
};<\/div>\n
\n
zone “windstream.com” {<\/div>\n
\u00a0 \u00a0 type forward;<\/div>\n
\u00a0 \u00a0 forward only;<\/div>\n
\u00a0 \u00a0 forwarders { 8.8.8.8; };<\/div>\n
};<\/div>\n<\/div>\n
<\/div>\n
Then you just have to make a rpz.db where you store your named files:<\/div>\n
\n
$TTL 60\r\n$ORIGIN rpz.\r\n@            IN    SOA  localhost. root.localhost.  (\r\n                          2   ; serial\r\n                          3H  ; refresh\r\n                          1H  ; retry\r\n                          1W  ; expiry\r\n                          1H) ; minimum\r\n                  IN    NS    localhost.\r\n\r\nwww.windstream.com    CNAME    www.yahoo.com.\r\n<\/pre>\n<\/div>\n
<\/div>\n
Restarted named and ran “rndc flush” to avoid serving cached content instead of the RPZ host data. Then ran a few tests and confirmed that the resolution configured in the rpz zone:<\/div>\n
<\/div>\n
[lisa@fedora02 named]# dig +short www.windstream.com @localhost<\/div>\n
www.yahoo.com.<\/div>\n
atsv2-fp.wg1.b.yahoo.com.<\/div>\n
98.139.183.24<\/div>\n
98.138.252.30<\/div>\n
98.139.180.149<\/div>\n
98.138.253.109<\/div>\n
<\/div>\n
[lisa@fedora02 named]# dig +short dell905.windstream.com @localhost<\/div>\n
ns4.windstream.com.<\/div>\n
173.186.244.139<\/div>\n
<\/div>\n
[lisa@fedora02 named]# dig +short www.google.com @localhost<\/div>\n
216.58.218.228<\/div>\n
<\/div>\n
In this process, I learnt something interesting about ICS’s implementation of RPZ: it still performs the query and\u00a0then<\/i>\u00a0overrides the results. Odd waste of cycles, but the resolution that was subsequently turned into yahoo’s address from the rpz zone. Looking up a windstream.com host that\u00a0isn’t<\/i>\u00a0in my RPZ and I got another query out to 8.8.8.8 which was expected. Query to something not in the forward zone and not in the rpz zone and I get no traffic to 8.8.8.8 (because it follows my normal forwarding which is to our ISP’s DNS).<\/div>\n
<\/div>\n
\"\"<\/a><\/div>\n
I was curious if this meant rpz could\u00a0not<\/em> be used to publish a bad hostname locally – but attempting to resolve a bad hostname (added abadhost.windstream.com with the same CNAME to Yahoo and reloaded my zone) worked just fine.<\/div>\n
\n
[root@fedora02 ~]# dig abadhost.windstream.com @localhost<\/p>\n
; <<>> DiG 9.11.1-P2-RedHat-9.11.1-2.P2.fc26 <<>> abadhost.windstream.com @localhost
\n;; global options: +cmd
\n;; Got answer:
\n;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8382
\n;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 4, ADDITIONAL: 3<\/p>\n
;; OPT PSEUDOSECTION:
\n; EDNS: version: 0, flags:; udp: 4096
\n; COOKIE: 1aa34751c5df7f78857a921259a8706fb5e1741a46eb5352 (good)
\n;; QUESTION SECTION:
\n;abadhost.windstream.com. IN A<\/p>\n
;; ANSWER SECTION:
\nabadhost.windstream.com. 5 IN CNAME www.yahoo.com.
\nwww.yahoo.com. 1800 IN CNAME atsv2-fp.wg1.b.yahoo.com.
\natsv2-fp.wg1.b.yahoo.com. 60 IN A 98.139.180.149
\natsv2-fp.wg1.b.yahoo.com. 60 IN A 98.138.253.109
\natsv2-fp.wg1.b.yahoo.com. 60 IN A 98.139.183.24
\natsv2-fp.wg1.b.yahoo.com. 60 IN A 98.138.252.30<\/p>\n
;; AUTHORITY SECTION:
\nwg1.b.yahoo.com. 172800 IN NS yf3.a1.b.yahoo.net.
\nwg1.b.yahoo.com. 172800 IN NS yf4.a1.b.yahoo.net.
\nwg1.b.yahoo.com. 172800 IN NS yf1.yahoo.com.
\nwg1.b.yahoo.com. 172800 IN NS yf2.yahoo.com.<\/p>\n
;; ADDITIONAL SECTION:
\nyf1.yahoo.com. 86400 IN A 68.142.254.15
\nyf2.yahoo.com. 86400 IN A 68.180.130.15<\/p>\n
;; Query time: 1204 msec
\n;; SERVER: ::1#53(::1)
\n;; WHEN: Thu Aug 31 16:24:15 EDT 2017
\n;; MSG SIZE rcvd: 315<\/p>\n
But there\u00a0is<\/em> a query that goes out to the name server and a ‘no such name’ result returned. Odd.<\/p>\n
\"\"<\/a><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
I realized today what, while I had written about why response policy zones are useful, I never indicated how to configure one! So here’s a quick document outlining how to set it up in ISC Bind. In your named.conf file, add a response policy to your options section: \u00a0 \u00a0 \u00a0 \u00a0 response-policy { \u00a0 …<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[30],"tags":[99,313,314,315,101],"class_list":["post-1555","post","type-post","status-publish","format-standard","hentry","category-system-administration","tag-bind","tag-isc-bind","tag-named","tag-response-policy-zone","tag-rpz"],"_links":{"self":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/1555","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1555"}],"version-history":[{"count":3,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/1555\/revisions"}],"predecessor-version":[{"id":1560,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/1555\/revisions\/1560"}],"wp:attachment":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1555"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1555"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1555"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}