12

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.

  • 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
9

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.

  • 2
    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
  • This fixed the problem for me, too. Thx! – Witek Nov 26 '18 at 10:03
  • 2
    @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. – Karthic Raghupathi Dec 1 '18 at 22:21
  • Same 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. – Igor Kupczyński Jan 9 at 12:44
6

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>
1

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.

  • 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
  • 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
0

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.

-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.

  • Is there any way to discover what the unresolved names are? – OrangeDog Jan 2 at 10:53

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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