When managing a DNS server such as BIND9, you might notice repeated messages like these in your lame-servers.log or system log:
03-Sep-2025 10:51:51.443 network unreachable resolving './NS/IN': 2001:500:1::53#53
03-Sep-2025 10:51:51.443 network unreachable resolving './NS/IN': 2801:1b8:10::b#53
03-Sep-2025 10:51:51.443 network unreachable resolving './NS/IN': 2001:7fe::53#53
03-Sep-2025 10:51:51.443 network unreachable resolving './NS/IN': 2001:503:c27::2:30#53
At first glance, these may look like DNS errors.
In reality, they are harmless IPv6 connectivity warnings, not signs of malfunction.
🔍 Why These Messages Appear
When BIND performs recursive queries, it tries to contact root DNS servers via both IPv4 and IPv6.
If your host or Docker container does not have IPv6 enabled or a default IPv6 route, BIND’s attempts to reach IPv6 root servers (e.g., 2001:500:1::53) will fail, resulting in messages like:
network unreachable resolving './NS/IN'
👉 Simply put:
BIND is notifying you that IPv6 is unreachable, but IPv4 resolution still works perfectly fine.
✅ Solutions (Choose One)
Option A — Force BIND to Use IPv4 Only (Recommended for IPv4-only Environments)
If your environment doesn’t need IPv6, the easiest fix is to start BIND with the -4 flag.
Here’s an example based on your original startup script:
docker run \
-d -4 \
--name=bind9 \
--restart=always \
-p 53:53/udp \
-p 53:53/tcp \
-v /data/docker/dnssys/bind9.9.21/config:/etc/bind \
-v /data/docker/dnssys/bind9.9.21/cache:/var/cache/bind \
-v /data/docker/dnssys/bind9.9.21/log:/var/log/bind \
-v /etc/localtime:/etc/localtime:ro \
-v /etc/timezone:/etc/timezone:ro \
internetsystemsconsortium/bind9:9.21
That placement of -4 is incorrect — Docker interprets it as its own flag.
It must come after the image name so that it’s passed to named inside the container.
✅ Correct version:
docker run \
-d \
--name=bind9 \
--restart=always \
-p 53:53/udp \
-p 53:53/tcp \
-v /data/docker/dnssys/bind9.9.21/config:/etc/bind \
-v /data/docker/dnssys/bind9.9.21/cache:/var/cache/bind \
-v /data/docker/dnssys/bind9.9.21/log:/var/log/bind \
-v /etc/localtime:/etc/localtime:ro \
-v /etc/timezone:/etc/timezone:ro \
internetsystemsconsortium/bind9:9.21 \
-4 -f
-4→ forces BIND to use IPv4 only-f→ runs the process in the foreground (required for most official BIND Docker images)
✅ Pros: Simple and effective — eliminates IPv6 unreachable warnings immediately.
⚠️ Cons: Disables IPv6 completely.
Option B — Enable IPv6 Networking in Docker
If you want BIND to support both IPv4 and IPv6, enable IPv6 in your Docker environment.
Edit /etc/docker/daemon.json:
{
"ipv6": true,
"fixed-cidr-v6": "fd00:dead:beef::/64"
}
Then restart Docker:
sudo systemctl restart docker
Check IPv6 connectivity inside the container:
ping6 2001:4860:4860::8888
✅ Pros: Full dual-stack (IPv4 + IPv6) support.
⚠️ Cons: Requires proper IPv6 routing and firewall configuration.
Option C — Suppress These Messages (Not Recommended)
If you just want to hide these logs without changing network behavior, you can adjust the logging configuration in named.conf:
logging {
channel null_chan { null; };
category lame-servers { null_chan; };
// category resolver { null_chan; }; // Uncomment if needed
};
✅ Pros: Stops log spam.
⚠️ Cons: Does not actually fix the underlying IPv6 issue.
💡 Additional Notes
- The
./NS/INquery refers to the root DNS namespace. - Addresses such as
2001:500:1::53and2001:7fe::53are IPv6 root server addresses. - If your BIND server is authoritative-only, you can disable recursion with:
recursion no;This prevents BIND from contacting root servers altogether.
🔚 Conclusion
The “network unreachable resolving './NS/IN'” messages simply indicate that your system doesn’t have IPv6 connectivity.
Your DNS server is still fully functional via IPv4.
The easiest and most practical fix is to start BIND with the -4 option.
If you plan to support IPv6, enable it properly at the Docker or host network level.
Either way — your DNS will continue resolving just fine.