Encrypted DNS: DNS over TLS and DNS over HTTPS

Linux agents can answer DNS over TLS (DoT, RFC 7858) and DNS over HTTPS (DoH, RFC 8484) as well as plain DNS. Clients get the same answers on the same addresses, with the same allow-query, recursion and DNS Firewall policy. The only difference is that nobody on the network path can read or change the queries.

Windows DNS Server agents don't support encrypted DNS, and the setting is hidden for them.

Turn it on

1. Go to Agents, open the agent and choose Configure → Encrypted DNS.
2. Tick DNS over TLS (DoT), DNS over HTTPS (DoH), or both.
   • DoT listens on port 853.
   • DoH listens on port 443, path /dns-query, over HTTP/2.
   • You can change both ports. If a web server already uses 443 on the agent's DNS address, give DoH another port.
3. Choose where the certificate comes from (see below), enter the hostnames clients will use (for example dns1.corp.example.com), and Save.

The agent applies the change within seconds with an in-place reconfiguration; named is not restarted. The tab then shows the client settings, such as the DoH template https://dns1.corp.example.com/dns-query{?dns} and the DoT host.

Certificates

Option	When to use it
Subnetly CA (default)	Subnetly runs a private CA for your organization and issues each agent a certificate covering its hostnames and DNS service IP. Certificates last about 13 months and are renewed automatically 30 days before they expire. Download the CA with Download CA (.cer) and deploy it to clients' trusted roots.
Upload certificate	You already have an internal PKI (for example AD Certificate Services) or a public certificate. Paste or upload the chain (leaf first) and the private key in PEM format. The key is stored encrypted and only ever sent to that agent. You renew it yourself; the tab shows the expiry date.
Self-signed	Quick trials only. BIND generates a throwaway certificate. Traffic is encrypted, but clients can't verify the server, so most only use it in opportunistic mode.

Deploy the Subnetly CA to Windows clients

1. Download subnetly-dns-ca.cer from the Encrypted DNS tab.
2. In Group Policy Management, edit a GPO linked to your computers. Go to Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities.
3. Right-click Import and choose the .cer file.

On macOS and iOS, add the certificate to a configuration profile with your MDM, and mark it as trusted for SSL/TLS.

Automatic upgrade with DDR

With Advertise via DDR on, the agent answers _dns.resolver.arpa (Discovery of Designated Resolvers, RFC 9462). Clients that already use the server over plain DNS, such as Windows 11, macOS and iOS, can discover its DoH and DoT endpoints and upgrade on their own. No per-client DoH configuration is needed.

DDR is only offered when clients can verify the server:

• the certificate comes from the Subnetly CA or is uploaded, not self-signed;
• at least one hostname is set (the first one is advertised);
• the certificate covers the server's IP address. The Subnetly CA always includes it; for an uploaded certificate, add the IP as a subject alternative name.

Check it with:

dig @10.20.0.53 _dns.resolver.arpa SVCB

Configure clients by hand

• Windows 11 / Server 2022+: netsh dns add encryption server=10.20.0.53 dohtemplate=https://dns1.corp.example.com/dns-query autoupgrade=yes udpfallback=no, then select Encrypted only for that DNS server in network settings.
• Android (Private DNS): enter the hostname, e.g. dns1.corp.example.com. Android requires a certificate it trusts for that name.
• Browsers: use the DoH template from the tab as a custom provider.

To test from any Linux host with BIND 9.18+ tools:

dig +tls  +tls-ca=subnetly-dns-ca.pem +tls-hostname=dns1.corp.example.com @10.20.0.53 www.corp.example.com
dig +https +tls-ca=subnetly-dns-ca.pem +tls-hostname=dns1.corp.example.com @10.20.0.53 www.corp.example.com

Troubleshooting

• "encrypted DNS: DoH 10.20.0.53:443 … is another service using port 443?" in the agent's events: another program on the host already holds that port on the DNS address. Plain DNS and DoT keep working. Stop the other service or pick another DoH port, then save again.
• The agent shows "predates encrypted DNS": update the agent from the Agents page. Encrypted DNS needs agent 1.2.3 or newer.
• Agents fall back to a self-signed certificate when the uploaded certificate has expired, or when the DNS container image is older than the agent. Run subnetly update on the host to fix the second case.

Forward to upstream resolvers over TLS

Encrypted DNS above protects queries between clients and your agents. To also encrypt what the agent sends upstream, have it forward recursive queries over DNS over TLS:

1. Open the agent and choose Configure → DNS Server.
2. Enter the Forwarders, for example 1.1.1.1, 1.0.0.1, and set Forward policy to only.
3. Tick Forward over TLS and Save DNS config.

How the agent checks the forwarders' certificate:

TLS hostname	CA certificate	The certificate must…
empty	empty	chain to a public CA and carry the forwarder's IP address. Works for Cloudflare (1.1.1.1), Google (8.8.8.8) and Quad9 (9.9.9.9).
cloudflare-dns.com	empty	chain to a public CA and carry that name.
empty or a name	your CA (PEM)	chain to your CA, for an internal resolver with a private certificate.

The hostname applies to every forwarder, so only set one when all the forwarders belong to the same service. If a forwarder's certificate doesn't match, the agent doesn't use it; with forward policy only and no forwarder left, recursive queries fail (SERVFAIL) rather than going out unencrypted.

Untick Verify the forwarders' certificate only for a resolver whose certificate you can't check: queries are still encrypted, but anyone who can intercept them can answer in the forwarder's place.

Good to know:

• Keep Forward policy on only. With first, BIND resolves from the root servers over plain DNS whenever the forwarders don't answer.
• Conditional forward zones that list their own forwarders (an Active Directory domain sent to its domain controllers, say) keep using plain DNS. Forward zones that use the agent's forwarders use TLS too.
• The port is 853 unless you change it.
• Forwarding over TLS needs BIND 9.20, which the DNS container has from agent 1.2.4. Until the host runs it, the option is greyed out with the reason; run subnetly update on the host. Windows DNS Server agents can't forward over TLS.

To check from the agent host:

docker compose -f /opt/subnetly/docker-compose.yml exec dns dig @127.0.0.1 www.example.com

A SERVFAIL with forwarding over TLS on usually means the certificate didn't match: check the hostname, or leave it empty to check the IP address.

Not covered yet

• DNS over QUIC (DoQ) and DoH over HTTP/3.
• A separate TLS hostname per forwarder.