As a fellow BIND administrator, I've encountered the same dilemma you're facing. The choice between /etc/bind/zones/
and /var/cache/bind/
isn't just about personal preference - it's about understanding BIND's architecture and Linux filesystem conventions.
In Debian/Ubuntu installations, BIND typically defaults to:
options {
directory "/var/cache/bind";
...
}
This configuration serves multiple purposes:
- Stores runtime files (like pid, journal files, and dynamic zone data)
- Acts as the default base directory for relative paths in zone declarations
Many administrators prefer creating a dedicated /etc/bind/zones/
directory for several reasons:
zone "example.com" {
type master;
file "/etc/bind/zones/db.example.com"; // Absolute path
};
Advantages of this approach:
- Clear separation between configuration (static zone files) and runtime data
- Easier backup management (only /etc/bind needs backup)
- More intuitive organization for human administrators
The directory
option in named.conf serves multiple purposes:
options {
directory "/var/cache/bind"; // Default working directory
...
}
This affects:
- Relative path resolution for zone files
- Location of runtime files (pid, managed-keys, etc.)
- Default location for dynamic zone files
Based on production experience, I recommend this hybrid approach:
options {
directory "/var/cache/bind"; // Keep default working directory
};
zone "example.com" {
type master;
file "/etc/bind/zones/db.example.com"; // Use absolute path
};
Key benefits:
- Static zone files remain in version-controlled /etc
- Runtime files stay in their designated /var location
- Clear separation of concerns
Here's a complete setup example for a Debian system:
# Directory structure
sudo mkdir -p /etc/bind/zones
sudo chown bind:bind /etc/bind/zones
sudo chmod 755 /etc/bind/zones
# named.conf.options
options {
directory "/var/cache/bind";
allow-recursion { any; };
recursion yes;
...
};
# named.conf.local
zone "example.com" {
type master;
file "/etc/bind/zones/db.example.com";
allow-transfer { secondary-ns-ip; };
};
Regardless of location choice, ensure proper permissions:
sudo chown bind:bind /etc/bind/zones/*
sudo chmod 644 /etc/bind/zones/*
For dynamic zones in /var/cache/bind:
sudo chown bind:bind /var/cache/bind
sudo chmod 755 /var/cache/bind
While the location itself doesn't significantly impact performance, consider:
- /etc typically resides on root partition (often SSD)
- /var might be on separate partition (possibly HDD)
- For high-traffic DNS servers, ensure /var is on fast storage
After managing multiple BIND installations across different Linux distributions, I've noticed persistent confusion about zone file locations. Let's clarify the technical distinctions between these directories and their implications for DNS administration.
The Filesystem Hierarchy Standard provides clear guidance:
/etc/bind/ - Configuration files (named.conf, etc.)
/var/cache/bind/ - Runtime files and dynamically updated zones
/var/lib/bind/ - Alternative for slave zone files and journal files
For master zones that you manually maintain:
zone "example.com" {
type master;
file "/etc/bind/zones/db.example.com";
allow-transfer { 192.168.1.2; };
};
For dynamically updated zones or slave zones:
zone "dynamic.example.net" {
type slave;
file "/var/cache/bind/db.dynamic.example.net";
masters { 192.168.1.1; };
};
The directory
option in named.conf
serves multiple purposes:
options {
directory "/var/cache/bind"; // Default working directory
// Other options...
};
This setting affects:
- Relative path resolution for zone files
- Location of PID file (named.pid)
- Default directory for dynamically created files
Consider these permission setups:
# For /etc/bind/zones:
chown root:bind /etc/bind/zones
chmod 750 /etc/bind/zones
# For /var/cache/bind:
chown bind:bind /var/cache/bind
chmod 770 /var/cache/bind
When dealing with large zone files or frequent updates:
// For high-performance setups:
options {
directory "/var/cache/bind";
max-cache-size 256M;
// Additional performance tweaks...
};
zone "large-domain.com" {
type master;
file "/var/cache/bind/db.large-domain.com";
journal "/var/cache/bind/db.large-domain.com.jnl";
};
After extensive testing across Debian, Ubuntu, and RHEL systems, I recommend:
- Use
/etc/bind/zones/
for manually maintained master zones - Reserve
/var/cache/bind/
for: - Slave zone files
- Dynamically updated zones
- Journal files
- Maintain the default working directory (
/var/cache/bind
)
This approach maintains FHS compliance while optimizing for both security and operational efficiency.