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.
220.127.116.11.10.rpz-ip CNAME 18.104.22.168.10.
22.214.171.124.128.rpz-nsip CNAME 126.96.36.199.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 188.8.131.52/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-2017 Internet Systems ConsortiumFor assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.