Course contentsShow
← Linux
Lesson 1528 of 1,81913. Containerization Primitives and NamespacesFree lesson

DNS Resolution in Namespaced Environments

Configuring per-namespace resolver settings without modifying host configuration files.

In this lesson, you will learn how to provide unique DNS resolution settings to individual network namespaces without altering the /etc/resolv.conf file on your host machine.

The Problem: Host File Centralization

By default, the glibc resolver looks at /etc/resolv.conf to determine how to resolve domain names. In a containerized or namespaced environment, you often want isolated services to use internal DNS caches (like CoreDNS) or specific upstream resolvers. If you rely strictly on the host's /etc/resolv.conf, every namespace inherits the host's configuration, which creates a significant bottleneck and a lack of isolation.

The Solution: Mount Namespaces and Bind Mounts

The key to decoupling resolver settings is leveraging the Mount Namespace alongside the Network Namespace. Because every process sees its own filesystem tree, you can "shadow" the system-wide resolver file by mounting a custom version over the standard path inside the target namespace.

If you are already inside a namespace, you can point your resolver to a specific file using a bind mount. This effectively masks the global file without affecting the host or other namespaces:

# 1. Create a custom resolver file
echo "nameserver 10.0.0.5" > /tmp/custom_resolv.conf

# 2. Bind mount the custom file over the standard location inside the namespace
# This must be done while inside the target mount namespace
mount --bind /tmp/custom_resolv.conf /etc/resolv.conf

Why This Works

When your application calls getaddrinfo() or similar resolver functions, the glibc library opens /etc/resolv.conf. Because of the mount namespace isolation, the process is redirected to your custom file instead of the host’s file.

This approach is highly robust because it requires no coordination with the host's network management daemon (like systemd-resolved or NetworkManager). It treats the resolver configuration as a piece of "per-container state," mirroring the way container runtimes initialize isolated filesystems. By combining this with the network namespace primitives we’ve previously discussed, you can build fully autonomous network environments where each namespace manages its own traffic path and name resolution strategy independently.

Key Takeaway: By utilizing bind mounts within a dedicated mount namespace, you can inject custom resolver configurations into isolated environments, overriding the host’s /etc/resolv.conf without side effects.