New alert keeps showing up: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001
Solution 1
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.
Solution 2
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.
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 on Ubuntu Forums
Hope that helped.
Solution 3
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">
<program_name>systemd-resolved</program_name>
<match>Server returned error NXDOMAIN</match>
<description>Usless systemd-resolvd log message</description>
</rule>
Solution 4
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:
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).
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 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:
[Resolve]
DNS=8.8.8.8 8.8.4.4
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
Cache=yes
DNSStubListener=yes
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.
Solution 5
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.
Related videos on Youtube
Gregory Schultz
Updated on September 18, 2022Comments
-
Gregory Schultz over 1 year
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.
-
dobey almost 6 yearsAre you behind a captive portal?
-
Gregory Schultz almost 6 yearsNo, this is a Linode 4GB server
-
dobey almost 6 yearsIf 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.
-
haytham-med haytham about 4 yearsI got this error when my country blocked torrents
-
-
Gregory Schultz almost 6 yearsAdded PTR record and haven't gotten a notice (so far). Thanks!
-
Gregory Schultz almost 6 yearsNope. 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.
-
Rwky almost 6 yearsIt's just part of how systemd works. If systemd-resolve tries to resolve a domain that doesn't resolve it logs that message.
-
Leo almost 6 yearsdo you mind adding the link to the recommendation in your answer? It would be useful for others having the same issue. thanks!
-
Gregory Schultz almost 6 years
-
datashaman over 5 yearsMine is pointing to
/run/systemd/resolve/stub-resolv.conf
on an Ubuntu 18.10 instance. -
Panagiotis Tabakis over 5 yearsForgot to mention my system. Latest KDE Neon, (Ubuntu based), 18.04.1, 4.15.0-39-generic.
-
Karthic Raghupathi over 5 years@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. -
OrangeDog over 5 yearsIs there any way to discover what the unresolved names are?
-
Igor Kupczyński over 5 yearsSame worked for me. I'm on 18.10, but migrated from 18.04. Changing the
/etc/resolv.conf -> /run/systemd/resolve/resolv.conf
did the trick. -
acgbox about 5 yearsnot work in ubunto 18.04
-
Dennis about 5 years@PanagiotisTabakis any chance you could edit the answer with the command required to change the symlink?
-
Panagiotis Tabakis about 5 years@Dennis generally, to change the target of a symlink, you use
ln -fs /path/to/file2 /path/to/symlink
. In my case it wasln -fs /run/systemd/resolve/resolv.conf /etc/resolv.conf
-
bain almost 5 years@OrangeDog
tcpdump -vv port 53 | grep NXDomain
-
F1Linux over 4 yearsThis error can be returned if systemd-resolved has no forwarders set.
-
Markku Kero over 4 yearsThis 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.
-
intosomethin about 4 yearsNever 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.
-
Eero Aaltonen about 4 yearsI tested this. As a practical drawback, this broke DNS resolution when using a VPN.
-
lucidbrot about 4 yearsSo there is no existing log of the application or domain that caused the log message?
-
lucidbrot about 4 yearsCould 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
? -
MarcH about 4 years
tcpdump
is not very convenient at boot time... -
Brad Thompson about 4 yearsMine 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
-
Mikko Rantalainen almost 4 yearsUgh... 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?
-
Murilo Guimarães over 3 yearsedns0 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/…
-
Murilo Guimarães over 3 yearsIt is bypassing systemd, because the requests are not sent anymore to 127.0.0.53, which is the systemd resolver. (Notice the difference between the
nameserver
lines.) -
Murilo Guimarães over 3 yearsI still see the message after installing libnss-resolve. Still the best answer IMHO.
-
yop83 over 3 yearsChanging an important system-level file like this is a bad idea and will only cause pain further down the line.
-
intosomethin over 3 years@Jocelyn: This I haven't checked. I amend my reply.
-
Robert Wm Ruedisueli over 3 yearsUnless you actually have a problem this error is harmless. It means you searched for a domain name (like a web site name) that didn't exist. It is telling you that it is using a workaround to make sure that the domain really doesn't exit. More of these errors need to be tagged "This error is harmless" meaning it's only for info in case you are actually looking at something that went wrong. The other option is to just tag it "INFO:"
-
Jea about 3 yearsdoes not work in ubuntu 20.04 either
-
Throw Away Account about 3 yearsI don't see what's wrong with bypassing systemd-resolved by symlinking
/etc/resolv.conf
. Nobody asked forsystemd-resolved
to be created in the first place, let alone made nearly impossible to disable, like some piece of malware. DNS works just fine without it. -
Csabi Vidó about 3 yearsNote for readers who want to say that this answer does not work: The question was about a message also caught in OSSEC, a software that is not installed by default in Ubuntu. This answer says, that one may ignore the message with a rule in OSSEC. If you look at journalctl or other logs the message will still be there.
-
LMSingh about 2 years+1, IMHO good answer. Instead of suppressing/ignoring seems to address the root cause for machines where systemd-resolved is not configured. Thank you.
-
LMSingh about 2 yearsAt least for my system, I now have more detail on the root cause.. (it might help others). As per man page for systemd-resolved (manpages.ubuntu.com/manpages/bionic/man8/…) read the section starting with "The DNS servers contacted are determined from ... ...". Because I was not using DHCP provided DNS (and all other DNS resolution options listed in the man page also were not available), there was no other way for a name to get resolved. Setting the DNS value in [Resolve] section allows the service to use that for resolution.