Skip to content

Nuface Blog

隨意隨手記 Casual Notes

Menu
  • Home
  • About
  • Services
  • Blog
  • Contact
  • Privacy Policy
  • Login
Menu

Understanding “network unreachable resolving ‘./NS/IN’” Messages in BIND9

Posted on 2025-11-052025-11-05 by Rico

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/IN query refers to the root DNS namespace.
  • Addresses such as 2001:500:1::53 and 2001:7fe::53 are 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.


Recent Posts

  • Postfix + Let’s Encrypt + BIND9 + DANE Fully Automated TLSA Update Guide
  • Postfix + Let’s Encrypt + BIND9 + DANE TLSA 指紋自動更新完整教學
  • Deploying DANE in Postfix
  • 如何在 Postfix 中部署 DANE
  • DANE: DNSSEC-Based TLS Protection

Recent Comments

  1. Building a Complete Enterprise-Grade Mail System (Overview) - Nuface Blog on High Availability Architecture, Failover, GeoDNS, Monitoring, and Email Abuse Automation (SOAR)
  2. Building a Complete Enterprise-Grade Mail System (Overview) - Nuface Blog on MariaDB + PostfixAdmin: The Core of Virtual Domain & Mailbox Management
  3. Building a Complete Enterprise-Grade Mail System (Overview) - Nuface Blog on Daily Operations, Monitoring, and Performance Tuning for an Enterprise Mail System
  4. Building a Complete Enterprise-Grade Mail System (Overview) - Nuface Blog on Final Chapter: Complete Troubleshooting Guide & Frequently Asked Questions (FAQ)
  5. Building a Complete Enterprise-Grade Mail System (Overview) - Nuface Blog on Network Architecture, DNS Configuration, TLS Design, and Postfix/Dovecot SNI Explained

Archives

  • December 2025
  • November 2025
  • October 2025

Categories

  • AI
  • Apache
  • Cybersecurity
  • Database
  • DNS
  • Docker
  • Fail2Ban
  • FileSystem
  • Firewall
  • Linux
  • LLM
  • Mail
  • N8N
  • OpenLdap
  • OPNsense
  • PHP
  • QoS
  • Samba
  • Switch
  • Virtualization
  • VPN
  • WordPress
© 2025 Nuface Blog | Powered by Superbs Personal Blog theme