The Domain Name System (DNS) is the telephone book of the Internet which primarily contains mappings from hostname to IP address. Not only do normal business and individuals use the DNS details for non-criminal entities, DNS also gets used by botnet operators, phishers, advertising & spam networks and other such malicious actors on the Internet. Many people will have a browser-based adblocker like uBlock Origin that in the backend uses hostname based or IP based blocking rules. An adblocker only restricts content in the browser though.

With DNS Response Policy Zones one can not only block, but also change the answer to a DNS query. Any computer program that looks up information in the DNS can be lied to when they use the recursor that is configured with a RPZ feed. Currently both BIND and PowerDNS support RPZ out of the box and only need to be configured to activate this very useful feature.

DNS RPZ – Firewalls for DNS

RPZ allows a myriad of possibilities of changing the answers to queries, the simplest being claiming that the requested label does not exist and thus to return a NXDOMAIN error to the question for certain labels. Another often used feature is to change the response to point the label to an administrator controlled host which typically is a webserver showing a walled garden web interface.

The IETF draft detailing the RPZ protocol has a good set of examples about the usage and ways that RPZ can be configured in the Appendix. Other good resources are the book DNS for Rocket Scientists which has a chapter about RPZ in general and a specific configuring RPZ chapter.

ISC, the maintainers of the DNS server BIND, have a section in their Knowledgebase about RPZ with a lot of information about RPZ configuration and examples.

The canonical example for RPZ is to completely make a domain disappear:

$ORIGIN rpz.example.net.
bad.example	CNAME	.
*.bad.example	CNAME	.

This can be used to block a virus or a botnet or even commit censorship.

To redirect one hostname to another, as a different name is returned:

$ORIGIN rpz.example.net.
evil.example	CNAME	good.example.

Noting of course that for HTTP the Host header has to be ignored or processed properly and for HTTPS a valid certificate has to be presented, which could be accomplished by installing a CA on all the clients and on-the-fly generated certificates as is done by mitmproxy. Most other common protocols rely on the IP address, not on the hostname.

RPZ Feeds

To use RPZ, one either defines a local zone or make use of a RPZ feed. Most RPZ feeds are subscription based services, where after agreeing on compensation a server operator is provided access to a AXFR capable DNS server.

Multiple feeds can be configured, the first match found for a DNS label is what matches and what dictates the result of the query. Configuring your DNS recursor this way will protect yourself from policies that might affect your network.

Distributing RPZ zones

As DNS RPZ zones are in effect normal DNS zones, they can also be distributed using standard DNS techniques. A standard DNS master/slave setup will, when configured as such, automatically forward updates of a DNS RPZ zone using the DNS AXFR/IXFR protocols and thus allowing incremental changes to be efficiently distributed.

RPZ and DNSSEC

As RPZ is a method of lying to the system, DNSSEC does not validate per default. One would have to create a private key and deploy it on all recursors that do DNSSEC validation to be able to lie completely to the system.

This is a good thing in a sense, as a DNSSEC validating recursor cannot be Man-In-The-Middle’d (MITM) with DNS RPZ to change the contents of a zone. As without a properly signed record the validation fails, what one does achieve is that the DNS label, which is faked, does not validate. For most DNSSEC recursor implementations that will result in a SERVFAIL error.

Common RPZ Pitfalls

When using autogenerated or external RPZ feeds, do validate these feeds for their quality, or you might accidentally block something that you did not want to block.

A very important step is to configure a local RPZ that contains a whitelist of domains and IP addresses that one does not want to have influenced. An accidental mistake in a RPZ feed could cause a widespread outage if for instance local domains or domains that are commonly queried are accidentally blocked. See the Feeds section for an example.

As DNS server best practice dictates, do keep authoritative and recursive DNS servers separate. Applying policy from RPZ to an authoritative server might cause unexpected results, especially when they are from RPZ feeds that are not manually audited.

Walled Gardens with RPZ

One common use for RPZ is to build a so called Walled Garden. A Walled Garden in this context is a technique to seclude a host in the network from the Internet. This is typically used to restrict that host from accessing Internet resources when that host has been detected to be performing actions that would negatively affect the network.

For instance, connections to an IP might be detected that is normally used for botnet communications. Or the host is trying to lookup hosts that are part of a Command and Control (C&C) infrastructure. A walled garden can also be used to require authentication from a host before it is allowed to use the rest of the infrastructure.

The Outside the Walled Garden and Inside the Walled Garden figures illustrates this concept. The Outside figure shows the Client A and C normally connected to the green/normal network and as they are connected with the router, they can also forward packets to the Internet. When C asks the RPZ-enabled DNS server for the address of B, the address of the Walled Garden is returned and the VLAN is changed from the normal VLAN to that of the Walled Garden. Client C has moved inside the Walled Garden Network, the IP addresses of the Router, DNS and DHCP servers remain the same, but the only thing it can really talk to is the Walled Garden Server, which will display a message showing what the next steps are.

The Walled Garden is in effect its own network. It has it’s own DHCP server thus ensuring that clients get an IP address. It also has a DNS server that only returns answers that point to the Walled Garden Servers IP address. By using a distinct VLAN we ensure that no traffic can ever reach any other parts of the network. There is no shared DNS/DHCP either, to ensure that there is an accidental data leakage: e.g. one could tunnel through DNS. Technically with a VLAN and own router, DHCP and DNS the client is restricted to the Walled Garden.

To address the case of a known botnet, we enter the hostnames, domain names and/or IP addresses in a RPZ zone and CNAME the destination address to our walled garden server:

$ORIGIN rpz.example.net.
virus.example		CNAME	walled.garden.example.net.
*.virus.example		CNAME	walled.garden.example.net.
42.2.18.198.rpz-ip	CNAME	walled.garden.example.net.
42.zz.db8.2001.rpz-ip	CNAME	walled.garden.example.net.

With these RPZ rules, anything trying to resolve virus.example or any DNS resolution pointing to 198.18.2.42 or 2001:db8::42 will be rewritten to point to the address of walled.garden.example.net.

When the client host now tries to connect to these servers, it will be returned the address of the walled garden server and connect there instead. At this point, one could opt, for HTTP to return a webpage with details about the problem (“You are infected with a virus”) but one could additionally cut off communications towards the Internet or even better: automatically move the host to a separate VLAN which not only disallows communicating with the Internet, but also to the local network, or better said, a VLAN that is the Walled Garden where one can only communicate with the Walled Garden server.

Keeping NTP local with RPZ

Most computer systems are deployed with NTP clients that are per default configured to either time.windows.com for Windows hosts or distro.pool.ntp.org for Linux based systems.

This means that all these systems ask some host somewhere on the Internet what time it is. Especially with pool.ntp.org one does not know what the quality of the time is nor where those hosts are located and what their network quality is. NTP also requires firewalls to be quite wide open while it is known that there are various DoS attacks involving misconfigured DNS servers.

If you have a local (GPS-synced) NTP server, it would of course be better if they used that local time source instead. Next to going through all systems to configure them manually or hoping that the DHCP option 42 takes effect, one could put the well-known system default NTP servers into RPZ:

$ORIGIN rpz.example.net.
time.windows.com	CNAME	ntp.example.net.
pool.ntp.org		CNAME	ntp.example.net.
*.pool.ntp.org		CNAME	ntp.example.net.

And now automatically all clients using this RPZ-enabled DNS server will use the locally defined NTP source of which one knows the quality of the time source.

Restricting circumvention of RPZ

The RPZ configuration is only enabled on the recursive DNS server that it is configured on. If a client uses for instance 8.8.8.8 or 2001:4860:4860::8888 for Google Public DNS, they are not asking DNS queries to the RPZ-enabled DNS recursor anymore and thus will not be lied to anymore. Similarly a client could use a VPN and with that bypass any local restrictions.

This is also why in the Walled Garden example the Walled Garden network is completely separated on L3 from being able to send and receive packets from the Internet, as when one can get a packet in and receive a response back one is able to tunnel out and use that connectivity instead.

Filtering typically won’t block determined people from getting out, hence why complete separation is the only real solution for a Walled Garden.

To ensure that all clients use the local RPZ-enabled DNS recursor one could force all port 53 udp and tcp traffic to go to the local RPZ-enabled DNS recursor. Of course any client using a VPN, tunnel or Tor does not query the local DNS server and thus bypasses also all the rules in RPZ, similarly as they bypass the local firewall rules.

About the Author

Jeroen Massar has been working since the mid 1990s with network technologies. Major topics of work include network protocols, performance, monitoring, anonymity and circumvention of Internet censorship.

Links

• http://www.zytrax.com/books/dns/ch7/rpz.html
• http://www.zytrax.com/books/dns/ch9/rpz.html
• https://deepthought.isc.org/article/AA-00525/110/Building-DNS-Firewalls-with-Response-Policy-Zones-RPZ.html
• https://mitmproxy.org
• https://openvpn.net/
• https://tools.ietf.org/html/draft-ietf-dnsop-dns-rpz-00
• https://www.dnsrpz.info
• https://www.torproject.org/
• https://www.wireguard.com/