Response Policy Zone (RPZ), NSIP rules, and nsip-wait-recurse
- Updated on 15 Oct 2018
- 1 minute to read
You, or your security team, want to use RPZ NSIP rules to filter results and provide protection for your users. Unfortunately, there are domains that you need to resolve names for that are served by ill-behaved servers that you are unable to resolve when you use NSIP rules.
One case in which this can happen is when you use a service that maps information into DNS (e.g. email sender reputation) using a period (.) to separate logical chunks of data. Each of the periods in the name forms a potential zone cut (i.e. a place where a delegation to a new set of servers could be placed).
The specification for NSIP rules states that these rules are to be checked against all of the name server IPs responsible for the containing zone and all of its parents. If the server(s) presenting the mapping as DNS does not respond to the NS and SOA queries for all of the potential zone cuts in the name, then named will have to wait for those to time out, and since the servers to query for a particular level will depend on the answers from the parent level, all of these questions must be asked in series. If there is a sufficient number of periods in the mapped name then it may take far longer for a policy decision to be made than the client will wait for an answer.
Starting in BIND 9.11.0 there is a new RPZ option,
nsip-wait-recurse, that directs named to use only what records it already has available (whether in cache or in local authoritative zones) for purposes of determining whether or not there is a match for an NSIP rule.
In the example given above, named wouldn't attempt to look up any records for any of the unused potential zone cuts, and so it would be able to render a match/no-match verdict on the NSIP rule without any delay.