Feature Request: Support ECH on NextDNS endpoints to bypass SNI filtering (Without root CA certificates)

Hi NextDNS Team,

I would like to formally request the implementation of Encrypted Client Hello (ECH) support on NextDNS incoming infrastructure (DoH, DoT, and DoQ endpoints).

Currently, during the TLS handshake, the endpoint domain (dns.nextdns.io or custom profile domains) is transmitted in cleartext within the Server Name Indication (SNI) field. In strictly censored regions with nationwide Deep Packet Inspection (DPI) systems, ISPs are actively using this cleartext SNI data to instantly detect and drop NextDNS traffic, even if we try to bypass port blocks.

Important Clarification:
I am familiar with your previous responses to users stating that implementing ECH-like functionality on mobile devices requires installing custom root CA certificates and proxying all web traffic (similar to what Control D does).

I am NOT asking for that. I am not asking NextDNS to proxy web traffic or decrypt third-party websites.

I am asking for NextDNS to enable native ECH support exclusively for your own server endpoints (inbound TLS handshakes). This means:

1. NextDNS generates and publishes standard ECH configuration keys via your service's DNS records (SVCB/HTTPS records).
2. Modern ECH-capable custom DNS clients can use these keys to encrypt the *.nextdns.io SNI during the initial handshake.
3. This requires zero modifications to the user's OS security, zero root CA certificates, and zero web proxying. It is a standard TLS 1.3 security feature implemented on the server side, exactly how Cloudflare or Google run their secure infrastructure.

Given the increasing level of keyword-based DPI censorship globally, adding native ECH support to your own nodes is the ultimate way to maintain service availability and user privacy in censored regions.

Thank you for considering this feature request!