Chapter 9. HOWTO redirect zones
This howto deals with the difficult topic of zone redirection. Since BIN9.8 ISC has developed and released at least three methods of redirecting zones. Whether this is a Good Thing ™ or not is beside the point. The techniques are out there ready to be used. The trend discernable is to assume that the user will increasingly need to control the environment (in a potentially draconian manner) rather than simply react as at present. The next stage clearly is to make this a completely dynamic real-time process (already anticipated with rndc enhancements, DLZ and BIND10). This page summarises the current techniques and points to further reading and configuration examples:
Response Policy Zone (RPZ) is a major new technology to control the behavior of recursive servers under multiple conditions. This page configures RPZ as a zone blocking (firewall) service which operationally may consist of potentially millions of zone records. There is a constant demand from educational establishments and even businesses wishing to implement such a blocking service both to reduce legal exposure and to reduce time-wasting. Using BIND, prior to RPZ, a configuration file consisting of individual zone definitions (in some cases whole TLDs could be taken out) using type forward; (this uses the smallest BIND memory footprint) was the only answer. RPZ will do the same job, with equally flexible control at perhaps 30% (estimated) of the memory usage. While the file will likely be quite dynamic using one of the binary zone formats will speed up load times of huge zone files. It makes this type of DNS firewall technology viable. RPZ makes solution design relatively complex (partly due to the sheer flexibility offered - just how many ways are there to skin a cat) but maintenance costs are thereafter low. Depending on how the system is designed and implemented it may even offer either a pure business opportunity or at least the ability of affinity groups, such as educational establishments, to share blocked zone lists with relative ease using standard zone transfer technology.
Historically, type stub; zones were simply a method of configuring a delegation only zone file. Just a tad on the exotic, if not weird, side outside of very limited conditions. BIND9.8 introduced type static-stub; zones. This feature allows the user to define the destination (using a simple referral typically) of any zone. Imaginative readers may spot other possibilities. There is no limit to the number or scope (zone "."?) of type static-stub; zones.
BIND9.9 introduced a type redirect; zone which allows the user to modify the behavior of any NXDOMAIN response (except from a signed zone) by substituting an almost unlimited set of actions defined using a normal zone file. The zone file is not visible in any normal sense (it cannot be queried, zone transferred or manipulated by rndc) but a lookup of this zone is triggered on the recursive server's receipt of NXDOMAIN. There is a limit, currently, of one type redirect; per named.conf or where view clauses are being used one type redirect; per view. There is no limit to the scope of the allowed zone file ("."?). The range of poosibilities here is enormous. And we have no imagination.
Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.
