Closed omgold closed 1 year ago
I remember I have written the logic to detect long packets or truncated packets. Maybe it didn't work for some reason…
Hi @m13253 – I can confirm the bug in ArchLinux version community/dns-over-https 2.3.2-1
> host asana-user-private-us-east-1.s3.amazonaws.com
Host asana-user-private-us-east-1.s3.amazonaws.com not found: 2(SERVFAIL)
> host asana-user-private-us-east-1.s3.amazonaws.com 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases:
asana-user-private-us-east-1.s3.amazonaws.com is an alias for s3-1-w.amazonaws.com.
s3-1-w.amazonaws.com is an alias for s3-w.us-east-1.amazonaws.com.
s3-w.us-east-1.amazonaws.com has address 3.5.21.101
s3-w.us-east-1.amazonaws.com has address 52.216.110.35
s3-w.us-east-1.amazonaws.com has address 3.5.11.228
s3-w.us-east-1.amazonaws.com has address 52.217.133.193
s3-w.us-east-1.amazonaws.com has address 52.217.84.52
s3-w.us-east-1.amazonaws.com has address 52.217.134.57
s3-w.us-east-1.amazonaws.com has address 54.231.197.217
s3-w.us-east-1.amazonaws.com has address 3.5.10.23
Same error on latest commit 70fc857
Thanks for the reports. Will spend some time investigating it.
Do we need a new release for this bug fix?
I used dig
with dns-over-https and it returned the answers correctly, while host
complained for bad packets (same as the issue).
I think these were something happening that resulted UDP packet chunked with the connection between host
and doh-client
.
Do we need a new release for this bug fix?
If it get fixed, definitely we need to bump the version number. I am currently trying to reproduce this bug along with @GreenYun.
I guess the problem is that, host
doesn’t support large UDP packets, while doh-client
mistakenly thought host
does support it (probably due to a mistake in parsing EDNS data).
Meanwhile, most modern DNS resolvers does support large UDP packets. For host
, you can use -T
to temporarily force TCP.
I think this logic is correct… Not sure why it doesn’t work. https://github.com/m13253/dns-over-https/blob/70fc8578c7acd39b76f9ef074290c582f6d446c9/doh-client/ietf.go#L241-L249
Please test the newer version fdc1b81e4224dbed8fd7372f79679de98504ecec and let me know if it fixes the problem.
Do we need a new release for this bug fix?
If it get fixed, definitely we need to bump the version number. I am currently trying to reproduce this bug along with @GreenYun.
I guess the problem is that,
host
doesn’t support large UDP packets, whiledoh-client
mistakenly thoughthost
does support it (probably due to a mistake in parsing EDNS data). Meanwhile, most modern DNS resolvers does support large UDP packets. Forhost
, you can use-T
to temporarily force TCP.
It is correct that host
does not send OPT part to announce a maximum UDP packet data size, while dig
does. That means host
only accepts a 512-byte datagram of the response.
The source code of host
shows that it parses the datagram first then check the TC bit for redoing the lookup via TCP. The truncated diagram may lead an error of malform data, as the following shows:
After the processing, host
checks the TC bit and requeue a further lookup:
Hi @m13253 - At the first glance it looks good. Thank you very much for the quick fix, it’s highly appreciated since I love the doh client. Tomorrow, I am gonna test it at home where I first stumbled across the error, but at work I have an almost identical setup.
Hi @omgold - can you confirm this?
Hi @GreenYun - thanks for checking host
. In my case it is not about host
itself, I was not able to open Netflix and some more in Firefox or Chromium.
Yes. for me the fix works also.
Hi @m13253 - At the first glance it looks good. Thank you very much for the quick fix, it’s highly appreciated since I love the doh client. Tomorrow, I am gonna test it at home where I first stumbled across the error, but at work I have an almost identical setup.
Hi @omgold - can you confirm this?
Hi @GreenYun - thanks for checking
host
. In my case it is not abouthost
itself, I was not able to open Netflix and some more in Firefox or Chromium.
Checking host
helped us to know how the TC bit work and found the problems. We have mistaken something before.
Do we need a new release for this bug fix?
I published the v2.3.3 release to include this fix. This fix solved a bug so I want to push it to downstream sooner.
I will generate new container image tonight
v2.3.3 container image released. Local tests passed.
v2.3.3 container image released. Local tests passed.
Big thanks!
Since some days ago, resolving www.netflix.com through dns-over-https fails for some unknown reason. It doesn't seem to be an upstream problem and all other domains I try work as expected.
I'm running version 2.3.2 on Arch Linux.
Upstream is configured like this:
When using the host command, I get this:
But everything seems fine when asking upstream directly:
The only unusual thing I see about Netflix is the rather long list of results. Could imagine there is a limit on message size in dns-over-https which is exceeded because of that.