DNS over TLS and DNSSEC — confidentiality and validation together

DNS over TLS (DoT) is the upstream-query confidentiality layer for OPNsense Unbound. It encrypts the queries the firewall sends to an upstream resolver, so that anyone watching the path between the firewall and the upstream cannot see what names are being resolved. DoT is independent of DNSSEC: DNSSEC validates answers, DoT protects queries in transit. Production estates that care about both run them together — DoT for the path, DNSSEC for the answers.

This lesson covers what DoT actually provides, how to configure it on OPNsense, the certificate verification discipline that makes it real, and the operational failure modes that arise when it is misconfigured.

What DoT provides and what it does not

DoT encrypts the transport between the DNS client (the firewall, in this case) and the DNS server (the upstream resolver). The standard port is 853. The connection is a TLS session, with all the properties TLS brings: confidentiality of the payload, integrity of the message in transit, server authentication by certificate.

What DoT provides:

• Confidentiality on the path. A network observer between the firewall and the upstream cannot read the question or the answer.
• Server authentication by certificate. The firewall can verify the upstream is who it claims to be, by checking the certificate against a name the operator configured.
• Resistance to on-path tampering. An on-path attacker who cannot produce a valid certificate for the upstream cannot modify the answer in transit without being detected.

What DoT does not provide:

• Confidentiality at the upstream. The upstream sees the query in cleartext. DoT moves the visibility boundary from the network to the upstream’s data centre. An operator who needs to push the visibility boundary further needs DoH (DNS over HTTPS) to a resolver that proxies, or a private recursive resolver with no external upstream.
• Validation of the answer. DoT proves the upstream sent the answer; it does not prove the answer is the answer the authoritative server published. That is DNSSEC’s job.
• Privacy of the SNI. The TLS handshake’s Server Name Indication reveals the upstream’s identity to any on-path observer who can read the TLS ClientHello. Encrypted SNI (ESNI / ECHO) is a separate protocol extension; OPNsense Unbound does not implement it as of this writing.

The mental model: DoT is a TLS tunnel for DNS between the firewall and a known upstream. DNSSEC is a digital signature on the DNS answer. Both together give confidentiality on the path and validation of the answer.

Configuring DoT on OPNsense

The configuration lives under Services → Unbound DNS → DNS over TLS. The page is similar to the Query Forwarding page but adds a TLS-specific Verify CN field per entry. The operator adds an entry per upstream:

The Verify CN field is the certificate name Unbound expects. The OPNsense documentation and most public resolvers publish the canonical Verify CN value in their setup guides. Common values:

Two entries (primary and alternate) on the same zone gives redundancy; the entries form a forwarder pool that Unbound round-robins or fails over between.

Verifying the TLS session is actually happening

The operator’s first verification after enabling DoT is to confirm the firewall is talking TLS to the upstream, not plain DNS on port 53.

$ sockstat -46 -p 853 -c

USER     PROCESS    PID   PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
unbound  unbound    4218  tcp46  192.0.2.1:54312       1.1.1.1:853
unbound  unbound    4218  tcp46  192.0.2.1:54313       1.0.0.1:853
unbound  unbound    4218  tcp46  192.0.2.1:54314       8.8.8.8:853

The check is read-only and safe; the firewall is not modified. The same data is available through the GUI under System → Diagnostics → States (filter by port 853) and Interfaces → Diagnostics → Packet Capture on the WAN.

A second verification uses drill with a TLS-aware resolver:

$ drill -T example.com @1.1.1.1

;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 42381
;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; example.com.   IN  A
;; ANSWER SECTION:
example.com.    300   IN  A   93.184.216.34
;; Query time: 28 msec
;; SERVER: 1.1.1.1#853(1.1.1.1)
;; TLS: established, encrypted: yes, certificate verified: yes

The drill -T output has two important signals: the SERVER line ends in #853(1.1.1.1) (TLS, not plain DNS) and the TLS line confirms the certificate was verified.

Composing DoT with DNSSEC

DoT and DNSSEC are not alternatives; they are layers. The mental model:

A resolver that does both gets confidentiality on the path and authenticity of the answer. A resolver that does only DoT gets confidentiality but trusts the upstream to return honest answers. A resolver that does only DNSSEC validates the answer but lets the path see every query.

The configuration in OPNsense is independent: enable DNSSEC on the General page, enable DoT on the DNS over TLS page. Both settings compose. The verification is the drill -T output above — the ad flag means DNSSEC-validated, the TLS line means the path is encrypted.

Failure modes

Three production failure modes recur when DoT is enabled without the rest of the discipline:

Verify CN mismatch. The upstream rolls its certificate and the new certificate is for a different common name. Unbound refuses the TLS handshake, marks the upstream as bad, and tries the next upstream. If all upstreams have stale Verify CN values, every query fails. The fix is to update the Verify CN field; most providers publish the new name in their setup guides weeks before the change.

Upstream behind a middlebox. Some corporate networks intercept outbound TLS on port 853 and present their own certificate. Unbound refuses the handshake because the certificate does not match the configured Verify CN. The fix is to either accept the interception (drop DoT for the duration of the network) or to find a path the middlebox does not intercept.

Port 853 blocked. Some firewalls and ISPs block outbound 853 because DoT can be used to bypass content controls. The fallback is plain DNS on port 53, which loses the confidentiality but keeps the resolution working. The firewall operator cannot fix an upstream port block from the OPNsense side; the workaround is a forwarder on a different port (DoH on 443 is the standard answer for the censorship-resistance pattern).

Summary

• DNS over TLS encrypts the upstream query path between the firewall and the upstream resolver on port 853.
• DoT does not validate the answer; it does not hide the query from the upstream; it does not hide the upstream identity in the TLS handshake. It is one layer of a complete privacy posture.
• Configure DoT under Services → Unbound DNS → DNS over TLS. Always set the Verify CN field; an empty Verify CN disables certificate verification.
• Verify the TLS sessions are actually established with sockstat -46 -p 853 -c or drill -T example.com @\<upstream\>.
• Compose DoT with DNSSEC for confidentiality plus authenticity. The two layers are independent and complementary.
• Failure modes: Verify CN mismatch after upstream certificate renewal, middlebox interception, upstream port 853 blocking. Each has a known diagnosis and a known mitigation.