Hello,
ESNI parameters are served through through the legacy _esni subdomains. You can check this here
However the newer method involving the HTTPS RR is not working as you can see here: there’s no echconfig parameter in use.
It has been a long time since Cloudflare started to use the HTTPS RR. Does Cloudflare plan to migrate ESNI params to HTTPS or do you plan to keep the _esni subdomain as the only ECH method?
Many thanks
Had the same question couple of days ago. Unfortunately I couldn’t get an answer either. ECH (Encrypted Client Hello) Support - #3 by soldier_21
So do you suggest that I email them or did he already do that?
Imma email them. Will post here, I hope, if they answer.
EDIT: I think I know why they did not implement this. (Though I haven’t received an answer from them)
@Writer10203 It would be really helpful if you were able to share the reason behind the protocol update.
I still haven’t heard back from them but my guess was that the SVCB implementation they use was outdated so they were expecting an update before using it so I opened a pull request that updates it: Update SVCB by DesWurstes · Pull Request #1341 · miekg/dns · GitHub (I use lots of usernames on different websites). Only recently I understood that there was no change to how ESNI is treated by HTTPS/SVCB so they SHOULD have implemented it. There’s really no reason for them not to, even before the pull request is merged.
@Writer10203 That looks like a parsing issue for HTTPS (65) DNS records for the “ech” field. I don’t think that is a major reason for the delay since you can get the updated “ech” keys without requesting DNS records using grease directly. This was a fix to slow DNS record update which was/is a problem with ESNI.
I’m pretty sure the main reason behind the delay is that the protocol is just undergoing some heavy test phase before getting deployed in prod. But again, it has been too long now since ESNI received any update…
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.