Question

port 53 open from system-resolve

Posted on May 30, 2024
Droplets
Asked by paul

I ran an “nmap -sUV -F” on my droplet, from the outside, and it returned the following:

   Port    state        service       version
  53/udp   open         domain       dnsmasq 2.90

Im running Debian 12. My firewall is solid. I first thought may be my outgoing rules to connect to the digitalocean dns servers was causing it. I removed the rules that allow for dns lookups and even tested it with an apt update and it failed like it should. So I did a “netstat -tulnp | grep 53” and got the following results:

udp 0 0 127.0.0.54:53 0.0.0.0:* 401/systemd-resolve

udp 0 0 127.0.0.53:53 0.0.0.0:* 401/systemd-resolve

udp 0 0 0.0.0.0:5355 0.0.0.0:* 401/systemd-resolve

My research indicates that the culprit is 127.0.0.53:53 through systemd-resolve process. But how is the outside world getting a response from a loopback address since the all addresses setting 0 0.0.0.0:5355 is port 5355 an not port 53 ? I don’t want to start messing with dnsmasq or editing the /etc/systemd/resolved.conf. Does any one know the answer?

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

alexdo

Site Moderator

• May 31, 2024

Hello, @paulsquid

You can run ss -tuln | grep :53 to see if any services are explicitly bound to all interfaces or the public interface.

Also confirm if dnsmasq is running and on which interfaces:

ps aux | grep dnsmasq

You might also want to check the configuration of dnsmasq to see which interfaces it’s bound to.

Given that systemd-resolved is configured to bind to the loopback address, it should not be exposed externally. The appearance of dnsmasq in the Nmap scan suggests that dnsmasq might be running and bound to an external interface.

Regards

paul • May 30, 2024

Add my own comment to my question: I should have check to see if I had dnsmasq 2.90 installed on my droplet. I do not. Even if I did debian 12 dnsmasq is 2.89. So I don’t think it is my droplet. But the question still stands then what is causing the nmap -sU result?