I tried to check what my DNS resolver is and I noticed this:

user@ubuntu:~$ cat /etc/resolv.conf 

options edns0

I was expecting, which is my default gateway, my router.

I don't understand why it points at When I hit that ip, apache2 serves me its contents. Could someone clear this up for me? Shouldn't the file point directly at my default gateway which acts as a DNS resolver - or even better directly at my preferred DNS which is

P.S: When I capture DNS packets with wireshark on port 53 all I see is and not, as it should be.


3 Answers 3


You are likely running systemd-resolved as a service.

systemd-resolved generates two configuration files on the fly, for optional use by DNS client libraries (such as the BIND DNS client library in C libraries):

  • /run/systemd/resolve/stub-resolv.conf tells DNS client libraries to send their queries to This is where the systemd-resolved process listens for DNS queries, which it then forwards on.
  • /run/systemd/resolve/resolv.conf tells DNS client libraries to send their queries to IP addresses that systemd-resolved has obtained on the fly from its configuration files and DNS server information contained in DHCP leases. Effectively, this bypasses the systemd-resolved forwarding step, at the expense of also bypassing all of systemd-resolved's logic for making complex decisions about what to actually forward to, for any given transaction.

In both cases, systemd-resolved configures a search list of domain name suffixes, again derived on the fly from its configuration files and DHCP leases (which it is told about via a mechanism that is beyond the scope of this answer).

/etc/resolv.conf can optionally be:

  • a symbolic link to either of these;
  • a symbolic link to a package-supplied static file at /usr/lib/systemd/resolv.conf, which also specifies but no search domains calculated on the fly;
  • some other file entirely.

It's likely that you have such a symbolic link. In which case, the thing that knows about the setting, that is (presumably) handed out in DHCP leases by the DHCP server on your LAN, is systemd-resolved, which is forwarding query traffic to it as you have observed. Your DNS client libraries, in your applications programs, are themselves only talking to systemd-resolved.

Ironically, although it could be that you haven't captured loopback interface traffic to/from properly, it is more likely that you aren't seeing it because systemd-resolved also (optionally) bypasses the BIND DNS Client in your C libraries and generates no such traffic to be captured.

There's an NSS module provided with systemd-resolved, named nss-resolve, that is a plug-in for your C libraries. Previously, your C libraries would have used another plug-in named nss-dns which uses the BIND DNS Client to make queries using the DNS protocol to the server(s) listed in /etc/resolv.conf, applying the domain suffixes listed therein.

nss-resolve gets listed ahead of nss-dns in your /etc/nsswitch.conf file, causing your C libraries to not use the BIND DNS Client, or the DNS protocol, to perform name→address lookups at all. Instead, nss-resolve speaks a non-standard and idiosyncratic protocol over the (system-wide) Desktop Bus to systemd-resolved, which again makes back end queries of or whatever your DHCP leases and configuration files say.

To intercept that you have to monitor the Desktop Bus traffic with dbus-monitor or some such tool. It's not even IP traffic, let alone IP traffic over a loopback network interface. as the Desktop Bus is reached via an AF_LOCAL socket.

If you want to use a third-party resolving proxy DNS server at, or some other IP address, you have three choices:

  • Configure your DHCP server to hand that out instead of handing out systemd-resolved will learn of that via the DHCP leases and use it.
  • Configure systemd-resolved via its own configuration mechanisms to use that instead of what it is seeing in the DHCP leases.
  • Make your own /etc/resolv.conf file, an actual regular file instead of a symbolic link, list there and remember to turn off nss-resolve so that you go back to using nss-dns and the BIND DNS Client.

The systemd-resolved configuration files are a whole bunch of files in various directories that get combined, and how to configure them for the second choice aforementioned is beyond the scope of this answer. Read the resolved.conf(5) manual page for that.

  • 3
    I've read the resolved.conf manpage and can not figure out how to configure it to ignore the DHCP assigned DNS servers. Is there somewhere else with information about this?
    – nog642
    Commented Apr 13, 2021 at 19:19
  • @JdeBP 's answer is actually the best one so far as it catches multiple cases and explains why DNS configs may look good from the view of many tools, yet still not provide a name resolution. (case and point the part about the AF_LOCAL socket)
    – Vasil
    Commented Jan 21, 2023 at 15:40
  • 1
    If you want to use other DHCP servers under Ubuntu you can leverage the netplan app. Do NOT try to override /etc/resolve.conf. Instead create/update a yaml file in the /etc/netplan/ directory. Additional DNS servers can be listed like this under your ethernets: followed by your interface name (eg. ens18 or eth0): nameservers:<newline> addresses: [,,] Commented Mar 29, 2023 at 17:57

The entire CIDR block is used for loopack routing. Your host seems to be (or at least seems to think it is) running its own DNS server on that specific loopback address.

Because loopback traffic (generally) never goes on the wire, it's not surprising that you do not see TCP/53 traffic in snipping tools like Wireshark, as they may not monitor loopback traffic with default settings. Using a tool such as ss (e. g. ss -plnt | grep ':53' will show you which process, if any, is listening on that TCP port to investigate further.

Possibly releated is that Ubuntu appears to use a loopback resolver, systemd-resolved in newer releases, as discussed in this answer on AskUbuntu.

  • 2
    wireshark can monitor loopback, but may not do so by default. Commented Oct 1, 2020 at 18:54
  • The thing is I never set up a local DNS resolver. I am using Ubuntu 20. Is there one by default?
    – HelloWorld
    Commented Oct 1, 2020 at 19:33
  • Did you run ss as described or similar tooling to see what if anything is listening on that IP?
    – DopeGhoti
    Commented Oct 1, 2020 at 19:48
  • @DopeGhoti apache2!
    – HelloWorld
    Commented Oct 1, 2020 at 19:53
  • 2
    should be systemd-resolve listening on 53 on an ubuntu 20.04 system. Commented Oct 1, 2020 at 19:55

This is because you are using systemd-resolved service for Network Name Resolution. In that case you can use resolvectl status command. Go to your network for eg: wlp1s0. Check the current DNS server. At first it was my router's IP 192.168.x.x, I have updated Primary DNS server to OpenDNS FamilyShield DNS resolver) under DHCP Server option in router configuration page. So Now after restarting NetworkManager, this is what I am getting when running resolvectl status

Link 3 (wlp1s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server:
       DNS Servers:

See the change in current DNS server from my router IP to OpenDNS one.

  • 5
    The question is about DNS, and your answer talks about DNS. Beyond that, you don't appear to have answered the question: Why does /etc/resolv.conf point at How does your example relate to the question? Besides, JdeBP has already posted a lengthy answer discussing systemd-resolved. Commented Feb 1, 2022 at 22:52
  • 9
    And yet this answer is fairly concise and super helpful.
    – pattivacek
    Commented Mar 22, 2022 at 13:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .