search

ungoogled-software / ungoogled-chromium

Google Chromium, sans integration with Google
BSD 3-Clause "New" or "Revised" License
20.8k stars 844 forks source link

Secure DNS fails on .works domain #2963

Closed Nifury closed 2 months ago

Nifury commented 3 months ago

When Secure DNS is turned on and set to use anything other than OS default, .works domain cannot be resolved and returns ERR_NAME_NOT_RESOLVED.

Example: https://howhttps.works/

I'm not sure if this issue is specific to UG, but I cannot reproduce it on Chrome.

teeminus commented 3 months ago

Have you tried to reproduce the problem on Linux?

PF4Public commented 3 months ago

Have you tried to reproduce the problem on Linux?

Can reproduce it on Linux: image

Nifury commented 3 months ago

Thank you, right as I was about to install a VM 😀

teeminus commented 3 months ago

Do you want to move this issue to the core repo?

PF4Public commented 3 months ago

We could've just moved the issue there…

Nifury commented 3 months ago

We could've just moved the issue there…

Ah I didn't know the issue could be literally moved. Shall I close the issue in the core repo?

PF4Public commented 3 months ago

@Ahrotahn Could you reproduce this issue on your system?

rany2 commented 3 months ago

It might have nothing to do with .works. I could resolve 19216811.works for example, maybe the fact that the domain contains https is the problem?

Ahrotahn commented 3 months ago

I can reproduce this. It only seems to be an issue for howhttps.works, other .works addresses function normally like the one @rany2 mentioned.

Even weirder, if you visit howhttps.works once without secure DNS enabled then the site will work fine afterwards once it's re-enabled. This works on other pages on the domain and with a hard refresh so it isn't just a cached version of the page.

PF4Public commented 3 months ago

Even weirder, if you visit howhttps.works once without secure DNS enabled then the site will work fine afterwards once it's re-enabled. This works on other pages on the domain and with a hard refresh so it isn't just a cached version of the page.

Same for me.

networkException commented 3 months ago

maybe something to do with HSTS?

alienbob commented 3 months ago

I just upgraded to my fresh Un-Googled Chromium 127 on Slackware, switched on Secure DNS and accessed https://howhttps.works/ . It works, No errors or issues and I get to see the page - and I honestly never visited this URL before, did not knw of its existence. Examining the network interactions (which I did activate via Developer Tools before accessing this URL for the first time) I only see loading error for https://tag.getdrip.com/9686301.js due to Referrer Policy: "strict-origin-when-cross-origin".

rany2 commented 3 months ago

@alienbob Did you access it without secure DNS beforehand? See https://github.com/ungoogled-software/ungoogled-chromium/issues/2963#issuecomment-2256554151

alienbob commented 3 months ago

@alienbob Did you access it without secure DNS beforehand? See #2963 (comment)

Nope. As I said (but perhaps not explicitly enough) , I had never even heard of the site, and turned on Secure DNS before accessing that URL for the first time.

Ahrotahn commented 3 months ago

So I figured out what's going on. An IPv6 check is being performed (I guess due to the site having an IPv6 address available?) and add-ipv6-probing-option.patch is forcing a true value unless --enable-features=SetIpv6ProbeFalse/chrome://flags/#set-ipv6-probe-false is set. Enabling that flag allows the site to function normally for me.

I think it'll be a good idea to update that patch to return the actual result rather than always assuming true. Then the flag could just override that value. Alternatively we could default to false since it does that already for those on wifi: https://source.chromium.org/chromium/chromium/src/+/refs/tags/127.0.6533.72:net/dns/host_resolver_manager.cc;l=1423-1430

I assume that @alienbob has IPv6 connectivity and that those of us encountering the issue don't?
Edit: Looks like I had that backwards then

Nifury commented 3 months ago

Interesting finding! I do have IPv6 connectivity and the site seems to return IPv4 addresses only, but enabling that flag works for me as well.

alienbob commented 3 months ago

I assume that @alienbob has IPv6 connectivity and that those of us encountering the issue don't?

I don't have IPv6 connectivity where I ran the test.

rany2 commented 3 months ago

I do have IPv6 connectivity, that's not it.... Sorry :(

PF4Public commented 3 months ago

IPv4-only host:

$ nslookup howhttps.works
[...]
Non-authoritative answer:
Name:   howhttps.works
Address: ***IPv4***
Name:   howhttps.works
Address: ***IPv4***

IPv6+IPv4 host:

$ nslookup howhttps.works
[...]
Non-authoritative answer:
Name:   howhttps.works
Address: ***IPv4***
Name:   howhttps.works
Address: ***IPv4***
** server can't find howhttps.works: SERVFAIL

The last one is actually trying to resolve AAAA, but fails: image

So it might indeed be trying to resolve IPv6 through DoH and fails to connect.

Calling DoH with dns-query?name=howhttps.works&type=a I get IPv4; calling with dns-query?name=howhttps.works&type=aaaa I predictably get nothing.

BTW: Compare that to any other IPv4-only domain. They all have something even for aaaa, but not howhttps.works, so it might be the domain that is bugged.

BTW BTW: Google says: "DNSSEC validation failure." and "Invalid denial of existence of howhttps.works/aaaa". https://dns.google/resolve?name=howhttps.works&type=aaaa

PF4Public commented 2 months ago

So I'm closing this as wontfix unless we get more of similarly troubling websites.