Closed Bug 1831001 Opened 3 years ago Closed 3 years ago

prudential.com not findable -- DNS over HTTPS enabling problem?

Categories

(Core :: Networking: DNS, defect)

Firefox 112
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jeff, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/112.0

Steps to reproduce:

For the last several days, when I tried to access prudential.com via
Firefox (either on Windows 10 or 11), Firefox said the site could not be
found. I verified this on a number of devices, as well as with Edge and
Chrome. That made me think it was a DNS problem. I had never changed
any of the Firefox "DNS over HTTPS" settings, which said "Use system
proxy settings", "Enable DNS over HTTPS", and "Cloudflare (Default)".

I decided to try changing DoH from the default CloudFlare to NextDNS, as
the easiest way to test with a different DNS. Now prudential.com COULD
be found, at least by Firefox. The other browsers were still using
whatever Windows provided; they still failed to find prudential.com.

To check this further, I switched back to CloudFlare. I was surprised
that prudential.com was still findable. I tried clearing history and
rebooting. It still was found. This makes me wonder if the supposedly
enabled DoH was ever working to begin with, i.e., was it really enabled
and using Cloudflare, or was Firefox actually using whatever DNS Windows
provides? Did switching to NextDNS and then back to Cloudflare cause a
sleeping DoH to be enabled? Maybe this peculiarity only shows up on
systems that have never previously changed that DoH DNS setting.

Meanwhile, Edge and Chrome still reliably FAIL to find prudential.com,
since there seems to be a problem with the DNS that Windows provides by
default. I did not try to change the Windows DNS setting to verify
this.

Actual results:

prudential.com not found

Expected results:

prudential.com found

The Bugbug bot thinks this bug should belong to the 'Core::Networking: DNS' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Networking: DNS
Product: Firefox → Core

That's quite interesting. Could you check and see if you can reproduce this in the latest nightly? https://nightly.mozilla.org
The DNS over HTTPS settings are not at the bottom of about:preferences#privacy
If you could also capture some logs, that would be great.
See instructions here: https://firefox-source-docs.mozilla.org/networking/http/logging.html

Flags: needinfo?(jeff)

Did you confirm the inability for Edge (or Google Chrome) to find
prudential.com when I reported the possible Firefox problem that
inability exposed?

That likely Windows problem still existed last night when I tested with
Edge and Google Chrome. However I guess Microsoft finally got the word
and fixed something since then. (The problem had existed for at least
three days.) This afternoon Edge and Chrome can finally find
prudential.com. That may make it harder to detect the Firefox bug I
thought I detected (DoH not really enabled until it is toggled from
CloudFlare to NextDNS, then back to Cloudflare.)

I'm still willing to try to get the logs you mentioned, but I now won't
be able to see that Firefox failed to find prudential.com before the DNS
toggle because it was actually still using the Windows DNS. I assume
from the logs you will be able to see if DoH is invoked (before the
toggle) as it is supposed to be, or if Firefox is still using the
Windows-specified DNS even though it says DoH is enabled from the start.

I can do this on a test PC that I have to set up now. First deleting
Firefox from that PC, then installing the nightly. I'll note what the
DoH settings are after the fresh install, but won't change anything at
this point. Then while logging I'll have Firefox try to access
prudential.com. However that will probably work now (because Windows
seems to have fixed their DNS) even though Firefox isn't supposed to be
using the Windows DNS if DoH is really initially enabled. I'll then do
the toggle between the two NoH DNS's and finally try to access
prudential.com again. Do I need to clear the cache before trying this
post-toggle access attempt? Presumably if the first attempt worked, a
DNS search won't be required and DoH won't get invoked. Do you really
need the log for that post-toggle access attempt? The potential bug is
before the toggle, not after it.

Is the above what you need? Is there some other scenario that should be
tested, e.g., freshly installing the current Firefox vs the nightly and
doing the above?

Flags: needinfo?(jeff)

OK, I installed the nightly and see the DoH user interface for settings
is no longer as in the current 112.0.2 Firefox where I had the problem.
I didn't change anything in the new DoH settings. Default Protection
was the button pre-clicked, so I assume it would run with that setting.

I set up logging and started logging, then had Firefox try to access
prudential.com, then stopped logging. There was no problem accessing
prudential.com. That was as expected since Windows seems to have fixed
its DNS bug, so I couldn't tell if Firefox was using the Windows DNS (a
DoH bug) or using the DoH DNS (as I wanted). Hopefully the log has what
you needed. Maybe the new DoH has fixed the bug if indeed it had
existed in the prior DoH. I can't tell without doing something to
cripple the Windows DNS; I don't want to do that. Maybe someone else
can. Since in the new UI there is no way to toggle between two specific
DNSs, I just did the one log.

I put the log on Google My Drive:
https://drive.google.com/file/d/1J3mgR-UErYzCHU-0S2QCHKnZsbPIYeA6/view?usp=sharing

Note that my test PC was running Windows 11. It was one of the PCs on
which I previously had recreated reliably the prudential.com problems.
The other three PCs on which I had shown the bug were running Windows
10.

So, from what I understand, the domain now works on all your computers and all browsers?
If that's the case, I assume there was an issue with the prudential.com and now it works.
Looking at the logs, it seems all of the loads of prudential.com completed successfully. Let me know if I'm wrong.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME

Thanks, Valentin. All seems to be OK now. I don't think it was a
Prudential problem. When the problem existed I also hit it for another
site. When the Prudential problem disappeared, the other site also
again became findable. Because of the same symptoms with non-Firefox
browsers on multiple devices and the ability to get around it in Firefox
by toggling the DoH settings, I think it was a temporary (about
three-day) problem with the Windows DNS. The related Firefox DoH
initial settings problem either never existed or was a user error. I
have not seen the symptoms again with the current Firefox. The new DoH
in the nightly version I logged for you worked fine. Thanks for looking
into this. I consider it closed.

Ah, in that case it's possible that you had an intermittent DNS issue that also affected the DoH resolver connection - so it normally fell back to native DNS which also failed.
When you switched DoH resolvers it cleared the DNS cache and resolved it again using the new one, which is probably why that worked. Then when you switched back again it still worked, because it resolved it again with cloudflare.

Please let me know if happens again. Some logs captured when the issue is happening would be most useful to diagnose the problem.
Thanks!

That sounds like a very good explanation for what I saw. I'll log if it happens again. Thanks.

You need to log in before you can comment on or make changes to this bug.