If your business continuity depends on full connectivity with another company whose ISP also serves some criminal or abusive customers, it's possible that one or more of your external RPZ providers -- that is, your security feed vendors -- will eventually add some RPZ rules that could hurt your connectivity to your business partner. You can protect yourself from this risk by using an internal RPZ in addition to your external RPZ's, and by putting into your internal RPZ some "pass through" rules to prevent any policy action from affecting a DNS response that involves your business partner.
A recursive DNS server can be connected to more than one RPZ, and these will be searched in order. Therefore to protect yourself from dangerous policies which may some day appear in your external RPZ zones, you should list your internal RPZ zones first.
Within your internal RPZ, you'll need rules describing the network assets of business partners whose communications you need to protect. You will not in general know what domain names they use, but you'll be aware of what address space they have and perhaps what name server names they use.
126.96.36.199.10.rpz-ip CNAME 188.8.131.52.10.
184.108.40.206.128.rpz-nsip CNAME 220.127.116.11.128.
ns.partner1.com.rpz-nsdname CNAME ns.partner1.com.
ns.partner2.com.rpz-nsdname CNAME ns.partner1.com.
Here, we know that answers in address block 10.0.0.0/8 indicate a business partner, as well as answers involving any name server whose address is in the 18.104.22.168/16 address block, and answers involving the name servers whose names are ns.partner1.com or ns.partner2.com.
The above example demonstrates that when matching by answer IP address (the .rpz-ip owner), or by name server IP address (the .rpz-nsip owner) or by name server domain name (the .rpz-nsdname owner), the special RPZ marker (so, .rpz-ip, .rpz-nsip, or .rpz-nsdname) does not appear as part of the CNAME target name.
By triggering these rules using known network assets of a partner, and using the "pass through" policy action, no later RPZ processing (which in the above example means the "rpz.security-vendor-1.com" and "rpz.security-vendor-2.com" policy zones, will have any effect on DNS responses for business partner assets.
See also: Building DNS Firewalls with Response Policy Zones (RPZ)
© 2001-2014 Internet Systems Consortium