Turns out OpenWrt doesn’t support configuring HTTPS records yet, specifically LuCI.
But thanks to an amazing guy named systemcrash this is already in the works, and I was able to patch my device locally (more details here).
I was able to test the early work and confirm it to be working:
❯ dig @192.168.1.1 +noall +answer HTTPS ha.example.com
ha.example.com. 0 IN HTTPS 1 ha.example.com. alpn="h3,h2" ipv4hint=192.168.1.10
And it’s working great, no more cloudflare-ech.com requests going to Caddy, and HTTP/2 and HTTP/3 connection can be established right away without requiring the initial HTTP/1.1 connection.
I supposed I could even go ahead and enable ECH in Caddy as well. I’d just need to make sure my HTTPS record points to it similar to how the Cloudflare one does:
❯ dig @1.1.1.1 +noall +answer HTTPS ha.example.com
ha.example.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.21.48.163,172.67.154.87 ech=AEX+DQBBcgAgACCuudXVeqy1b7VjHm3+N5rJppj+yAvIrV3DfAS5RT2teQAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:3032::6815:30a3,2606:4700:3033::ac43:9a57
But ECH within my local network doesn’t really make sense. I control the DNS resolver anyway; it’s not leaking to my ISP or something like that.
Conclusion:
Make sure your local DNS server is serving both the A/AAAA and HTTPS records for your domain. If you serve just A/AAAA, then your browser will probably end up receiving the HTTPS record from the public DNS server, which is going to confuse the browser and cause the ERR_SSL_PROTOCOL_ERROR down the line.