Solved: Error starting userland proxy: listen tcp4 0.0.0.0:53: bind: address already in use -

Problem

While configuring the Duo Network Gateway (DNG) on a Ubuntu device for RDP, I came across the following error while trying to configure a DNS service:

The error is presented because the Ubuntu system is using the UDP port 53 (DNS). This is because there is a network name resolution service called systemd-resolved running by default. This service provides name resolution to local applications using the loopback IP of the device and acts by default as a DNS stub listener. It can also validate DNS/DNSSEC and can be configured for Link-Local Multicast Name Resolution (LLMNR) which when enabled will become a full LLMNR responder and resolver. There are a few other things that systemd-resolved can do but for this article, we won’t discuss those as they’re not relevant. You can find out more about systemd-resolved here.

Solution

II’ve seen articles on the Internet recommending that systemd-resolved should be disabled if you encounter this issue. However, by disabling systemd-resolved, the name resolution will not work, so we need to take another approach. The approach that we’re going to take in this article is to modify the resolved.conf for systemd-resolved. We will modify the configuration so that it no longer listens for DNS requests but rather uses the configured DNS servers for that task.

Verify that port 53 is used on your DNG

Although you have experienced the aforementioned error that more than likely brought you here, let’s not jump the gun! We want to start by checking what is using port 53. Enter the following command to valid port 53 is indeed in use.

sudo lsof -i udp:53

You should recieve a similar output to the one shown in the screenshot below. Here we confirm that systemd-resolved is indeed using UDP 53 (DNS).

We can further validate this by performing an NSLOOKUP to see what the system uses to resolve FQDN’s. Enter the following command.

sudo nslookup google.com

The results should be similar to the screenshot below. You can see that the DNG is using itself to cache and perform DNS lookups.

Modify systemd/resolved.conf

Now that we are 100% certain that systemd-resolved is causing some issues here, lets modify the configruation so that we can return to what we were originally trying to achieve. Enter the following commands and modify the following fields.Now that we are 100% certain that systemd-resolved is causing some issues here, lets modify the configruation so that we can return to what we were originally trying to achieve. Enter the following commands and modify the following fields.

sudo nano /etc/systemd/resolved.conf

[Resolve]
DNS=<Your preferred DNS server/s here>
#FallbackDNS=
Domains=<enter your domain here>
#LLMNR=no
MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=no

Once saved, now we will create a symbolic link between for resolved.conf. This is basically just creating a shortcut or alias for the configuration file. Enter the following commands.

sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

Reboot the DNG and confirm changes

Although we should now be good and if you performed another NSLOOKUP, you would see that the DNG is no longer authoritive for DNS. Lets reboot the system just to confirm that the changes are now in place. Enter the following command.

reboot

When the system comes back online, perform another NSLOOKUP. You should now see that you are resolving with the DNS server/s that you configured.

You are now free to go back to installing DNS within Docker…assuming that’s what you were doing ;-).

Note: If you’re still having issues you could run the following commands. The first command will stop systemd-resolved and the last command will make sure you can still do DNS lookups with this service now stopped.

sudo systemctl stop systemd-resolved
nslookup google.com