all starting to come together....
https://crt.sh/?id=5059423735
(as background: this is all just to make browsers happy as they don't know the underlying connection is e2e wireguard already)
I have some similar infra at home and I'm quietly scared of the upcoming esni changes that may make my small hack need to turn into a big mess. Did you cover that part?
ESNI was replaced by Encrypted Client Hello (ECH). It relies on the new HTTPS record type which isn't broadly supported yet. It shouldn't end up being that hard to deploy but software largely doesn't support it yet. It's still somewhat useful even without a shared server IP.
My solution in this space of "my browser works properly with walled garden services" also solves for, in some cases, non-walled services, wherein the same endpoint that handles the acme challenge forwarding also has a path the drops out to splice(2) after initial routing
It's this spliced part that I think will be most affected, but I'm also not yet sure (haven't read enough, which is most of why I'm afraid it'll make a mess), if it's also going to make the acme dance indirection harder
I expect http://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html… will support ECH. The load balancer will be where ECH terminates but not TLS. I don't think that's a problem because I think the way it works is there's a separate key for ECH with the public key in the HTTPS record. I can't remember all details.
Nothing really seems to implement ECH yet and the only place that I've seen explicit HTTPS record support is Cloudflare's DNS. At this point, it's not really something that's actually available for use unless you implement it yourself. It definitely won't be commonly used anyway.
Turns out ldns (drill) does actually support HTTPS records in the development branch but the last stable release was in 2019.
PowerDNS has support for it too but it hasn't been added to all the documentation yet.
https://doc.powerdns.com/authoritative/guides/svcb.html…
I don't get why ipv4hint/ipv6hint exist.