CoreDNS misbehaving for outside Kuberentes queries #2289
Comments
|
It is related but it is a little different. DNS Tools nslookup Output DNS Tools dig Output |
|
Assuming you are not routing nslookup does these queries because it follows the search domains in So, it seems, with nslookup that the upstream dns server answers 2 queries, then ignores the third. |
|
Exactly, I have defined |
No, i don't think it would. Perhaps there are intermittent connectivity issues to the upstream server... When you use nslookup, does it always fail on the same domain? or does it randomly fail. |
|
As you said removing After 1st execution of nslookup after dig After 2nd execution of nslookup after dig |
Confounding. What happens when you query the upstream servers directly using nslookup? e.g. |
|
What about with dig +search ?
…On Tue, Nov 13, 2018 at 9:18 AM chrisohaver ***@***.***> wrote:
nslookup always fails on acme-v02.api.letsencrypt.org ...
nslookup and dig work perfectly fine on google.com
Confounding.
What happens when you query the upstream servers directly using nslookup?
e.g.
nslookup acme-v02.api.letsencrypt.org <upstream-dns-ip>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2289 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AJB4s0vefbsavkmshUJV84yaT_WXc6fgks5uuv7EgaJpZM4YZMTV>
.
|
DNS query works perfectly. Here is the output:
|
|
The response is quite large. Could be related to compression/truncation? And one of the responses above shows a TCP fallback due to truncation. We recently fixed some compression/truncation issues. What CoreDNS version are you using? |
|
dig sets EDNS0 by default with buffer size 4096. I bet nslookup does not...
…On Tue, Nov 13, 2018 at 12:09 PM chrisohaver ***@***.***> wrote:
The response is quite large. Could be related to compression/truncation?
And one of the responses above shows a TCP fallback due to truncation. We
recently fixed some compression/truncation issues.
What CoreDNS version you are using?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2289 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AJB4s6fkO5R7ks36feIyIfIqcmKG9fZpks5uuybmgaJpZM4YZMTV>
.
|
|
try
dig +search +noedns
On Tue, Nov 13, 2018 at 12:18 PM John Belamaric <jbelamaric@google.com>
wrote:
… dig sets EDNS0 by default with buffer size 4096. I bet nslookup does not...
On Tue, Nov 13, 2018 at 12:09 PM chrisohaver ***@***.***>
wrote:
> The response is quite large. Could be related to compression/truncation?
> And one of the responses above shows a TCP fallback due to truncation. We
> recently fixed some compression/truncation issues.
>
> What CoreDNS version you are using?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#2289 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AJB4s6fkO5R7ks36feIyIfIqcmKG9fZpks5uuybmgaJpZM4YZMTV>
> .
>
|
Yeah - if this is a compression/truncation issue, then the expectation is that this would fail in the same way as Would be good to confirm before upgrading to latest CoreDNS, if indeed you are on an older version. |
Yes, maybe. I wanted to try DoT (DNS over TLS) so that I could possibly fix this issues and also prevent possible intervention by ISP. Do you think that this might help me in this case?
k8s.gcr.io/coredns:1.2.2
|
Yes, they are servfailing ...
Try k8s.gcr.io/coredns:1.2.6, this has a fix for compression/truncation (#2261). I don't know for certain that it will fix this specific issue, but its wort a try. |
|
I will try and share my results here. Thank you very much for your support. |
|
the dig output in #2289 (comment) looks bat shit crazy. Either something is interfering with your request or coredns is doing some very wrong. |
I assumed it was a copy paste issue, or misplaced newlines due to scrubbing. |
|
There was a little problem in copy paste. I fixed it, sorry. I updated CoreDNS to k8s.gcr.io/coredns:1.2.6. But it didn't help. But I experimented something that might help. I ran the same DNS queries on a host without CoreDNS they were pretty large. Both of the results were successful but very large. The authority section of both of them looked the same. But I tried these queries on a host with a different network. There was no authority section (which is how it should be) and the response was smaller. It seems that there may be a problem with CoreDNS handling large DNS queries. Because both nslookup and dig are succesful in querying DNS using upstream defined in the |
|
[ Quoting <notifications@github.com> in "Re: [coredns/coredns] CoreDNS misbe..." ]
I updated CoreDNS to k8s.gcr.io/coredns:1.2.6. But it didn't help. But I experimented something that might help.
I ran the same DNS queries on a host without CoreDNS they were pretty large. Both of the results were successful but very large. The authority section of both of them looked the same. But I tried these queries on a host with a different network. There was no authority section (which is how it should be) and the response was smaller. It seems that there may be a problem with CoreDNS handling large DNS queries.
can you tcpdump on either sides?
|
|
I also had this problem |
|
|
|
same problem |
|
@liupeng0518 In my travels I've seen a lot of other posts in regards to a busybox specific issue. You might want to look into that and rule that out as a possibility. |
|
@liupeng0518, Any version of busybox > 1.28 has a broken nslookup that ignores search domains. |
|
not the busybox，It's no error when I use the image with net-tools test at the kube-dns， I saw the errors when I use the coredns and the same images。 |
|
This looks stale or solved. Closing |
|
In my case, it is very strange, And I wonder, when will coredns version: 1.6.2 Here is the resolve output: |
CoreDNS fails to respond to queries relating to the outside Kuberntes cluster. I have enabled logging in my configuration.
The text was updated successfully, but these errors were encountered: