BIND 9.9 redirect zones (for NXDOMAIN redirection)
  • 17 Sep 2018
  • 2 Minutes to read
  • Contributors
  • Dark
  • PDF

BIND 9.9 redirect zones (for NXDOMAIN redirection)

  • Dark
  • PDF

The ability to configure a redirect zone was first introduced in BIND 9.9.0. (BIND 9 Subscription Version and BIND 9.10 extend this by allowing BIND to provide responses based upon an API to an external user-developed module - for example, DLZ or a coded back-end. For more details, see NXDOMAIN Redirection Using DLZ in BIND 9.10 and later.)

What is NXDOMAIN Redirection?

NXDOMAIN redirection provides the ability for a recursive server to replace an NXDOMAIN response to a query with a configured answer of its own - usually pointing to a helpful service site. This substitute response is returned to the original client in place of the NXDOMAIN response received by the server.  Recursive server administrators may use this redirection for their own purposes or to obtain advertising revenue from third parties who specialize in this business. 

NXDOMAIN Redirection will not override DNSSEC.
If the client has requested DNSSEC records (DO=1) and the NXDOMAIN response is signed then no substitution will occur.

How is NXDOMAIN Redirection configured?

Running BIND 9.11?
BIND 9.11 releases have an additional method, 'nxdomain-redirect', for accomplishing the same basic idea but with different trade-offs and requirements.  Consult the ARM for your BIND release to see information on configuration and usage.

The zone data within such a zone will often consist of a pair of (A and AAAA)  wildcard records for root, but it's also possible to add records specifically for different domains. 

The substitution supports all possible types and is not limited to A and AAAA records; any record type may be placed in a redirect zone.

For example, this would be a standard redirect zone configuration from named.conf:

zone "." {
     type redirect;
     file "db.redirect" ;

To redirect any A or AAAA queries to and 2001:ffff:ffff:: on NXDOMAIN, you would configure the redirect zone like this.

$TTL 300
@ IN SOA 0 0 0 0 0
; NS records do not need address records in this zone as it is not in the
; normal namespace.
*. IN A
*. IN AAAA 2001:ffff:ffff::

To redirect all Spanish names (under .ES) use entries like these:

*.ES. IN A
*.ES. IN AAAA 2001:ffff:ffff::

Similarly, to redirect all commercial Spanish names (under COM.ES) create entries like these:

*.COM.ES. IN AAAA 2001:ffff:ffff::

The redirect zone can also hold redirect records for multiple different domains. If the above examples were added to the same redirect zone together, then the most specific matching redirect would be used when forming a query response.