Exempting broken domains in recursion

Overview

When BIND is used as a recursive resolver, a domain name may fail to resolve under some configurations, but not others. Resolver operators who wish to exempt individual zones from the resolver’s configuration and query with a configuration which can resolve the domain name may use the multi-view configuration described in this article.

Multi-view configuration

The solution uses two views: the first that is used to query most domain names, and a second that queries for zones containing domain names which the first view's configuration cannot resolve.

The first view uses forwarding statements for each exempted zone. Queries for domain names in each exempted zone are forwarded to the second view. The forwarder statement sends these queries to a loopback IP address, such as 127.0.0.1, on which the second view is configured to listen.

The second view's configuration disables the functionality that breaks domain name resolution with the first view's configuration. For example, when the first view uses QNAME minimization (qname-minimization strict; statement) and a domain fails to resolve due to incorrect authoritative name server configuration, the second view would disable QNAME minimization (qname-minimization off;) or uses QNAME minimization in relaxed mode (qname-minimization relaxed;). Another example: the second view disables DNS cookies (send-cookie false) for authoritative name servers that do not properly handle them.

Multi-view configuration template

Below is a template BIND configuration file illustrating the two-view technique using pseudo-code, with inline comments explaining the purpose of each section of the template. Consider using similar comments in your configuration for readability and maintainability.

Note that this template is not a working configuration file.

view_one {

// Place standard configuration statements here.
// Additions to view_one should normally also be
// added to view_two.

statement1
statement2
statement3

...

// Add forwarder zone statements for domain names which fail resolution.
// Recommend using comments to indicate domain(s) and reason(s) for failure.

zone "badzone1.example" {	// www.badzone1.example fails to resolve due to <reason>

  type forward;
  forwarders { 127.0.0.1; };

  };

zone "badzone2.example" {	// Domains in badzone2.example fail to resolve due to <reason>

  type forward;
  forwarders { 127.0.0.1; };

  };

} // End view_one

view_two {

// Options needed for this view to run as a recursor on a looback interface.

	options {

		recursion yes;					// Turns on recursion	
		listen-on {127.0.0.1};			// Listen only on loopback for incoming queries
		match-clients { 127.0.0.1/32;};	// Only allow queries w/loopback source address 

	}

// The standard configuration, minus the statements in view_one
// that are incompatible with resolution for the forwarded zones

statement1
statement2
statement3

...

// Configuration specific to this view, including statements with
// the same keyword but different values than those in view_one.

statement4
statement5
statement6

...

} // End view_two

Zone and view statements

BIND requires that all zone statements be included in a view statement block. When no views are explicitly defined, BIND implicitly creates a default view. However, when an explicit view is created with a view statement, the default view is removed. Therefore, the statements creating forwarding zones which forward to a view must themselves be contained in a view. In the above template, this is why configuration statements must be enclosed in view_one. If a configuration is attempted with no enclosing view, BIND will log a start-up error indicating:

when using 'view' statements, all zones must be in views

Optional configuration statements

The loopback view ("view_two") may not require certain configurations found in the view "view_one". For example, any forwarder zones created for other reasons than zone exemptions will typically not be duplicated in the loopback view. Another example: in many environments view_two may not need private or reserved IP address reverse mapping zone files because these zones should not be forwarded to view_two, so view_two might contain a empty-zones-enable no; statement. Review your standard configuration to determine whether any statements can be omitted from or deactivated within the loopback view. Removal of unneeded statements will improve maintainability and security.

Additional details

The multiple view approach adds size and complexity to a BIND configuration. The size essentially doubles, and configuration added to the first view typically requires duplication in the or more loopback views. Consider the issues listed below when deciding whether to implement a multi-view configuration for exempting domains which fail resolution.

Multiple exemption loopback views

If domain name resolution in different zones fails for different reasons, the resolver administrator will need to decide if one loopback view (in the above example, view_two) should process all of the zones with resolution failures, or use multiple loopback views—each processing a subset of zones with a common reason(s) for resolution failure (e.g. creation of a "view_two", "view_three" and so on). If using multiple loopback views, forwarding from view_one would then use different values for the forwarders statements.

As an example of using multiple loopback views, view_one could forward certain zones to a view which does not perform QNAME minimization and is configured to listen on loopback IP address 127.0.0.1, and forward other zones to a view which does not use DNS cookies and is configured to listen on loopback IP address 127.0.0.2. Alternatively, the same IP address could be used and different port numbers could distinguish the views. Note that a zone which had multiple reasons for resolution failure (e.g. failure due to QNAME minimization and DNS cookies) would require a view to handle both, simultaneously.

Alias resource records

A domain name which fails resolution under certain configurations may otherwise resolve to a CNAME, DNAME or ANAME record. If the domain name in the RDATA is not within the same zone as the failing domain name (or within a child zone) then the RDATA’s domain name could fail to resolve as well, and require its own exemption. When adding an exemption with this technique, check the full resolution chain to ensure no CNAME, DNAME or ANAME records exist which could cause resolution failure.

For example, if the domain name www.foo.bar.example fails to resolve because the bar.example zone does not properly respond to minimized queries, and www.foo.bar.example is a CNAME record for www.foo.bar.gslb.mycdn.example, then ensure that www.foo.bar.gslb.mycdn.example resolves using the standard configuration. If this domain name also fails to resolve with the standard configuration because the mycdn.example zone also does not properly respond to minimized queries, then two forward zone statements are required, one for the bar.example zone and one for the mycdn.example zone.