DNS Response Policy Zones (DNS RPZ) is a method that allows a name server to be configured with information on top of the global DNS to provide alternate responses to queries.

One of the original purposes for DNS RPZ was to provide "DNS Firewall" capabilities. DNS RPZ was originally created to protect internet users from an ever-expanding list of threats, exploits, and attacks. While DNS RPZ excels at providing users protection, it also provides ancillary benefits and can be used to serve a wide variety of other use cases. Here are a few:

1. DevOps
2. Static NAT
3. Split Horizon DNS environments
4. Business Continuity Processing
5. Domain Name Hijack
6. Selective Filtering

DevOps

DevOps means a lot of things, but as part of my own business, DevOps is the development lifecycle process when building software, i.e. develop, test, stage, and eventually move to production. Development usually always takes place on the localhost, no matter if you are an independent developer or a member of a team of developers. So, one way I leverage DNS RPZ is to put in two (2) simple rules into my environment:

*.dev.local.rpz.            A   127.0.0.1
*.test.local.rpz.           A   127.0.0.1

This means any FQDN ending in either .dev or .test will ALWAYS resolve to 127.0.0.1 or the localhost.

dig my-project-example.test +short
127.0.0.1

In addition, if there is a need to develop a web or tool for a customer, I am able to easily insert the site into my local RPZ zone and override what the public DNS might return.

Example:

ibm.com.local.rpz.        A  192.168.80.80

I can now develop locally using https://ibm.test which will resolve to localhost or 127.0.0.1. The above rule allows me to stage https://ibm.com on an internal only web server, effectively overwriting what the Internet's real response to ibm.com would be.

This is quite HANDY!

Static NAT scenario

I have implemented local DNS RPZ zone(s) to handle Merger and Acquisitions or M&A situations where two (2) companies combine networks, that have duplicated address space. Bi-directional DNS forwarding can be set up in a DMZ where the networks of the two firms are joined. A local RPZ zone can be used to create alternate DNS responses for those hosts that reside on duplicated IP space and that are statically NAT'ed.

The process for constructing the NAT, firewall rule(s), and DNS records can be tied together and helps document the network as the M&A activity takes place.

The above figure depicts a pair of companies ABC and XYZ that are merging. They have constructed a DMZ network connection between them, and set up static Network Address Translation or NAT for all overlapping IP Addresses. Additionally, they have set up a special name server that performs bi-directional forwarding to the internal corporate name servers. The DMZ DNS server also has a local DNS RPZ configured with static RPZ entries that coincide with the NAT entries.

Example:

1. A workstation, somehost.xyz.com initiates a DNS query for host01.abc.com
2. The XYZ name server is configured to forward queries for abc.com to the DMZ name server
3. The DMZ name server is configured to perform bi-directional forwarding to the respective name severs in XYZ and ABC, and the ABC name server responds with the following response:

   host01.abc.com.  A  10.10.10.10
   

4. The DMZ DNS server overrides this by replying with:

   host01.abc.com.local.rpz.  A 172.16.10.10
   

5. The client attempts to establish a connection to 172.16.10.10 (NAT address) - The firewall and NAT make the translation and forward the connection to host01.abc.com using the translated address of 10.10.10.10
6. Likewise, a client within Company ABC, queries its local name server for host01.abc.com which replies with the real inside address of 10.10.10.10.
7. The client then connects to the internal host01.abc.com at 10.10.10.10

Split Horizon DNS

Split-horizon DNS, sometimes referred to as split-brain, split-view, or more simply split-dns, is when entities utilize the same domain name(s) in more than one environment, such as internal private vs. external public-facing. In BIND, DNS Views are normally used to accomplish this, and the two (2) views are managed mutually exclusive of one another. While they may contain some data that is duplicated, most of the data is inherently different.

In my organization, I leverage a local DNS RPZ zone to avoid having to manage Split-Horizon DNS. Go-Daddy hosts my publicly available DNSSEC signed authoritative zone, ddiguru.com. Internally, my name servers are configured with ddiguru.com as well, but using a stub zone. This essentially brings a "copy" of it internally on my business and lab networks. While a stub zone is non-writable i.e. read-only, I am able to override any DNS record in my zone using a local DNS RPZ zone. For example, I am able to overwrite the A record for my email server with an RFC 1918 private address, which allows me to send mail direct internally without doing hairpin NAT. People on the Internet, will resolve my email sever to it's public IP, while I resolve it to my internal IP.

This gives me the ability to have a superset of DNS records without having to fully manage the same name space internally. Using a local DNS RPZ rules, I'm able to do one of the following:

1. Add a net-new DNS record to my ddiguru.com domain (resolved internally)
2. Add a DNS record for a domain name that exists externally that resolves to a different value (internally)

Business Continuity Process (BCP)

A business that performs site Disaster Recovery or DR for its Business Continuity Process or BCP, could leverage a special local.rpz zone using very short TTLs, and simply effect the BCP test using insertion of DR records into the local.rpz zone, and remove them when done. There are a couple of advantages of doing this for BCP or DR testing:

• Less work - production DNS records could remain "as is" without making any modifications to them i.e. leave them in their "steady state"
• Fast to implement - the change would be quickly implemented because of DNS RPZ response processing precedence
• Scope - Focused control of the change because you would handle the entire BCP change in one particular batch or zone
• Fast rollback - quick removal of the records and very low TTLs would mean fast rollback
• Visibility - you could get logging and auditing out of client RPZ hits that would be visible in DNS logs

DNS Record Hijack

I'm not sure I like the title of this use case, because it connotes something bad. But, if you ever need to take over a DNS domain name for your enterprise that you don't own (or authoritative for), you can do so with a local DNS RPZ rule. Suppose you wanted to configure your own Linux RPM repository, and wanted to use the public domain name that distribution XYZ uses. A local DNS RPZ rule would allow you to override xyz-repo.com with your own internal IP Address(es).

Selective Filtering

Lastly, I have used a local DNS RPZ rule set to selectively filter an RRSET for a given domain name. Suppose, for example, you have an Active Directory environment, xyz.com that contains a dozen Active Domain Controllers. Your internal DNS normally advertises ALL of the AD domain Controller records:

xyz.com.      A  10.1.1.100
xyz.com.      A  10.1.1.101
xyz.com.      A  10.2.1.100
xyz.com.      A  10.2.1.101
xyz.com.      A  10.3.1.100
xyz.com.      A  10.3.1.101
xyz.com.      A  10.4.1.100
xyz.com.      A  10.4.1.101
xyz.com.      A  10.5.1.100
xyz.com.      A  10.5.1.101
xyz.com.      A  10.6.1.100
xyz.com.      A  10.6.1.101

Let's suppose that for some reason, there is a secure DMZ that needs Active Directory access, but there is only visibility to one of the network pairs of servers (10.6.1.100 and 10.6.1.101). Let's assume that this limitation has no workaround either. When they query the DNS normally, they will get back the full compliment of DNS records. The Active Directory experience would be massively degraded, since they only have reach-ability to 2 of the 12. There would be significant latency and timeouts galore!

Enter our local DNS RPZ rules. We could potentially filter out the ten (10) AD Domain Controllers by configuring a name server for this special security zone using the following local DNS RPZ set of rules:

xyz.com.local.rpz.      A  10.6.1.100
xyz.com.local.rpz.      A  10.6.1.101

This would address the A records, but to fully handle Active Directory, you would have to create rules for all the other CNAME and SRV records (see the %systemroot%\system32\Config\netlogon.dns file). This would filter out all those records (without actually removing them) that were otherwise unreachable.

Conclusion

In final, I know these are wildly non-traditional uses of RPZ, but I have to say - it often works and works well in situations like these. I know they serve my own needs well, and I've seen it work in large enterprise settings as well. Give local DNS RPZ rules a try!