The "Cannot assign request" error when dnsmasq tries to bind to 172.17.0.1 typically indicates that the port is already in use by another process or that the network interface associated with that IP address is not yet available. This common Linux issue arises during containerized environments or virtual networking setups where port conflicts or timing issues prevent the DNS service from initializing correctly.
Understanding the Error Context
The IP address172.17.0.1 is the default gateway for Docker’s bridge network. When dnsmasq fails to create a listening socket on this specific address, it usually means the service cannot bind to the required UDP or TCP ports (typically 53) because they are occupied or the interface configuration is incomplete. This error prevents dnsmasq from resolving DNS queries within your local network or container ecosystem.
To resolve this, you must identify what is holding the port or why the interface is unavailable. The troubleshooting process involves checking for conflicting services, verifying network interface status, and ensuring proper configuration of the DNS server.
Check for Port Conflicts
The most frequent cause of the "Cannot assign request" error is another process already listening on port 53. Before assuming a network interface issue, verify that no other DNS server or application is using the same port. Use the following command to list all processes listening on port 53:sudo ss -tlnp | grep :53
sudo ss -ulnp | grep :53systemd-resolved, named, or another instance of dnsmasq) is bound to 127.0.0.53:53 or 0.0.0.0:53, this is likely the culprit. In many modern Linux distributions, systemd-resolved acts as a stub resolver on localhost, which can conflict with dnsmasq if both attempt to manage DNS resolution simultaneously.
If a conflicting service is found, you can either stop that service or reconfigure dnsmasq to listen on a different interface or port. For example, if systemd-resolved is the conflict, ensure your /etc/resolv.conf points to 127.0.0.53 instead of trying to run a full dnsmasq instance on the same stack unless specifically required.
Verify Network Interface Availability
Since172.17.0.1 is tied to the docker0 bridge interface, the error may occur if dnsmasq starts before Docker has fully initialized the network bridge. If the interface does not exist or lacks the IP address when dnsmasq attempts to bind, the kernel will reject the request.
Check the status of the docker0 interface:
ip addr show docker0inet 172.17.0.1/16. If this IP is missing, Docker has not created the bridge yet. This is common in scripts or systemd units where dnsmasq is started without waiting for Docker dependencies.
To fix this, ensure that dnsmasq is configured to start after Docker. In a systemd environment, modify the service file for dnsmasq to include:
After=docker.service
Requires=docker.servicednsmasq manually or via a script, add a delay or a loop to wait for the interface to appear:
until ip addr show docker0 | grep -q '172.17.0.1'; do
sleep 1
done
sudo dnsmasq ...Review dnsmasq Configuration
Incorrect configuration directives in/etc/dnsmasq.conf or included files can also lead to binding failures. Ensure that the interface directive explicitly specifies docker0 or 172.17.0.1 if you intend to restrict dnsmasq to that network.
interface=docker0
bind-interfacesbind-interfaces option forces dnsmasq to bind only to specified interfaces rather than all interfaces. If this is set but the interface is down or misconfigured, the error occurs. Remove bind-interfaces temporarily to test if dnsmasq can start on any available interface, which helps isolate whether the issue is interface-specific or general.
Additionally, check for duplicate entries in your configuration files. Multiple instances of listen-address or conflicting interface settings can confuse the daemon. Clean up any redundant configurations and restart the service:
sudo systemctl restart dnsmasqRestart Services Properly
After addressing port conflicts and interface availability, restart the affected services in the correct order. Restarting Docker first ensures the bridge is established, followed bydnsmasq.
sudo systemctl restart docker
sudo systemctl restart dnsmasqsudo systemctl status dnsmasqsudo journalctl -u dnsmasq -fnslookup or dig against 172.17.0.1.
Frequently Asked Questions
Why does dnsmasq fail only sometimes?
This intermittent failure often happens due to race conditions during system boot. If dnsmasq starts before the docker0 interface is fully configured, it cannot bind to 172.17.0.1. Implementing systemd dependencies or startup delays resolves this timing issue.
Can I use a different IP address for dnsmasq?
Yes, you can configure dnsmasq to listen on a different IP or interface by modifying the listen-address or interface directives in its configuration file. This is useful if 172.17.0.1 remains problematic or if you want to avoid conflicts with Docker's default bridge.
How do I check if port 53 is blocked by a firewall?
Firewall rules rarely cause "Cannot assign request" errors, which are kernel-level binding failures. However, you can check firewall status with sudo ufw status or sudo iptables -L to ensure inbound traffic on port 53 is allowed if external access is required.
What if systemd-resolved is causing the conflict?
If systemd-resolved is using port 53, you can disable it by unlinking /etc/resolv.conf and pointing it to 127.0.0.53 or configuring dnsmasq to act as the upstream resolver. Alternatively, configure systemd-resolved to not listen on localhost if dnsmasq handles all resolution.
Is it safe to ignore this error?
No, ignoring this error means dnsmasq will not provide DNS resolution for the specified network. Containers relying on this DNS server will fail to resolve domain names, leading to connection timeouts and application failures within the containerized environment.