I’m not trying to expose it to the internet and there are indeed multiple solutions to get HTTPS. This one works with a real domain name is what works best for me :)

Yes it does. Are you using Firefox? And you can’t resolve local ip addresses, so that’s why you are setting this exception?

Wouldn’t that require me to use tailscale even at home on my home network? It also does not provide HTTPS unless you maybe use magic DNS, but then we’re back to using a public domain I guess.

Since it knows the DNS will always be public, it also knows that the 192.168.10.20 address is not routable on the internet where it found it.

That is in fact not it. I left the default firefox DNS setting. I simply enabled network.trr.allow-rfc1918 from within the about:config which allows the resolution of local IP addresses. It now works. All my DNS are public, I make no use of any private, local DNS.

This was not required in my case, but maybe it solves other issues?

Works flawlessly with my tailscale setup :) Thanks for asking! I’m not trying to expose anything to the open. Just for me personally, from home or remotely using my VPN.

Thanks for your response. Indeed, this is only for myself within my home network. No split DNS required, the public DNS record mentions my local private IP address which of course will only resolve to my homeserver from within my home network and will not lead anywhere for anyone else from any other network. That’s all what makes this great. Yes, I did the DNS challenge as I mentioned in my OP and retrieved a wildcard certificate for all my local needs :)

Yes, I now managed to make it fully work on firefox too, needed to set network.trr.allow-rfc1918 to true in the about:config settings! :)

so some apps (like Firefox) with internal hard-coded DNS functions

Thank you! This was the information I needed! It landed me on this page https://support.mozilla.org/en-US/kb/firefox-dns-over-https which shows When DoH is enabled, Firefox by default directs DoH queries to DNS servers that are operated by a trusted partner, which has the ability to see users' queries and lead me to this page https://wiki.mozilla.org/Trusted_Recursive_Resolver where I was able to read more about it. That explains why it does not work, I appreciate the insight!

No, it is not fully working. Many have tried to explain to you that your setup only works for YOU on YOUR subnet.

That’s exactly what I want. I don’t know why you thought I wanted something else? I’m trying to reach services in my home network from home, using HTTPS, without requiring a local DNS or to load self-signed certificates.

EDIT: I realize I maybe could’ve made a better job at explaining that the intention was for it to work exclusively for me on my home network.

Yes, it was an attempt at doing on step at the time, but I realize I’ve been able to make it work in some browsers and on some DNS using HTTPS, as hoped. I’m now mostly trying to solve specific DNS issues, trying to understand why there are some cases where it’s not working (i.e. in Firefox regardless of DNS setting, or when calling dig, curl or host).

Opening up the network developer tools in Firefox, I’m seeing the following error: NS_ERROR_UNKNOWN_HOST, though I haven’t been able to determine how to solve this yet. It does make sense, because it would also explain why curl is unable to resolve it, if the nameserver is unreachable. I’m still confused though, because cloudflare, google and most other DNS’s I’ve tried work without issue. Even setting google’s dns in firefox does not resolve it.

This was a good suggestion, indeed other browsers seem to work just fine, I updated my post with a new edit. I’m making progress, it seems I’m having some specific issue with Firefox, my default browser. And your last point was also spot-on, though I only understand now what you meant now that I figured out the port-80 resolution loop trap.

It does work. In my first edit I’m sharing multiple examples of others making it work, and I’ve made it work in some cases which I explain in my second edit. I’m not using an HTTP challenge, but a DNS challenge which is not specific to any IP address and does not require the IP address to be reachable from outside my network. I only care about accessing the endpoint from within my home network. The use of a real domain allows me to make use of the public chain of trust infrastructure and DNS allowing me to reach my homeserver using any device without having to setup any specific local DNS or installing any custom certificate on any of my devices.

If I put my registrar’s DNS, or cloudflare or google, it works just fine in dig, here with google:

; <<>> DiG 9.18.39 <<>> @8.8.8.8 mydomain.tld
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1301
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mydomain.tld.		IN	A

;; ANSWER SECTION:
mydomain.tld.	3600	IN	A	192.168.10.20

;; Query time: 34 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Sun Oct 05 15:51:47 CEST 2025
;; MSG SIZE  rcvd: 60

Would you mind explaining further what you mean by “setting it up on both sides of the route”? Much appreciated!

I’m getting the following:

; <<>> DiG 9.18.39 <<>> mydomain.tld
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16004
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;mydomain.tld.		IN	A

;; Query time: 3 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sun Oct 05 14:23:20 CEST 2025
;; MSG SIZE  rcvd: 44

I guess your proposal would be the last resort, but I have not seen any mention of this approach being necessary for others achieving what I’m trying.

I tried, it just gave me the following:

curl: (6) Could not resolve host: mydomain.tld

Which is surprising. I got something similar when I tried traceroute earlier.

Yet when I look into my registrars records, all seems fine, and it seems to also be confirmed by the nslookup I mentioned in the OP. So I’m a bit confused.

The A record was set on my registrar, so on a public DNS, so to speak.

1. It allows me to use HTTPS on a private service without setting up any custom DNS locally and without me using any selfsigned certificates and with all my IP addresses being private. It’s a good solution for me to have the real certificates using the default public infrastructure while keeping everything private. What’s the danger of sharing that my private server is accessible at 192.168.10.20 for the external world? What could they do with that information?
2. I use my tailscale network to which I expose my local network to allow remote access. Works great for me.

You sure can. You can see someone doing just that here successfully:

https://www.yewtu.be/watch?v=qlcVx-k-02E