Add an example with EDS

README.md

@@ -89,8 +89,18 @@ Unless the front-end is a CDN, an ideal setup is to use `rust-doh` behind `Encry
 * Unlike DNSCrypt where users must explicitly trust a DNS server's public key, the security of DoH relies on traditional public Certificate Authorities. Additional root certificates (required by governments, security software, enterprise gateways) installed on a client immediately make DoH vulnerable to MITM. In order to prevent this, DNS stamps should include the hash of the parent certificate.
 * TLS certificates are tied to host names. But domains expire, get reassigned and switch hands all the time. If a domain originally used for a DoH service gets a new, possibly malicious owner, clients still configured to use the service will blindly keep trusting it if the CA is the same. As a mitigation, the CA should sign an intermediate certificate (the only one present in the stamp), itself used to sign the name used by the DoH server. While commercial CAs offer this, Let's Encrypt currently doesn't.
 * Make sure that the front-end supports HTTP/2 and TLS 1.3.
+* Internal DoH servers still require TLS certificates. So, if you are planning to deploy an internal server, you need to set up an internal CA, or add self-signed certificates to every single client.
 
-## Example usage with Nginx
+## Example usage with `encrypted-dns-server`
+
+Add the following section to the configuration file:
+
+```toml
+[tls]
+upstream_addr = "127.0.0.1:3000"
+```
+
+## Example usage with `nginx`
 
 In an existing `server`, a `/doh` endpoint can be exposed that way: