BIND essentially choked because it found two different zone definitions for the same zone name (. in this case, the root zone) but within different view blocks. BIND can’t decide which one to use, so it throws its hands up and refuses to load.
Here are the common reasons this happens and how to fix them:
1. Accidental Duplicate Root Zone Definition
This is the most frequent culprit. You might have a named.conf file that looks something like this:
options {
directory "/var/named";
recursion yes;
};
acl "trusted" { 192.168.1.0/24; };
view "internal" {
match-clients { trusted; };
zone "." IN {
type hint;
file "named.ca";
};
};
view "external" {
match-clients { any; };
zone "." IN {
type hint;
file "named.ca"; // Oops! Duplicate definition
};
};
Diagnosis: Carefully examine your named.conf and any included files (named.conf.local, named.conf.options, etc.) for multiple zone "." IN { ... }; stanzas.
Fix: Remove all but one instance of the zone "." IN { type hint; file "named.ca"; }; definition. BIND only needs one root hints zone, and it’s typically defined in the global options block or a single view. If you have views, ensure the root zone is defined only once, preferably in the view that matches most clients or in the global options if it’s common to all views.
Why it works: BIND processes configuration files sequentially. When it encounters the second identical zone "." IN { ... } definition, it flags it as an error because it has already registered a zone with that name and type. Removing the duplicate ensures only one authoritative definition exists.
2. Incorrectly Defined Global Root Hints Zone
Sometimes, you might intend to define the root hints zone globally but accidentally put it inside a view block, and then also have another definition (perhaps in another view or globally).
options {
directory "/var/named";
recursion yes;
// Intended global root hints
zone "." IN {
type hint;
file "named.ca";
};
};
view "internal" {
match-clients { trusted; };
// Accidentally duplicated here
zone "." IN {
type hint;
file "named.ca";
};
};
Diagnosis: Check your options block for a zone "." IN { type hint; ... }; definition. Then, check all your view blocks for the same definition.
Fix: If you have a root hints zone defined in the global options, remove any identical definitions from within view blocks. If you want the root hints zone to be specific to a view, remove it from the global options and define it only in that specific view.
Why it works: A zone defined in the global options is usually applied to all views unless explicitly overridden. If you then define it again within a view, BIND sees two definitions for the same zone name, leading to the error.
3. Copy-Paste Errors When Merging Zone Files or Configurations
When migrating or updating configurations, it’s common to copy blocks of text. If you’re not careful, you might end up with duplicate zone definitions.
Diagnosis: Use a text editor with search capabilities or command-line tools like grep to find all occurrences of zone "." IN { in your BIND configuration directory (e.g., /etc/bind/, /etc/named/).
Fix: Manually review each instance found. If you’re using views, ensure the root hints zone (zone "." IN { type hint; ... };) appears only once in the configuration that applies to the relevant view. If it’s meant to be global, it should be outside any view block.
Why it works: This is purely about correcting erroneous configuration syntax. By finding and removing the duplicated zone definition, you eliminate the ambiguity BIND faces.
4. Using include Statements Incorrectly
If you use include statements to split your configuration, you might inadvertently include the same zone definition file or block multiple times.
// named.conf
options { ... };
include "/etc/bind/named.conf.views";
include "/etc/bind/named.conf.local"; // Might contain a root zone definition
And then in /etc/bind/named.conf.views:
view "internal" {
match-clients { trusted; };
zone "." IN {
type hint;
file "named.ca";
};
};
And in /etc/bind/named.conf.local:
zone "." IN {
type hint;
file "named.ca";
};
Diagnosis: Trace all your include statements. Examine the files being included to see if any of them contain a definition for zone "." IN { ... }.
Fix: Consolidate the root hints zone definition. Either place it in a single file that is included only once, or define it directly in named.conf (or named.conf.options) outside any view, ensuring it’s not duplicated elsewhere.
Why it works: include directives are processed as if the content of the included file were directly pasted into the main configuration file. Multiple includes of the same zone definition will result in duplicate entries, just as if they were written directly.
5. Complex View Logic Leading to Overlapping Definitions
In very complex configurations with many views, it’s possible for a zone definition to be implicitly or explicitly applied to multiple views in a way that BIND interprets as a duplicate. This is less common for the root zone itself but can happen.
Diagnosis: This requires a deep dive into your view definitions. Use named-checkconf -p (or named-checkconf -v if available and you want verbose output) to ensure the syntax is correct. Then, manually trace which views match which clients and which zones are defined or inherited by each view.
Fix: Refine your view match-clients and match-destinations clauses to ensure that a zone is only defined once for the set of clients and destinations that will use it. If the root hints zone is intended for all clients, define it once globally or in a single view that matches all clients.
Why it works: BIND builds an internal representation of all zones and their visibility per view. If, after processing all configurations, it finds two distinct definitions for the same zone name that are active for the same logical "view context," it errors. Cleaning up the view matching logic ensures each zone is uniquely associated.
6. Using file for a Zone That Should Be master or slave
While less likely to cause a "multiple default zones" error specifically for the root zone (which is always a hint), this can manifest as similar issues if you’re misconfiguring other zones and trying to apply views. The root zone is special.
Diagnosis: Ensure that your zone "." IN { ... }; stanza correctly uses type hint;. If you were trying to define a different zone (e.g., your local domain) and accidentally used type hint; or type master; incorrectly within a view, it might lead to confusion.
Fix: For the root zone, the definition must be:
zone "." IN {
type hint;
file "named.ca"; // Or the actual path to your root hints file
};
Ensure type hint is used, and the file points to the correct root hints file (usually provided by your OS distribution).
Why it works: The type hint directive tells BIND this is a special zone for resolving root DNS servers. Misusing type master or type slave for the root zone would be a configuration error, though usually resulting in a different error message. This fix ensures the root zone is declared with its correct, unique type.
After fixing any of these issues, run named-checkconf to validate your configuration syntax and then restart BIND (e.g., sudo systemctl restart named or sudo systemctl restart bind9).
The next error you’ll likely encounter if you’ve only fixed this specific issue is a notification that BIND is not serving authoritative data for your local network, or that it’s not forwarding queries correctly if you intended it to do so.