BIND’s zone loading process choked because it found a zone file that it believes is already loaded and active in memory.

Common Causes and Fixes

1. Stale named.pid File: The most common culprit is a stale named.pid file left behind by a previous, unclean shutdown of the BIND process. BIND uses this file to track its running instance. If it finds a pid file but no process is actually running, it can get confused.

  • Diagnosis: Check for the existence of the named.pid file in your BIND working directory (often /var/run/named/ or /var/named/).

    ls -l /var/run/named/named.pid
    

    If the file exists, check if a named process is actually running:

    ps aux | grep named
    

    If named.pid exists but no named process is running, this is your problem.

  • Fix: Remove the stale named.pid file and restart BIND.

    rm /var/run/named/named.pid
    systemctl restart named
    

    This works because removing the pid file signals to BIND that there’s no existing instance to conflict with, allowing it to start fresh and create a new pid file.

2. Duplicate Zone Entries in named.conf: You might have accidentally included the same zone definition twice in your named.conf or included configuration files.

  • Diagnosis: Carefully review your named.conf file and any files it includes for duplicate zone stanzas.

    grep -r "zone \".*\"" /etc/named/
    

    Look for identical zone "example.com" { ... }; blocks.

  • Fix: Remove the duplicate zone stanza from your configuration and reload BIND.

    # Example: Remove one of the duplicate zone blocks from /etc/named/named.conf
    # Then reload BIND
    systemctl reload named
    

    This resolves the issue by ensuring BIND only sees a single, definitive configuration for each zone.

3. Incorrect rndc Configuration or State: The rndc utility is used to control the named process. If rndc is misconfigured or its internal state is out of sync with named, it can lead to perceived conflicts.

  • Diagnosis: Check the rndc.key file and the controls section in named.conf to ensure they match. Also, try clearing rndc’s cache.

    # Check rndc.key permissions and content
    ls -l /etc/rndc.key
    cat /etc/rndc.key
    
    # Check named.conf for controls section
    grep -A 5 "controls {" /etc/named/named.conf
    

    Ensure the key and algorithm match between rndc.key and named.conf.

  • Fix: Re-generate rndc.key and update named.conf accordingly, then restart BIND.

    rndc-confgen -a -b 128 > /etc/rndc.key
    # Edit /etc/named/named.conf to use the new key and algorithm
    systemctl restart named
    

    This forces a clean synchronization between the control utility and the BIND server.

4. Corrupted Zone File Syntax: While less common for "Zone Already Exists," a severely malformed zone file might cause BIND to misinterpret its state during loading, especially if it was partially loaded previously.

  • Diagnosis: Use named-checkzone to validate your zone file.

    named-checkzone example.com /var/named/zones/db.example.com
    

    Look for any syntax errors reported by this command.

  • Fix: Correct the syntax errors in the zone file identified by named-checkzone and reload BIND.

    # Correct errors in /var/named/zones/db.example.com
    systemctl reload named
    

    This ensures BIND can parse the zone file correctly without ambiguity.

5. Incorrect Permissions on Zone Files or Directories: BIND needs to read zone files and sometimes write to its working directory. Incorrect permissions can prevent it from properly managing zone states.

  • Diagnosis: Check the ownership and permissions of your zone files and the BIND working directory. The BIND process typically runs as the named user.

    ls -ld /var/named/zones/
    ls -l /var/named/zones/db.example.com
    

    Ensure the named user has read access to zone files and write access to the working directory if BIND needs to create temporary files.

  • Fix: Set appropriate ownership and permissions.

    chown -R named:named /var/named/zones/
    chmod 644 /var/named/zones/db.example.com
    # If BIND needs to write to the directory:
    # chmod 755 /var/named/
    systemctl restart named
    

    This grants BIND the necessary access to read zone data and manage its internal state files.

6. BIND View Configuration Conflicts: If you are using BIND views to serve different zone data to different clients, a misconfiguration within or between views can lead to a zone appearing to exist in multiple contexts, triggering this error.

  • Diagnosis: Examine your named.conf for view stanzas. Ensure that a zone is not defined in more than one view, or if it is, that the conditions for each view are mutually exclusive.

    grep -r "view " /etc/named/
    
  • Fix: Adjust your view definitions to ensure each zone is uniquely assigned to a single view or that view matching logic is correct.

    # Edit /etc/named/named.conf to clarify view definitions
    systemctl reload named
    

    This harmonizes the zone definitions across different client contexts.

The next error you’ll likely encounter if you haven’t fixed the underlying issue is a "client @ #: query (A IN example.com)’ responded with SERVFAIL" or similar query failure.

Want structured learning?

Take the full Dns course →