Split DNS and net::ERR_FAILED

Configuration
1

I have a HA with NPM. I access HA with the same https link externally and internally. External link it is a domain hosted on cloudflare and in HA i got cloudflare addon- it works flawlessly. Internally i use split DNS on pihole - i got same domain on pihole that resolves to internal ip that is set up using NPM and certs are take by NPM from cloudflare. In pihole i block HTTPS requests so browsers only resolves ipv4 record. Now every few minutes i can’t get to HA locally from my Chrome- it says

GET https://xxx.xxx.eu/manifest.json net::ERR_FAILED

or

core.ts:73 WebSocket connection to 'wss://xxx.xxx.eu/api/websocket' failed:

. It stays like that for few minutes and then it works. If i want to force it to work i close and reopen Chrome and it works. I’ve already tried million things and nothing helped. Any thoughts what could that be?

2

Why. I assume NPM is Nginx proxy manager ? I use it too, but at home or external I just use http://home.mydomain.com

3

Yes NPM - nginx proxy manager. Why? Bacause i want it to be accessible through https both locally and from external because i have some additional cards where i have iframes and You would not be able to access http iframe on https website

4

ah, i use a wildcard certificate, and my iframes go through nginx too.

5

That line makes no sense.
From the text it could be that your client machine somehow lookup the external address and your router is not configured for hairpin natting.

6

I’m not doing any NAT. Cloudflare tunnel is running and HA is available externally through it. By saying i block HTTPS requests i mean HTTPS request on DNS. All new browsers are looking at A, AAAA and HTTPS records and when You have split DNS scenario with cloudlflare on external browser will try to resolve HTTPS records on DNS servers and it will get addresses from cloudflare event if it asks internal DNS server.

7

HTTPS has nothing to do with DNS.

DNS solves hostnames to IP addresses and maybe also the other way around, but that is it.

Well, you can use DNS-over-HTTPS, but that is just a tunnel connection to the DNS server.

8

Sorry but you are wrong. Modern browsers ask dns servers for https records and use that over a record. List of DNS record types - Wikipedia
This is known issue when you use same fqdn with split tunnel and let say cloudflare. But like I mentioned I blocked that on my Pi-hole.

9

It is not a standard. It is just proposed.

Here you the RFC and its state is listed first as a proposed standard.

Here is the explanation of the states.

There are many proposed standards and many that do not make the cut to a draft.

10

Jee man. Just google it!!!
The HTTPS DNS record is a standardized DNS resource record type specified in RFC 9460, finalized as an Internet Standards Track document by the IETF in November 2023. It is a variant of the SVCB (Service Binding) record type, specifically designed to provide service discovery and connection parameters for HTTPS. This enables reducing DNS queries and improving privacy and performance while establishing HTTPS connections. The HTTPS record is no longer just a proposal but an official standard that many DNS providers and clients have started to support.

11

I just linked to IETF’s database earlier.
They are the ones deciding the standards.
It is just a proposed standard.
I also linked what a proposed standard means and what extra steps it needs to take is also listed in the link.

A proposed standard is the IETF wording for alpha test.
Next step is draft standard, which is IETF wording for beta test.
And finally it will become a standard.

A proposed standard is the lowest level in the IETF hierarchy.

12

Regardless if it is a proposed standard or not, both Cloudflare and Chrome (chromium) are now using “HTTPS” DNS records. When using a Cloudflare tunnel it uses a DNS “proxy” record. Cloudflare then creates a dynamic (but hidden from the UI) “HTTPS” record that responds with the Cloudflare public IP address.

When Chrome accesses an https (tls) based website URL, it performs a HTTPS DNS query. When you are at home it queries your local DNS (e.g., pihole, UDM-SE, whatever your local DNS server is), but most do not support HTTPS DNS record types given they are so new. So the DNS query is forwared from your local DNS server to whatever you have defined as upstream. If you are using Cloudflare tunneling, it will return the public IP of your site. So you end up with the issue with the “A” record has your internal IP but the HTTPS DNS record returns the public IP. Chrome then gets confused because the https cert on your local system is normally unsigned or a real cert by LetsEncrypt, but that doesn’t match the Cloudflare https cert. So you end up with err_SSL_UNRECOGNIZED_NAME_ALERT

Not sure about other setups, but I can confirm this issue using Cloudflare tunnels.

You can verify this via the following:

# Query public DNS server
$ dig +short @1.1.1.1 https myserver.mydomain.com

# then query your local DNS (replace x.x.x.x with your local DNS server):
$ dig +short @x.x.x.x https myserver.mydomain.com

You will notice in the second query example above that even though you query your local DNS server, you get back the public IP address info.

Chromium uses the HTTPS record type to retrieve configuration for TLS services, which is crucial for Encrypted Client Hello (ECH) to function correctly. ECH encrypts the Server Name Indication (SNI) in the TLS handshake to improve user privacy by allowing a server to advertise cryptographic keys via the new HTTPS DNS record type. While Chromium has implemented support for this new record, its actual use and performance have been the subject of ongoing study and development. Though its now in full use within Google Chrome and Microsoft Edge browsers.

13

@kaczkalolo How did you block the “HTTPS” dns query type only via pi-hole? I’m only seeing the ability block the entire DNS name regardless of DNS query type.

UPDATE:
I will answer my own question. You can block via regex that includes the querytype. Example below:

^(.+\.)?example\.com$;querytype=HTTPS