New alert keeps showing up: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001
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.
server dns systemd-resolved
edited Nov 27 '18 at 19:38
200_success
839716
asked Jul 23 '18 at 18:47
Gregory SchultzGregory Schultz
182116
add a comment |
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.
server dns systemd-resolved
edited Nov 27 '18 at 19:38
200_success
839716
asked Jul 23 '18 at 18:47
Gregory SchultzGregory Schultz
182116
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
add a comment |
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.
server dns systemd-resolved
edited Nov 27 '18 at 19:38
200_success
839716
asked Jul 23 '18 at 18:47
Gregory SchultzGregory Schultz
182116
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.
server dns systemd-resolved
server dns systemd-resolved
edited Nov 27 '18 at 19:38
200_success
839716
asked Jul 23 '18 at 18:47
Gregory SchultzGregory Schultz
182116
edited Nov 27 '18 at 19:38
200_success
839716
asked Jul 23 '18 at 18:47
Gregory SchultzGregory Schultz
182116
edited Nov 27 '18 at 19:38
200_success
839716
edited Nov 27 '18 at 19:38
200_success
839716
edited Nov 27 '18 at 19:38
200_success
839716
839716
asked Jul 23 '18 at 18:47
Gregory SchultzGregory Schultz
182116
asked Jul 23 '18 at 18:47
Gregory SchultzGregory Schultz
182116
asked Jul 23 '18 at 18:47
Gregory SchultzGregory Schultz
182116
182116
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
add a comment |
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
Are you behind a captive portal?
– dobey
Jul 23 '18 at 18:56
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
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
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
add a comment |
7 Answers
7
active
oldest
votes
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.
answered Nov 10 '18 at 0:35
Panagiotis TabakisPanagiotis Tabakis
1,207719
3
Mine is pointing to/run/systemd/resolve/stub-resolv.confon 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.conffrom/run/systemd/resolve/stub-resolv.conffixed 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.confdid the trick.
– Igor Kupczyński
Jan 9 at 12:44
add a comment |
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>
edited Oct 20 '18 at 0:16
Chai T. Rex
4,18611536
answered Jul 31 '18 at 19:29
Gregory SchultzGregory Schultz
182116
do you mind adding the link to the recommendation in your answer? It would be useful for others having the same issue. thanks!
– Leo
Aug 10 '18 at 3:03
1
github.com/ossec/ossec-hids/issues/1479
– Gregory Schultz
Aug 11 '18 at 10:16
not work in ubunto 18.04
– ajcg
7 hours ago
add a comment |
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.
edited Jul 25 '18 at 13:13
abu_bua
4,04181530
answered Jul 25 '18 at 10:52
RwkyRwky
1563
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
add a comment |
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.
answered Dec 16 '18 at 19:57
Hermann KleinHermann Klein
212
Is there any way to discover what the unresolved names are?
– OrangeDog
Jan 2 at 10:53
add a comment |
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/
edited Feb 5 at 22:07
NIMISHAN
90131119
answered Feb 5 at 10:12
GuestGuest
111
add a comment |
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.
answered Oct 24 '18 at 12:49
roschrosch
5,47411323
add a comment |
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.
answered Mar 20 at 3:30
Dominic108Dominic108
1,14955
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1058750%2fnew-alert-keeps-showing-up-server-returned-error-nxdomain-mitigating-potential%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Nov 10 '18 at 0:35
Panagiotis TabakisPanagiotis Tabakis
1,207719
3
Mine is pointing to/run/systemd/resolve/stub-resolv.confon 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.conffrom/run/systemd/resolve/stub-resolv.conffixed 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.confdid the trick.
– Igor Kupczyński
Jan 9 at 12:44
add a comment |
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.
answered Nov 10 '18 at 0:35
Panagiotis TabakisPanagiotis Tabakis
1,207719
3
Mine is pointing to/run/systemd/resolve/stub-resolv.confon 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.conffrom/run/systemd/resolve/stub-resolv.conffixed 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.confdid the trick.
– Igor Kupczyński
Jan 9 at 12:44
add a comment |
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.
answered Nov 10 '18 at 0:35
Panagiotis TabakisPanagiotis Tabakis
1,207719
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.
answered Nov 10 '18 at 0:35
Panagiotis TabakisPanagiotis Tabakis
1,207719
answered Nov 10 '18 at 0:35
Panagiotis TabakisPanagiotis Tabakis
1,207719
answered Nov 10 '18 at 0:35
Panagiotis TabakisPanagiotis Tabakis
1,207719
answered Nov 10 '18 at 0:35
Panagiotis TabakisPanagiotis Tabakis
1,207719
1,207719
3
Mine is pointing to/run/systemd/resolve/stub-resolv.confon 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.conffrom/run/systemd/resolve/stub-resolv.conffixed 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.confdid the trick.
– Igor Kupczyński
Jan 9 at 12:44
add a comment |
3
Mine is pointing to/run/systemd/resolve/stub-resolv.confon 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.conffrom/run/systemd/resolve/stub-resolv.conffixed 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.confdid the trick.
– Igor Kupczyński
Jan 9 at 12:44
3
3
Mine is pointing to
/run/systemd/resolve/stub-resolv.conf on an Ubuntu 18.10 instance.– datashaman
Nov 11 '18 at 6:14
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
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
This fixed the problem for me, too. Thx!
– Witek
Nov 26 '18 at 10:03
2
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
@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
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
add a comment |
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>
edited Oct 20 '18 at 0:16
Chai T. Rex
4,18611536
answered Jul 31 '18 at 19:29
Gregory SchultzGregory Schultz
182116
do you mind adding the link to the recommendation in your answer? It would be useful for others having the same issue. thanks!
– Leo
Aug 10 '18 at 3:03
1
github.com/ossec/ossec-hids/issues/1479
– Gregory Schultz
Aug 11 '18 at 10:16
not work in ubunto 18.04
– ajcg
7 hours ago
add a comment |
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>
edited Oct 20 '18 at 0:16
Chai T. Rex
4,18611536
answered Jul 31 '18 at 19:29
Gregory SchultzGregory Schultz
182116
do you mind adding the link to the recommendation in your answer? It would be useful for others having the same issue. thanks!
– Leo
Aug 10 '18 at 3:03
1
github.com/ossec/ossec-hids/issues/1479
– Gregory Schultz
Aug 11 '18 at 10:16
not work in ubunto 18.04
– ajcg
7 hours ago
add a comment |
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>
edited Oct 20 '18 at 0:16
Chai T. Rex
4,18611536
answered Jul 31 '18 at 19:29
Gregory SchultzGregory Schultz
182116
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>
edited Oct 20 '18 at 0:16
Chai T. Rex
4,18611536
answered Jul 31 '18 at 19:29
Gregory SchultzGregory Schultz
182116
edited Oct 20 '18 at 0:16
Chai T. Rex
4,18611536
edited Oct 20 '18 at 0:16
Chai T. Rex
4,18611536
edited Oct 20 '18 at 0:16
Chai T. Rex
4,18611536
4,18611536
answered Jul 31 '18 at 19:29
Gregory SchultzGregory Schultz
182116
answered Jul 31 '18 at 19:29
Gregory SchultzGregory Schultz
182116
answered Jul 31 '18 at 19:29
Gregory SchultzGregory Schultz
182116
182116
do you mind adding the link to the recommendation in your answer? It would be useful for others having the same issue. thanks!
– Leo
Aug 10 '18 at 3:03
1
github.com/ossec/ossec-hids/issues/1479
– Gregory Schultz
Aug 11 '18 at 10:16
not work in ubunto 18.04
– ajcg
7 hours ago
add a comment |
do you mind adding the link to the recommendation in your answer? It would be useful for others having the same issue. thanks!
– Leo
Aug 10 '18 at 3:03
1
github.com/ossec/ossec-hids/issues/1479
– Gregory Schultz
Aug 11 '18 at 10:16
not work in ubunto 18.04
– ajcg
7 hours ago
do you mind adding the link to the recommendation in your answer? It would be useful for others having the same issue. thanks!
– Leo
Aug 10 '18 at 3:03
do you mind adding the link to the recommendation in your answer? It would be useful for others having the same issue. thanks!
– Leo
Aug 10 '18 at 3:03
1
1
github.com/ossec/ossec-hids/issues/1479
– Gregory Schultz
Aug 11 '18 at 10:16
github.com/ossec/ossec-hids/issues/1479
– Gregory Schultz
Aug 11 '18 at 10:16
not work in ubunto 18.04
– ajcg
7 hours ago
not work in ubunto 18.04
– ajcg
7 hours ago
add a comment |
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.
edited Jul 25 '18 at 13:13
abu_bua
4,04181530
answered Jul 25 '18 at 10:52
RwkyRwky
1563
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
add a comment |
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.
edited Jul 25 '18 at 13:13
abu_bua
4,04181530
answered Jul 25 '18 at 10:52
RwkyRwky
1563
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
add a comment |
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.
edited Jul 25 '18 at 13:13
abu_bua
4,04181530
answered Jul 25 '18 at 10:52
RwkyRwky
1563
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.
edited Jul 25 '18 at 13:13
abu_bua
4,04181530
answered Jul 25 '18 at 10:52
RwkyRwky
1563
edited Jul 25 '18 at 13:13
abu_bua
4,04181530
edited Jul 25 '18 at 13:13
abu_bua
4,04181530
edited Jul 25 '18 at 13:13
abu_bua
4,04181530
4,04181530
answered Jul 25 '18 at 10:52
RwkyRwky
1563
answered Jul 25 '18 at 10:52
RwkyRwky
1563
answered Jul 25 '18 at 10:52
RwkyRwky
1563
1563
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
add a comment |
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
Added PTR record and haven't gotten a notice (so far). Thanks!
– Gregory Schultz
Jul 26 '18 at 1:09
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
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
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
add a comment |
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.
answered Dec 16 '18 at 19:57
Hermann KleinHermann Klein
212
Is there any way to discover what the unresolved names are?
– OrangeDog
Jan 2 at 10:53
add a comment |
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.
answered Dec 16 '18 at 19:57
Hermann KleinHermann Klein
212
Is there any way to discover what the unresolved names are?
– OrangeDog
Jan 2 at 10:53
add a comment |
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.
answered Dec 16 '18 at 19:57
Hermann KleinHermann Klein
212
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.
answered Dec 16 '18 at 19:57
Hermann KleinHermann Klein
212
edited Dec 16 '18 at 22:58
answered Dec 16 '18 at 19:57
Hermann KleinHermann Klein
212
answered Dec 16 '18 at 19:57
Hermann KleinHermann Klein
212
answered Dec 16 '18 at 19:57
Hermann KleinHermann Klein
212
212
Is there any way to discover what the unresolved names are?
– OrangeDog
Jan 2 at 10:53
add a comment |
Is there any way to discover what the unresolved names are?
– OrangeDog
Jan 2 at 10:53
Is there any way to discover what the unresolved names are?
– OrangeDog
Jan 2 at 10:53
Is there any way to discover what the unresolved names are?
– OrangeDog
Jan 2 at 10:53
add a comment |
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/
edited Feb 5 at 22:07
NIMISHAN
90131119
answered Feb 5 at 10:12
GuestGuest
111
add a comment |
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/
edited Feb 5 at 22:07
NIMISHAN
90131119
answered Feb 5 at 10:12
GuestGuest
111
add a comment |
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/
edited Feb 5 at 22:07
NIMISHAN
90131119
answered Feb 5 at 10:12
GuestGuest
111
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/
edited Feb 5 at 22:07
NIMISHAN
90131119
answered Feb 5 at 10:12
GuestGuest
111
edited Feb 5 at 22:07
NIMISHAN
90131119
edited Feb 5 at 22:07
NIMISHAN
90131119
edited Feb 5 at 22:07
NIMISHAN
90131119
90131119
answered Feb 5 at 10:12
GuestGuest
111
answered Feb 5 at 10:12
GuestGuest
111
answered Feb 5 at 10:12
GuestGuest
111
111
add a comment |
add a comment |
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.
answered Oct 24 '18 at 12:49
roschrosch
5,47411323
add a comment |
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.
answered Oct 24 '18 at 12:49
roschrosch
5,47411323
add a comment |
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.
answered Oct 24 '18 at 12:49
roschrosch
5,47411323
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.
answered Oct 24 '18 at 12:49
roschrosch
5,47411323
answered Oct 24 '18 at 12:49
roschrosch
5,47411323
answered Oct 24 '18 at 12:49
roschrosch
5,47411323
answered Oct 24 '18 at 12:49
roschrosch
5,47411323
5,47411323
add a comment |
add a comment |
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.
answered Mar 20 at 3:30
Dominic108Dominic108
1,14955
add a comment |
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.
answered Mar 20 at 3:30
Dominic108Dominic108
1,14955
add a comment |
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.
answered Mar 20 at 3:30
Dominic108Dominic108
1,14955
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.
answered Mar 20 at 3:30
Dominic108Dominic108
1,14955
edited Mar 20 at 16:37
answered Mar 20 at 3:30
Dominic108Dominic108
1,14955
answered Mar 20 at 3:30
Dominic108Dominic108
1,14955
answered Mar 20 at 3:30
Dominic108Dominic108
1,14955
1,14955
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1058750%2fnew-alert-keeps-showing-up-server-returned-error-nxdomain-mitigating-potential%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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