Understanding systemd-resolved: Default Port 53 Usage and its Impact on Ubuntu DNS Configuration

0x00 Introduction

Some time ago, in a cyber group, the usual chatter among the experts revolved around which operating system is the most efficient. Then, somewhere in the conversation, an expert mentioned Ubuntu, calling it junk, because higher versions of Ubuntu by default occupy port 53, causing their DNS service to not start up for a long time. Wait a minute, does Ubuntu occupy port 53 by default? This was the first I’d heard of it, so I looked it up and found it was a service called systemd-resolved that occupies port 53 by default. What is this thing? Reference (http://www.jinbuguo.com/systemd/systemd-resolved.service.html#)

/>

You might as well take a glance; it roughly starts a local service similar to DNS to provide a better experience of some sort? Moreover, this feature seems to be embedded by default in versions above Ubuntu 18, my intuition tells me this might bring some interesting elements.

0x01 Exploring systemd-resolved

I checked my Alibaba Cloud’s Ubuntu host and found this service was running by default as well. I’m particularly interested in what characteristics of this feature might be exploited for security. Let’s examine the description below directly:

/>

After a rough understanding, I’ve identified a few intriguing features:

1. _gateway resolves to the gateway address
2. xxxxxx.localhost and xxxx.localhost.localdomain resolve to the local address
3. Supports mDNS, which should be disabled by default; if enabled, it will respond to mDNS, and hostname.local will resolve to the corresponding local network address

Let’s take a brief look at these three features. I’ll start a virtual machine of Ubuntu 20 and a Kali virtual machine for comparison.

Kali

Ubuntu 20

You can see that on Ubuntu, directly pinging _gateway resolves to the gateway address, while the service doesn’t run on Kali, hence no resolution. Let’s try other features similarly.

You can observe that they all resolve to the local address. However, it doesn’t work on Kali.

Alright, just take note of these small features, they might not be of much use. So, what is xxx.local, and what is mDNS? Here’s where it gets interesting.

0x02 Exploring mDNS

Let’s first post a simple introductory article about mDNS (https://www.cnblogs.com/yuweifeng/p/6409182.html). Meanwhile, here’s some information from the RFC (https://tools.ietf.org/html/rfc6762#section-5.2).

Simply put, to address the need for automatic discovery of services between hosts within a local network, the mDNS protocol emerged. Each service running mDNS listens on its own UDP port 5353, while sending requests to the multicast address 224.0.0.251 when joining a network. Furthermore, each host running mDNS will publish its hostname, IP, and running services through this multicast address, and can ask which host in the network contains a specific service. The hosts hearing this query will respond. It sounds similar to ARP but has significant differences:

1. ARP only maps MAC to IP addresses, whereas mDNS can retrieve IP addresses, hostnames, and running services.
2. ARP usually cannot cross subnets, although mDNS can respond across subnets if supported by the router.

Differences between mDNS and DNS:

1. Typically, DNS involves a single DNS server in the network, with other clients querying it, whereas mDNS involves each host supporting mDNS listening on the 5353 UDP port itself.
2. mDNS communicates via multicast, with the multicast address functioning as a public channel where nodes can inform the network who they are.

Honestly, as a beginner, my knowledge of this protocol was also partial. I just wanted to see what it can discover in the network. So I launched Wireshark on our office network to monitor the mDNS traffic:

ip.dst_host==224.0.0.251 and udp.port==5353

You can see, there are plenty of devices broadcasting their hostnames and IPs, and you can directly see my colleague’s name because their hostname includes it.

You can also find the IP address in the A record, although typically the source IP of the transmission is this A record IP itself.

So how do I retrieve similar information on a target host if I don’t have Wireshark? I found a project called zeroconfScan on GitHub (https://github.com/JohnGrime/ZeroconfScan), which basically replicates the functionality of Wireshark. This tool is written in Go and requires self-compilation. Let’s look at the demonstration:

You can see the left type and the type within DNS are largely consistent, but I don’t fully understand the specifics yet, so you can study them yourself.

Here are a few command introductions

systemd-resolve resolvectlavahi-*

systemd-resolve

resolvectl (should function similarly to what’s mentioned above)

avahi-* is the default mdns service running on my Ubuntu, so let’s look at what commands it has and what we can possibly observe

I’m interested in this browser

Let’s try -a here

The red circle may be a display issue with Chinese, but you can perceive it shows what’s listening on the network and which services hosts support. We can also monitor a specific service type and list supported service types with -kb

For instance, let’s query SSH services

Though there might be some issues with Chinese encoding above, the error message below when parsing displays Chinese correctly, emmmmm

0x03 Summary

Although systemd-resolve is enabled by default on Ubuntu versions 18 and above, it seems to only listen on port 53, while mDNS doesn’t start by default. Therefore, mDNS might miss on server auto-discovery. In an office environment, gathering some information might be alright. I haven’t dug deeper, so I’ll refrain from conclusive opinions. Why write this? Simply thought it was fun, hahaha, whether it’s useful or not, you be the judge. I believe knowing these obscure facts is slightly better than not knowing, perhaps. I hope a master out there further researches this and shares more interesting findings with me, hahaha, and please correct any evident mistakes in the article.