I just installed a new Ubuntu Server 18.04. I set my hostname hostnamectl set-hostname ****.openbayou.biz
and I set /etc/hosts
:
127.0.0.1 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.
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 waysystemd-resolved
is skipped and the application with the faulty DNS request talks directly to the name server and not to thesystemd-resolved
stub anymore. This waysystemd-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.
IMPORTANT: The solution posted here hides the problematic message by bypassing an important part of your system (the DNS resolver daemon). It may cause DNS malfunction in the future (example). For a proper way to handle the error message please refer to this answer.
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
andsystemd-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 on Ubuntu Forums
Hope that helped.
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
Problem
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:
...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).Solution:
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 prependingresolve
which sets systemd-resolved as first source of DNS resolution that will be consulted:Edit
/etc/systemd/resolved.conf
. Some suggested settings:Restart
systemd-resolved
:When you next check
systemd-resolved
's status, the error should now be cleared:And DNS resolution should now behave in the expected way.
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
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.
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.Summary:
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/
Apparently it doesn't link to 127.0.0.53 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.
Steps:
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 onlyserver
.In my case Google Cloud dislikes CloudFlare DNS. After running the following command from bain above
When I open my domain in a browser I get:
Might be the case with other VPS-CDN providers as well.
Moving DNS to your VPS/Cloud provider can help.