I just installed a new Ubuntu Server 18.04. I set my hostname hostnamectl set-hostname ****.openbayou.biz and I set /etc/hosts: localhost
[ip address] ****.openbayou.biz hostname
# The following lines are desirable for IPv6 capable hosts
[ip6 address] *****.openbayou.biz hostname
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

I also installed OSSEC to monitor for new files, errors and changes to my server and I'm now getting these alerts:

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

It's now repeating itself:

systemd-resolved[3195]: message repeated 4 times: [ Server returned error 
NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction 
with reduced feature level UDP.]

I've looked online for a solution and nobody is reporting this issue.

  • Are you behind a captive portal? – dobey Jul 23 '18 at 18:56
  • No, this is a Linode 4GB server – Gregory Schultz Jul 23 '18 at 19:27
  • If you comment out the two lines you added, does it make a difference? I don't think the errors are about your /etc/hosts. They are happening because of the infrastructure the server is behind is likely doing something wrong. github.com/systemd/systemd/pull/8608 seems to be the issue you're having, and was the first search result for "DVE-2018-0001." I don't think you're going to get a satisfactory answer until the upstream issue is fixed and released. – dobey Jul 23 '18 at 19:27
  • I got this error when my country blocked torrents – haytham-med haytham Mar 29 at 21:42

11 Answers 11


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

The same error happened to my desktop machine, I don't know if it applies to server too.

It seems that my system had the old config in the place, resulting in a conflict between two services: resolvconf and systemd-resolved.

The symlink /etc/resolv.conf pointed to ../run/resolvconf/resolv.conf

Changing it to point to /run/systemd/resolve/resolv.conf which is managed by systemd, fixed it for me.

Read more here.

Hope that helped.

| improve this answer | |
  • 13
    Mine is pointing to /run/systemd/resolve/stub-resolv.conf on an Ubuntu 18.10 instance. – datashaman Nov 11 '18 at 6:14
  • Forgot to mention my system. Latest KDE Neon, (Ubuntu based), 18.04.1, 4.15.0-39-generic. – Panagiotis Tabakis Nov 18 '18 at 12:38
  • 6
    @datashaman It was the same case for me but changing the symlink to point /run/systemd/resolve/resolv.conf from /run/systemd/resolve/stub-resolv.conf fixed the issue for me. I no longer see that error. – k427h1c Dec 1 '18 at 22:21
  • 28
    This is the wrong thing to do. This does not fix anything but actually breaks how the resolver is supposed to work. The error message goes away because the systemd resolver gets bypassed. See the answer of Hermann Klein below. – Markku Kero Oct 24 '19 at 3:46
  • 1
    Mine was pointing to /run/systemd/resolve/stub-resolv.conf on an Ubuntu 20.04. relinked to Mine is pointing to /run/systemd/resolve/resolv.conf restart and works – Brad Thompson May 17 at 18:31

This warning is logged by systemd-resolved, whenever a name can not be resolved by the DNS system (e.g. nslookup www.kjfoiqaefah34876asdf.com). This can be tolerated and is no reason to be alarmed. This is no error and nothing needs to be fixed.

Redirecting /etc/resolv.conf to /run/systemd/resolve/resolv.conf is wrong, because this way systemd-resolved is skipped and the application with the faulty DNS request talks directly to the name server and not to the systemd-resolved stub anymore. This way systemd-resolved does not notice the NXDOMAIN events any more and therefore cannot log it any more.

The NXDOMAIN events are caused by packages, which try to access non-existing servers during system startup.

| improve this answer | |
  • 11
    Is there any way to discover what the unresolved names are? – OrangeDog Jan 2 '19 at 10:53
  • 16
    @OrangeDog tcpdump -vv port 53 | grep NXDomain – bain Jul 17 '19 at 16:20
  • 1
    So there is no existing log of the application or domain that caused the log message? – lucidbrot May 8 at 17:34
  • 3
    tcpdump is not very convenient at boot time... – MarcH May 14 at 1:16

I asked on the OSSEC GitHub about this error and they recommended writing a rule to ignore NXDOMAIN errors. Add to /var/ossec/rules/local_rules.xml

<rule id="234567" level="0">
 <match>Server returned error NXDOMAIN</match>
 <description>Usless systemd-resolvd log message</description>
| improve this answer | |

I noticed the same thing on an Ubuntu 18.04 server which was recently updated to 18.04.1.

It would appear that systemd-resolve logs that message whenever it gets any NXDOMAIN response. In my case I have postfix running. So I get a lot of NXDOMAINS when random servers connect that don't have PTR record set.

You can test it with

systemd-resolve securelogin.example.com

Then you should see the log message appear.

With this in mind it would appear to be a relatively innocuous error and you can ignore it.

| improve this answer | |
  • Added PTR record and haven't gotten a notice (so far). Thanks! – Gregory Schultz Jul 26 '18 at 1:09
  • Nope. Still getting them. Think next stage is to get OSSEC to ignore them. Would it be something related to Cloudflare as it's going through their systems and not being bypassed? Also, I see that OSSEC has an update (on 2.9.4, update to 3.0.0). Will update and see what happens. – Gregory Schultz Jul 26 '18 at 21:29
  • 1
    It's just part of how systemd works. If systemd-resolve tries to resolve a domain that doesn't resolve it logs that message. – Rwky Jul 27 '18 at 22:07
  • Ugh... what's good the error message when it doesn't contain information about which process tried to request the domain nor the domain name that was about to be resolved? – Mikko Rantalainen Jul 3 at 8:57


Although there might be other circumstances where this error will occur, I can definitely say that I've seen it puked in the output of:

systemctl status systemd-resolved

...when systemd-resolved is not configured.

And an Azure Ubuntu 18.04 VM does not have systemd-resolved configured out-of-the-box (as of today, 20191008).


Configure systemd-resolved.

Mini systemd-resolved Config HowTo:

NOTE: Following instructions were prepared using Ubuntu 18.04

Edit hosts directive in /etc/nsswitch.conf by prepending resolve which sets systemd-resolved as first source of DNS resolution that will be consulted:

hosts:          resolve files dns

Edit /etc/systemd/resolved.conf. Some suggested settings:


Restart systemd-resolved:

sudo systemctl restart systemd-resolved

When you next check systemd-resolved's status, the error should now be cleared:

systemctl status systemd-resolved

And DNS resolution should now behave in the expected way.

| improve this answer | |

My understanding after having read the previous answers and other web pages such as Ubuntu 18.04 systemd-resolved error NXDOMAIN is that this is more a warning than an error and there is nothing I can do on my side about it.

Therefore, I agree with those who say that we should not try to do something on our side so that these messages are not produced anymore. If we succeed, it is likely that we have altered the normal way the system resolve DNS requests.

However, since I have thousands of them (I am also in a desktop - it's not a server), I don't want them in my syslog file. Therefore, following https://www.rsyslog.com/doc/v8-stable/configuration/filters.html and Number pair prefix to config files, I added a file named 10-resolv.conf with a single line :msg, contains, "Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP" ~ in the directory /etc/rsyslog.d .

The name 10-resolv.conf is not important, but it must precede all other file names in the directory in alphabetic order. The command :msg, contains, <message-part> ~ says that all messages that contains <message-part> must be ignored: the tilde ~ in the command says to drop the message.

Note added: Since I wrote this answer, I installed some packages (for other reasons) and the error message is not produced anymore as checked with journalctl -u systemd-resolved -f. One installed package that might explain the disappearance of this message is libnss-resolve.

| improve this answer | |
  • I still see the message after installing libnss-resolve. Still the best answer IMHO. – Jocelyn Sep 1 at 6:09


NXDOMAIN error message means that a domain does not exist.

Some ISPs started DNS hijacking or DNS redirection for NXDOMAIN error messages. It is the practice of redirecting the resolution of Domain Name System (DNS) names to other DNS servers or web servers.

Commonly used for displaying advertisements or collecting statistics.

This practice violates the RFC standard for DNS (NXDOMAIN) responses.

Phishing: Cross-site scripting attacks can occur due to malicious hijacking.

Censorship: DNS service providers to block access to selected domains.

Shown up here: https://www.dnsknowledge.com/whatis/nxdomain-non-existent-domain-2/

| improve this answer | |

Apparently it doesn't link to anymore, but I had no issues with it since re-linking.

I think there is a bug report out on this one. Anyway, it worked very well after re-linking.


# systemctl status systemd-resolved

# unlink /etc/resolv.conf

# ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

# systemctl restart systemd-resolved

# systemctl status systemd-resolved
| improve this answer | |
  • 1
    Never thought I had to write the following on this forum, but apparently "yes": The "#" is the root's prompt. As a normal user, you would need "sudo" on all non-"status" commands. – intosomethin Apr 19 at 23:52
  • Could you please add some more explanation about why Herrman Klein is wrong here? As somebody with little previous knowledge on this topic, right now there are just three disagreeing answers, two with many votes and one which is newer. How or Why is Panagiotis not bypassing systemd. Why especially not if it was linked to stub-resolv.conf ? – lucidbrot May 8 at 17:39
  • 1
    It is bypassing systemd, because the requests are not sent anymore to, which is the systemd resolver. (Notice the difference between the nameserver lines.) – Jocelyn Sep 1 at 6:08
  • @Jocelyn: This I haven't checked. I amend my reply. – intosomethin Nov 13 at 22:38

I was able to get rid of the message, and by the way I was also able to finally connect to my samba server, by changing the server name to server.domain instead of only server.

| improve this answer | |

In my case Google Cloud dislikes CloudFlare DNS. After running the following command from bain above

sudo tcpdump -vv port 53 | grep NXDomain

When I open my domain in a browser I get:

dns.google.domain > ....: [udp sum ok] .... NXDomain q: PTR? ... ns: .... SOA ....cloudflare.com. dns.cloudflare.com. ....

Might be the case with other VPS-CDN providers as well.

Moving DNS to your VPS/Cloud provider can help.

| improve this answer | |

This appears related to EDNS. The difference between using stub-resolv.conf and resolv.conf is options edns0.

Extension mechanisms for DNS (EDNS) is a specification for expanding the size of several parameters of the Domain Name System (DNS) protocol which had size restrictions that the Internet engineering community deemed too limited for increasing functionality of the protocol.


More details under this issue: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1766969

It sounds like, you can simply turn off that "option".

| improve this answer | |
  • 1
    edns0 is needed by some client applications, for exemple for ensuring the response is validated by DNSSEC. It was added to systemd for this reason in this commit: github.com/systemd/systemd/commit/… – Jocelyn Sep 1 at 6:03

Not the answer you're looking for? Browse other questions tagged or ask your own question.