User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36

Steps to reproduce:

1. Open a new browser with DNS over HTTPS enabled with any dns provider [e.g. cloudflare]
2. Navigate to api.stytch.shophellosocks.com/health

Actual results:

Reaches "hmm. We're having trouble finding this site"...

Expected results:

The browser should resolve the domain. What should happen, is DOH should go into fallback mode and resolve the dns of the site.

The domain resolves on other browsers using DNS over HTTPS (chrome), resolves once DNS over HTTPS is disabled in Firefox, or when invalidating the cache in inspector tools.

As per https://support.mozilla.org/en-US/kb/firefox-dns-over-https

"DoH is enabled for users in “fallback” mode. For example, if the domain name lookups that are using DoH fail for some reason, Firefox will fall back and use the default DNS configured by the operating system (OS) instead of displaying an error."

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.

I am unable to reproduce the bug with the link you provided.
Is it still happening for you?
If so, could you capture some HTTP logs? https://firefox-source-docs.mozilla.org/networking/http/logging.html

Hello Valentin,

Thanks for looking into this.

We had spent a bit more time investigating this and found a bit more when this fails on firefox (and when it doesn't).

When we point our cname entry (api.stytch.shophellosocks.com/health) to another cname entry which is a wildcard, we get this error. When we do not use the cname entry which is a wild card, we do not get the error. For the sake of the issue, we are now pointing it to the cname entry which is a wildcard, because the expected behavior is this should still resolve and work.

If you try again you should be able to reproduce. I've attached logs as well.

Thank you for your report.
Indeed, it seems to only be happening when loading from the HTTP cache.

However, the page also fails to resolve in Chrome or wget - at least on my machine:

$ dig api.stytch.shophellosocks.com

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> api.stytch.shophellosocks.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34154
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;api.stytch.shophellosocks.com.	IN	A

;; ANSWER SECTION:
api.stytch.shophellosocks.com. 44 IN	CNAME	firefox.customers.stytch.com.
firefox.customers.stytch.com. 44 IN	CNAME	*.customers.stytch.com.cdn.cloudflare.net.
*.customers.stytch.com.cdn.cloudflare.net. 44 IN A 104.22.2.122
*.customers.stytch.com.cdn.cloudflare.net. 44 IN A 104.22.3.122
*.customers.stytch.com.cdn.cloudflare.net. 44 IN A 172.67.5.99

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Jan 09 17:22:59 CET 2023
;; MSG SIZE  rcvd: 200

$ wget https://api.stytch.shophellosocks.com/health
--2023-01-09 17:24:40--  https://api.stytch.shophellosocks.com/health
Resolving api.stytch.shophellosocks.com (api.stytch.shophellosocks.com)... failed: Name or service not known.
wget: unable to resolve host address ‘api.stytch.shophellosocks.com’

It appears that the thing that breaks our behaviour here is the HTTPS record. If I set network.dns.use_https_rr_as_altsvc to false then the bug goes away.

I'll try to turn this into a unit test.

Thanks for your quick response!

a few follow up questions/clarifications:

1. To confirm, wget/chrome failed, but firefox worked when you set the network.dns.use_https_rr_as_altsvc setting to false? Do you mind re-confirming?

2. What is a HTTPS record? Where does it show in the DIG results? I see CNAMEs and A records

3. You mentioned it only seems to be "happening when loading from the HTTP cache." What is the HTTP cache?

4. Is this expected behavior? Or does turning this into a unit test imply its a bug?

(In reply to ovadia from comment #6)

Thanks for your quick response!

a few follow up questions/clarifications:

1. To confirm, wget/chrome failed, but firefox worked when you set the network.dns.use_https_rr_as_altsvc setting to false? Do you mind re-confirming?

That is correct. With DNS over HTTPS enabled, and network.dns.use_https_rr_as_altsvc setting set to false, I was able to load and refresh the page.

2. What is a HTTPS record? Where does it show in the DIG results? I see CNAMEs and A records

Here's an article explaining it: https://simpledns.plus/help/https-records
Here are the HTTPS records for your domain: https://dns.google/query?name=api.stytch.shophellosocks.com&rr_type=HTTPS&ecs=

"Answer": [
    {
      "name": "api.stytch.shophellosocks.com.",
      "type": 5 /* CNAME */,
      "TTL": 55,
      "data": "firefox.customers.stytch.com."
    },
    {
      "name": "firefox.customers.stytch.com.",
      "type": 5 /* CNAME */,
      "TTL": 295,
      "data": "*.customers.stytch.com.cdn.cloudflare.net."
    },
    {
      "name": "*.customers.stytch.com.cdn.cloudflare.net.",
      "type": 65 /* HTTPS */,
      "TTL": 300,
      "data": "1 . alpn=h2 ipv4hint=104.22.2.122,104.22.3.122,172.67.5.99 ipv6hint=2606:4700:10::6816:27a,2606:4700:10::6816:37a,2606:4700:10::ac43:563"
    }

3. You mentioned it only seems to be "happening when loading from the HTTP cache." What is the HTTP cache?

The first load is coming from the network - we cache it in the browser's HTTP cache.

4. Is this expected behavior? Or does turning this into a unit test imply its a bug?

Not sure. The fact that it doesn't work at all without DNS over HTTPS leads me to believe CNAME records to a wildcard domain aren't well supported by DNS resolvers. I'll still try to turn this into a test, just because it's such a weird corner case 🙂

The website in comment 0 seems to have been fixed.
Keeping this bug open to write a test.