3

I'm currently testing Ubuntu 20.04.1 (after decades using Fedora from Core 2 to 31), and I have currently issue with local/private DNS resolution.

Getting systematically error messages linked to this vulnerability:

Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP

Simplified context:

  • I have a Synology Router which provides Ethernet network (its @IP address 192.168.56.1)
  • it is the one providing DHCP server
  • each of my devices (about 10) have a specific DHCP registration, with a specific name

For sake of simplification, let's consider the Device named 'nas'.

Out of the box, my Ubuntu 20.04.1 LTS refuses to resolve nas, whatever the used command, see end of this question.

After plenty of readings on Stackoverflow, and Forum, I tried, without success:

  • install libnss-resolve, which enhance /etc/nsswitch.conf file
  • change /etc/resolv.conf symbolic link from /run/systemd/resolve/stub-resolv.conf to /run/systemd/resolve/resolv.conf
  • hack /etc/systemd/resolved.conf file specifying @IP address of my router as DNS server
  • hack /etc/sysctl.conf file to define kernel.domainname with a specific domain, like defined on my Synology Router (previously there was none, and it was working with Fedora)
  • flush the cache sudo systemd-resolve --flush-caches

Tests:

systemd-resolve nas
nas: resolve call failed: No appropriate name servers or networks for name found

dig nas
; <<>> DiG 9.16.1-Ubuntu <<>> nas
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 65082
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;nas.               IN  A

;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: mer. juil. 29 15:13:09 CEST 2020
;; MSG SIZE  rcvd: 32

dig @192.168.56.1 nas
; <<>> DiG 9.16.1-Ubuntu <<>> @192.168.56.1 nas
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34633
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;nas.               IN  A

;; AUTHORITY SECTION:
.           86064   IN  SOA a.root-servers.net. nstld.verisign-grs.com. 2020072900 1800 900 604800 86400

;; Query time: 24 msec
;; SERVER: 192.168.56.1#53(192.168.56.1)
;; WHEN: mer. juil. 29 15:13:30 CEST 2020
;; MSG SIZE  rcvd: 107

nslookup nas

Server: 127.0.0.53 Address: 127.0.0.53#53

** server can't find nas: SERVFAIL


Current contents of my /etc/resolv.conf (the default one):

nameserver 127.0.0.53
options edns0

Current contents of my /etc/nsswitch.conf:

passwd:         files systemd
group:          files systemd
shadow:         files
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Of course, adding @ip/name mapping in /etc/hosts works but it is NOT a solution.

Edit: I still have the same issue under Ubuntu 22.04.2 LTS, with my very new Synology RT2600ac. How can I fix this issue?

15
  • My setup is like yours except 1) I have a search <router supplied default dom> at the end of my (stub) resolv.conf. 2)nslookup,ping, dig name all work for me (this month). Last month, this same setup failed, so is your system fully updated? I also wondered about missing mdns4 in the nsswitch.conf (like the 18.04 has). Local names seem to be a moving target, ;^(
    – ubfan1
    Commented Jul 29, 2020 at 16:20
  • Yes my system is updated to 20.04.1 LTS, and security updates are installed. I tried adding the search <my router @IP> without success :/ What do you mean by missing mdns4 in nsswitch.conf ? Commented Jul 30, 2020 at 7:33
  • See github.com/datawire/teleproxy/issues/60 The mdns4_minimal only handles .local Wrong about 18.04, it's not there now, Don't recall where I saw it, but the link has an example of using both.
    – ubfan1
    Commented Jul 30, 2020 at 15:52
  • 1
    Thanks, but like I said, without changing anything on my Router, DNS resolution was perfectly working under Fedora ... Commented Aug 12, 2020 at 20:21
  • 1
    In lieu of fixing dns on the Synology, then you would need a DNS server for local names and dnsmasq is an easy way to provide that service. I run dnsmasq on a small always on computer and hand it out as the first dns ip address for my network. Though I would debug the Synology more as I found indications it can act as a DNS server.
    – Guser314
    Commented Aug 16, 2020 at 19:55

2 Answers 2

1

This error means the DNS server could not resolve the domain. It generally means that your local dns setup sends queries about local domains (.local, .lan, .home, ...) to remode dns servers. In my case, I had configured "Domains=" (with my local search domain) in /etc/systemd/resolved.conf, but no "DNS=" (leaving this to DHCP), which is wrong. When the dns server is provided by dhcp, the search domain has to be provided the same way.

5
  • So you mean, you fixed your issue, with no more things defined in /etc/systemd/resolved.conf? Commented Oct 12, 2020 at 8:38
  • Yes, that's right.
    – Olivier
    Commented Oct 13, 2020 at 9:03
  • In my opinion, debugging a dns configuration could be made much easier if there was a --verbose or --debug flag to the systemd-resolve (resolvectl) tool.
    – Olivier
    Commented Oct 13, 2020 at 9:05
  • I tried that, and unfortunately it still doesn't work, I still have systemd-resolved[1273]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP. Commented Nov 26, 2020 at 8:12
  • Some other relevant settings: askubuntu.com/a/1179542/935172 Commented Jan 23, 2021 at 20:55
0

You haven't said whether this is a Server or Desktop installation. Either way, I'll outline how to set a search domain for you. Your original post indicates that you were using Ubuntu 20.04, but you've since upgraded to 22.04.

Side note: The following would apply to both 20.04 and 22.04, but the output of resolvectl status looks a bit different between versions.

With regards to what search domain to use, this is dependent on what's been defined in the DHCP server on your router. It's typically something like local, localdomain, or lan. You can edit as wanted.

I'm using a pfSense router. A domain is entered on the System/General Setup page. In my case, the default is localdomain, which I've left as configured.

enter image description here

I'm not familiar with Synology routers, so you'll have to consult the manual on how to define a domain. You've indicated in a comment that you "do not have a domain configured on my router anymore." I suspect this is part of the problem.

To clarify the purpose of a search domain, the manpage for systemd-resolved.service(8) explains it rather well:

Queries for the address records (A and AAAA) of single-label non-synthesized names are resolved via unicast DNS using search domains. For any interface which defines search domains, such look-ups are routed to the servers defined for that interface, suffixed with each of those search domains. When global search domains are defined, such look-ups are routed to the global servers. For each search domain, queries are performed by suffixing the name with each of the search domains in turn.


Let's get started...

I see that you've edited /etc/resolv.conf in your attempts to solve your problem. So let's reset this file as a symlink to /run/systemd/resolve/stub-resolv.conf, which is the local caching stub resolver and the default setup.

Run ls -l /etc/resolv.conf to see what it currently is. On my system, I get the following:

$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Dec 31  2021 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

If it's a file or a symlink to something other than /run/systemd/resolve/stub-resolv.conf, then delete it:

sudo rm /etc/resolv.conf

Next, create a symlink:

sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

Now let's add a search domain to a network interface for both a Server and Desktop host.

Server

Networking is typically configured via Netplan and managed by systemd-networkd as the backend renderer. Let's see how the current system is setup before making any changes.

On a virtual machine, I have the following Netplan YAML config file with an interface setup as DHCP.

$ cat /etc/netplan/00-network.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: true

Show the output of cat /etc/resolv.conf before any changes. Note that a search domain is not listed.

$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad

In the following output of resolvectl status eth0, I'm only showing one specific link. Substitute eth0 with your device name. Notice that it doesn't indicate a setting for DNS Domain, which is where a search domain would be listed.

$ resolvectl status eth0
Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS
                    DNSSEC=no/unsupported         
  Current DNS Server: 192.168.10.1
         DNS Servers: 192.168.10.1

Now that we've seen the current state, let's edit your Netplan config file. Substitute the name of your config file in the following command:

sudo /etc/netplan/00-network.yaml

To add a search domain, edit your config file as follows. In this example, I'm adding localdomain as a search domain.

$ cat /etc/netplan/00-network.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: true
      nameservers:
        search: [localdomain]

Save and exit the file. Then apply the changes:

sudo netplan try

Restart systemd-resolved:

sudo systemctl restart systemd-resolved

Then look at the output of /etc/resolv.conf and you'll see the search domain has been added.

$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search localdomain

Likewise, resolvectl status eth0 shows that localdomain is listed under DNS Domain.

$ resolvectl status eth0
Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS
                    DNSSEC=no/unsupported         
  Current DNS Server: 192.168.10.1
         DNS Servers: 192.168.10.1
          DNS Domain: localdomain 

Desktop

With a Desktop installation, networking is typically managed by Network Manager. Therefore, we'll use nm-connection-editor to open the Network Connections editor and add a search domain to an interface.

Before editing a connection, let's look at the current state before adding a new search domain. Enter cat /etc/resolv.conf. On my system...

$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad

Enter nm-connection-editor in a terminal. A Network Connections window will open. Select your interface that you want to edit, then click the gear icon on the bottom. A new window will open. Select the IPv4 Settings tab and enter a search domain under Additional Search Domains. In the below image, I'm editing a wifi connection called Bluwave and I've entered localdomain as an additional search domain.

enter image description here

Click Save to close this window. Then close the Network Connections window.

The effects of this edit can be seen in Network Manager system-connections config files in the /etc/NetworkManager/system-connections directory. The name of the file for the above connection is Bluewave.nmconnection. Yours will be different. Here are the contents before adding localdomain as a search domain on my interface. Note that dns-search is empty.

$ sudo cat Bluwave.nmconnection 
[connection]
id=Bluwave
uuid=e37ca330-8072-4c45-a5f9-e6ac73f3351b
type=wifi
interface-name=wlp9s0
permissions=
timestamp=1691197080

[wifi]
mac-address-blacklist=
mode=infrastructure
seen-bssids=04:D5:90:AC:79:F0;04:D5:90:AC:79:F8;04:D5:90:AC:8E:00;04:D5:90:AC:8E:08;
ssid=Bluwave

[wifi-security]
key-mgmt=wpa-psk
psk=XXXXXXXXXXXXXX

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
ip6-privacy=0
method=auto

[proxy]

After adding the search domain, you'll see the localdomain added to dns-search:

$ sudo cat Bluwave.nmconnection 
[connection]
id=Bluwave
uuid=e37ca330-8072-4c45-a5f9-e6ac73f3351b
type=wifi
interface-name=wlp9s0
permissions=
timestamp=1691197080

[wifi]
mac-address-blacklist=
mode=infrastructure
seen-bssids=04:D5:90:AC:79:F0;04:D5:90:AC:79:F8;04:D5:90:AC:8E:00;04:D5:90:AC:8E:08;
ssid=Bluwave

[wifi-security]
key-mgmt=wpa-psk
psk=XXXXXXXXXXXXXX

[ipv4]
dns-search=localdomain
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
ip6-privacy=0
method=auto

[proxy]

Anyway, Network Manager needs to restart (or a reboot) for this change to take effect. So back in the terminal, run the following command:

sudo systemctl restart network-manager

Your new search domain should be in effect. To confirm, look again at cat /etc/resolv.conf. Notice how the search domain of localdomain has been added.

$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search localdomain

This is also shown in the output of resolvectl status. In the following output, I'm only showing my specific wifi device. Substitute wlp9s0 with your device name.

$ resolvectl status wlp9s0
Link 3 (wlp9s0)
$ resolvectl status eth0
Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS
                    DNSSEC=no/unsupported         
  Current DNS Server: 192.168.10.1
         DNS Servers: 192.168.10.1
          DNS Domain: ~.           
                      localdomain 

When it's all said and done, you should be able to ping your server or run nslookup with it's hostname. As an example on my network:

$ ping -c 1 office
PING office.localdomain (192.168.10.30) 56(84) bytes of data.
64 bytes from OFFICE.localdomain (192.168.10.30): icmp_seq=1 ttl=128 time=0.385 ms

--- office.localdomain ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.385/0.385/0.385/0.000 ms



$ nslookup office
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   office.localdomain
Address: 192.168.10.30

You must log in to answer this question.

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