-
Print
-
PDF
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.