Why does Chromium report NXDOMAIN when a domain resolves successfully
I was surprised to see this error message in Chromium on Ubuntu 18.04 when trying to view an image in a post on a StackExchange site:
This site can’t be reached
i.stack.imgur.com’s server IP address could not be found.
DNS_PROBE_FINISHED_NXDOMAIN
In an attempt to find out what was happening I tried to run tcpdump to look at the DNS requests and responses. I attempted to reload the image giving me the error and this was the DNS traffic that I saw:
# tcpdump -pni any 'port 53'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
20:10:17.618041 IP 127.0.0.1.42714 > 127.0.0.53.53: 3068+ A? i.stack.imgur.com. (35)
20:10:17.618080 IP 127.0.0.1.42714 > 127.0.0.53.53: 23569+ AAAA? i.stack.imgur.com. (35)
20:10:17.618861 IP 127.0.0.53.53 > 127.0.0.1.42714: 3068 13/0/0 CNAME i.stack.imgur.com.cdn.cloudflare.net., A 104.16.0.35, A 104.16.26.34, A 104.16.2.35, A 104.16.30.34, A 104.16.28.34, A 104.16.24.34, A 104.16.25.34, A 104.16.29.34, A 104.16.27.34, A 104.16.3.35, A 104.16.1.35, A 104.16.31.34 (277)
20:10:17.619395 IP 127.0.0.53.53 > 127.0.0.1.42714: 23569| 16/0/0 CNAME i.stack.imgur.com.cdn.cloudflare.net., AAAA 2001:67c:2b0:db32:0:1:6810:1f22, AAAA 2001:67c:2b0:db32:0:1:6810:1b22, AAAA 64:ff9b::6810:23, AAAA 2001:67c:2b0:db32:0:1:6810:223, AAAA 2001:67c:27e4:64::6810:123, AAAA 64:ff9b::6810:1f22, AAAA 2001:67c:27e4:64::6810:1f22, AAAA 2001:67c:27e4:64::6810:223, AAAA 2001:67c:27e4:64::6810:1b22, AAAA 2001:67c:27e4:64::6810:1922, AAAA 2001:67c:2b0:db32:0:1:6810:1d22, AAAA 64:ff9b::6810:123, AAAA 2001:67c:2b0:db32:0:1:6810:1e22, AAAA 64:ff9b::6810:1822, AAAA 2001:67c:2b0:db32:0:1:6810:1822 (505)
As you can see the DNS resolution succeeded. But Chromium was still showing me the same NXDOMAIN error message. What could cause Chromium to report NXDOMAIN when the lookups were indeed successful?
chromium
asked Jan 3 at 19:22
kasperdkasperd
9611732
add a comment |
I was surprised to see this error message in Chromium on Ubuntu 18.04 when trying to view an image in a post on a StackExchange site:
This site can’t be reached
i.stack.imgur.com’s server IP address could not be found.
DNS_PROBE_FINISHED_NXDOMAIN
In an attempt to find out what was happening I tried to run tcpdump to look at the DNS requests and responses. I attempted to reload the image giving me the error and this was the DNS traffic that I saw:
# tcpdump -pni any 'port 53'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
20:10:17.618041 IP 127.0.0.1.42714 > 127.0.0.53.53: 3068+ A? i.stack.imgur.com. (35)
20:10:17.618080 IP 127.0.0.1.42714 > 127.0.0.53.53: 23569+ AAAA? i.stack.imgur.com. (35)
20:10:17.618861 IP 127.0.0.53.53 > 127.0.0.1.42714: 3068 13/0/0 CNAME i.stack.imgur.com.cdn.cloudflare.net., A 104.16.0.35, A 104.16.26.34, A 104.16.2.35, A 104.16.30.34, A 104.16.28.34, A 104.16.24.34, A 104.16.25.34, A 104.16.29.34, A 104.16.27.34, A 104.16.3.35, A 104.16.1.35, A 104.16.31.34 (277)
20:10:17.619395 IP 127.0.0.53.53 > 127.0.0.1.42714: 23569| 16/0/0 CNAME i.stack.imgur.com.cdn.cloudflare.net., AAAA 2001:67c:2b0:db32:0:1:6810:1f22, AAAA 2001:67c:2b0:db32:0:1:6810:1b22, AAAA 64:ff9b::6810:23, AAAA 2001:67c:2b0:db32:0:1:6810:223, AAAA 2001:67c:27e4:64::6810:123, AAAA 64:ff9b::6810:1f22, AAAA 2001:67c:27e4:64::6810:1f22, AAAA 2001:67c:27e4:64::6810:223, AAAA 2001:67c:27e4:64::6810:1b22, AAAA 2001:67c:27e4:64::6810:1922, AAAA 2001:67c:2b0:db32:0:1:6810:1d22, AAAA 64:ff9b::6810:123, AAAA 2001:67c:2b0:db32:0:1:6810:1e22, AAAA 64:ff9b::6810:1822, AAAA 2001:67c:2b0:db32:0:1:6810:1822 (505)
As you can see the DNS resolution succeeded. But Chromium was still showing me the same NXDOMAIN error message. What could cause Chromium to report NXDOMAIN when the lookups were indeed successful?
chromium
asked Jan 3 at 19:22
kasperdkasperd
9611732
I am suspecting a bug in handling of truncated DNS responses. But I don't have definitive evidence of that yet.
– kasperd
Jan 3 at 19:50
add a comment |
I was surprised to see this error message in Chromium on Ubuntu 18.04 when trying to view an image in a post on a StackExchange site:
This site can’t be reached
i.stack.imgur.com’s server IP address could not be found.
DNS_PROBE_FINISHED_NXDOMAIN
In an attempt to find out what was happening I tried to run tcpdump to look at the DNS requests and responses. I attempted to reload the image giving me the error and this was the DNS traffic that I saw:
# tcpdump -pni any 'port 53'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
20:10:17.618041 IP 127.0.0.1.42714 > 127.0.0.53.53: 3068+ A? i.stack.imgur.com. (35)
20:10:17.618080 IP 127.0.0.1.42714 > 127.0.0.53.53: 23569+ AAAA? i.stack.imgur.com. (35)
20:10:17.618861 IP 127.0.0.53.53 > 127.0.0.1.42714: 3068 13/0/0 CNAME i.stack.imgur.com.cdn.cloudflare.net., A 104.16.0.35, A 104.16.26.34, A 104.16.2.35, A 104.16.30.34, A 104.16.28.34, A 104.16.24.34, A 104.16.25.34, A 104.16.29.34, A 104.16.27.34, A 104.16.3.35, A 104.16.1.35, A 104.16.31.34 (277)
20:10:17.619395 IP 127.0.0.53.53 > 127.0.0.1.42714: 23569| 16/0/0 CNAME i.stack.imgur.com.cdn.cloudflare.net., AAAA 2001:67c:2b0:db32:0:1:6810:1f22, AAAA 2001:67c:2b0:db32:0:1:6810:1b22, AAAA 64:ff9b::6810:23, AAAA 2001:67c:2b0:db32:0:1:6810:223, AAAA 2001:67c:27e4:64::6810:123, AAAA 64:ff9b::6810:1f22, AAAA 2001:67c:27e4:64::6810:1f22, AAAA 2001:67c:27e4:64::6810:223, AAAA 2001:67c:27e4:64::6810:1b22, AAAA 2001:67c:27e4:64::6810:1922, AAAA 2001:67c:2b0:db32:0:1:6810:1d22, AAAA 64:ff9b::6810:123, AAAA 2001:67c:2b0:db32:0:1:6810:1e22, AAAA 64:ff9b::6810:1822, AAAA 2001:67c:2b0:db32:0:1:6810:1822 (505)
As you can see the DNS resolution succeeded. But Chromium was still showing me the same NXDOMAIN error message. What could cause Chromium to report NXDOMAIN when the lookups were indeed successful?
chromium
asked Jan 3 at 19:22
kasperdkasperd
9611732
I was surprised to see this error message in Chromium on Ubuntu 18.04 when trying to view an image in a post on a StackExchange site:
This site can’t be reached
i.stack.imgur.com’s server IP address could not be found.
DNS_PROBE_FINISHED_NXDOMAIN
In an attempt to find out what was happening I tried to run tcpdump to look at the DNS requests and responses. I attempted to reload the image giving me the error and this was the DNS traffic that I saw:
# tcpdump -pni any 'port 53'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
20:10:17.618041 IP 127.0.0.1.42714 > 127.0.0.53.53: 3068+ A? i.stack.imgur.com. (35)
20:10:17.618080 IP 127.0.0.1.42714 > 127.0.0.53.53: 23569+ AAAA? i.stack.imgur.com. (35)
20:10:17.618861 IP 127.0.0.53.53 > 127.0.0.1.42714: 3068 13/0/0 CNAME i.stack.imgur.com.cdn.cloudflare.net., A 104.16.0.35, A 104.16.26.34, A 104.16.2.35, A 104.16.30.34, A 104.16.28.34, A 104.16.24.34, A 104.16.25.34, A 104.16.29.34, A 104.16.27.34, A 104.16.3.35, A 104.16.1.35, A 104.16.31.34 (277)
20:10:17.619395 IP 127.0.0.53.53 > 127.0.0.1.42714: 23569| 16/0/0 CNAME i.stack.imgur.com.cdn.cloudflare.net., AAAA 2001:67c:2b0:db32:0:1:6810:1f22, AAAA 2001:67c:2b0:db32:0:1:6810:1b22, AAAA 64:ff9b::6810:23, AAAA 2001:67c:2b0:db32:0:1:6810:223, AAAA 2001:67c:27e4:64::6810:123, AAAA 64:ff9b::6810:1f22, AAAA 2001:67c:27e4:64::6810:1f22, AAAA 2001:67c:27e4:64::6810:223, AAAA 2001:67c:27e4:64::6810:1b22, AAAA 2001:67c:27e4:64::6810:1922, AAAA 2001:67c:2b0:db32:0:1:6810:1d22, AAAA 64:ff9b::6810:123, AAAA 2001:67c:2b0:db32:0:1:6810:1e22, AAAA 64:ff9b::6810:1822, AAAA 2001:67c:2b0:db32:0:1:6810:1822 (505)
As you can see the DNS resolution succeeded. But Chromium was still showing me the same NXDOMAIN error message. What could cause Chromium to report NXDOMAIN when the lookups were indeed successful?
chromium
chromium
asked Jan 3 at 19:22
kasperdkasperd
9611732
asked Jan 3 at 19:22
kasperdkasperd
9611732
asked Jan 3 at 19:22
kasperdkasperd
9611732
asked Jan 3 at 19:22
kasperdkasperd
9611732
asked Jan 3 at 19:22
kasperdkasperd
9611732
9611732
I am suspecting a bug in handling of truncated DNS responses. But I don't have definitive evidence of that yet.
– kasperd
Jan 3 at 19:50
add a comment |
I am suspecting a bug in handling of truncated DNS responses. But I don't have definitive evidence of that yet.
– kasperd
Jan 3 at 19:50
I am suspecting a bug in handling of truncated DNS responses. But I don't have definitive evidence of that yet.
– kasperd
Jan 3 at 19:50
I am suspecting a bug in handling of truncated DNS responses. But I don't have definitive evidence of that yet.
– kasperd
Jan 3 at 19:50
add a comment |
1 Answer
1
active
oldest
votes
See launchpad bugs 1804487 and 1805027 for the systemd-resolve problem. Workarounds
1) Add package libnss-resolve.
2) Use a nameserver directly in /etc/resolve.conf s link (or redirect link from /run/systemd/resolve/stub-resolve.conf to /run/systemd/resolve/resolve.conf
edited Jan 4 at 0:18
kasperd
9611732
answered Jan 3 at 23:03
ubfan1ubfan1
9,28641527
This answer is surely helpful, but it cannot be the full story. As seen from the packet trace in my question only theAAAAlookups result in an answer large enough to trigger the bug. Since Chromium supposedly follows RFC 8305 the successfulAlookups should have allowed Chromium to still load the page even if theAAAAlookups were failing. I found another quite unexpected workaround. I shut down the DHCP server on my router such that my LAN is effectively IPv6-only, and now I can accessi.stack.imgur.comwithout any problems.
– kasperd
Jan 4 at 17:23
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%2f1106691%2fwhy-does-chromium-report-nxdomain-when-a-domain-resolves-successfully%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
See launchpad bugs 1804487 and 1805027 for the systemd-resolve problem. Workarounds
1) Add package libnss-resolve.
2) Use a nameserver directly in /etc/resolve.conf s link (or redirect link from /run/systemd/resolve/stub-resolve.conf to /run/systemd/resolve/resolve.conf
edited Jan 4 at 0:18
kasperd
9611732
answered Jan 3 at 23:03
ubfan1ubfan1
9,28641527
This answer is surely helpful, but it cannot be the full story. As seen from the packet trace in my question only theAAAAlookups result in an answer large enough to trigger the bug. Since Chromium supposedly follows RFC 8305 the successfulAlookups should have allowed Chromium to still load the page even if theAAAAlookups were failing. I found another quite unexpected workaround. I shut down the DHCP server on my router such that my LAN is effectively IPv6-only, and now I can accessi.stack.imgur.comwithout any problems.
– kasperd
Jan 4 at 17:23
add a comment |
See launchpad bugs 1804487 and 1805027 for the systemd-resolve problem. Workarounds
1) Add package libnss-resolve.
2) Use a nameserver directly in /etc/resolve.conf s link (or redirect link from /run/systemd/resolve/stub-resolve.conf to /run/systemd/resolve/resolve.conf
edited Jan 4 at 0:18
kasperd
9611732
answered Jan 3 at 23:03
ubfan1ubfan1
9,28641527
This answer is surely helpful, but it cannot be the full story. As seen from the packet trace in my question only theAAAAlookups result in an answer large enough to trigger the bug. Since Chromium supposedly follows RFC 8305 the successfulAlookups should have allowed Chromium to still load the page even if theAAAAlookups were failing. I found another quite unexpected workaround. I shut down the DHCP server on my router such that my LAN is effectively IPv6-only, and now I can accessi.stack.imgur.comwithout any problems.
– kasperd
Jan 4 at 17:23
add a comment |
See launchpad bugs 1804487 and 1805027 for the systemd-resolve problem. Workarounds
1) Add package libnss-resolve.
2) Use a nameserver directly in /etc/resolve.conf s link (or redirect link from /run/systemd/resolve/stub-resolve.conf to /run/systemd/resolve/resolve.conf
edited Jan 4 at 0:18
kasperd
9611732
answered Jan 3 at 23:03
ubfan1ubfan1
9,28641527
See launchpad bugs 1804487 and 1805027 for the systemd-resolve problem. Workarounds
1) Add package libnss-resolve.
2) Use a nameserver directly in /etc/resolve.conf s link (or redirect link from /run/systemd/resolve/stub-resolve.conf to /run/systemd/resolve/resolve.conf
edited Jan 4 at 0:18
kasperd
9611732
answered Jan 3 at 23:03
ubfan1ubfan1
9,28641527
edited Jan 4 at 0:18
kasperd
9611732
edited Jan 4 at 0:18
kasperd
9611732
edited Jan 4 at 0:18
kasperd
9611732
9611732
answered Jan 3 at 23:03
ubfan1ubfan1
9,28641527
answered Jan 3 at 23:03
ubfan1ubfan1
9,28641527
answered Jan 3 at 23:03
ubfan1ubfan1
9,28641527
9,28641527
This answer is surely helpful, but it cannot be the full story. As seen from the packet trace in my question only theAAAAlookups result in an answer large enough to trigger the bug. Since Chromium supposedly follows RFC 8305 the successfulAlookups should have allowed Chromium to still load the page even if theAAAAlookups were failing. I found another quite unexpected workaround. I shut down the DHCP server on my router such that my LAN is effectively IPv6-only, and now I can accessi.stack.imgur.comwithout any problems.
– kasperd
Jan 4 at 17:23
add a comment |
This answer is surely helpful, but it cannot be the full story. As seen from the packet trace in my question only theAAAAlookups result in an answer large enough to trigger the bug. Since Chromium supposedly follows RFC 8305 the successfulAlookups should have allowed Chromium to still load the page even if theAAAAlookups were failing. I found another quite unexpected workaround. I shut down the DHCP server on my router such that my LAN is effectively IPv6-only, and now I can accessi.stack.imgur.comwithout any problems.
– kasperd
Jan 4 at 17:23
This answer is surely helpful, but it cannot be the full story. As seen from the packet trace in my question only the
AAAA lookups result in an answer large enough to trigger the bug. Since Chromium supposedly follows RFC 8305 the successful A lookups should have allowed Chromium to still load the page even if the AAAA lookups were failing. I found another quite unexpected workaround. I shut down the DHCP server on my router such that my LAN is effectively IPv6-only, and now I can access i.stack.imgur.com without any problems.– kasperd
Jan 4 at 17:23
This answer is surely helpful, but it cannot be the full story. As seen from the packet trace in my question only the
AAAA lookups result in an answer large enough to trigger the bug. Since Chromium supposedly follows RFC 8305 the successful A lookups should have allowed Chromium to still load the page even if the AAAA lookups were failing. I found another quite unexpected workaround. I shut down the DHCP server on my router such that my LAN is effectively IPv6-only, and now I can access i.stack.imgur.com without any problems.– kasperd
Jan 4 at 17:23
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%2f1106691%2fwhy-does-chromium-report-nxdomain-when-a-domain-resolves-successfully%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
I am suspecting a bug in handling of truncated DNS responses. But I don't have definitive evidence of that yet.
– kasperd
Jan 3 at 19:50