Overview

The NetWall receives encrypted DNS traffic from clients on TCP port 853, terminates the TLS connection, and forwards the decrypted DNS-over-TCP traffic to a standard DNS server on TCP port 53.

This allows existing DNS servers that do not natively support DoT to be exposed to clients using encrypted DNS.

+-------------+          DNS over TLS           +-------------+
|             |          TCP/853                |             |
| DoT Client  | ==============================> |   NetWall   |
|             |           encrypted             |             |
+-------------+                                 +------+------+
                                                       |
                                                       | DNS over TCP
                                                       | TCP/53
                                                       | plaintext
                                                       v
                                                +-------------+
                                                |             |
                                                | DNS Server  |
                                                |             |
                                                +-------------+

The TLS connection exists only between the DoT client and NetWall. Traffic between NetWall and the backend DNS server is standard unencrypted DNS over TCP.

Use Cases

This configuration can be useful in several scenarios.

Provide encrypted DNS to existing DNS infrastructure

An organization may already operate internal or external DNS resolvers that only support traditional DNS.

NetWall can provide the TLS endpoint without requiring the DNS server itself to support DoT.

Clients                    NetWall                 Existing DNS
                           TLS termination         infrastructure

+--------+                 +---------+              +---------+
| Client | == DoT =======> | NetWall | -- DNS --->  | DNS     |
+--------+    TCP/853      +---------+    TCP/53    | Server  |
                                                   +---------+

Protect DNS traffic over untrusted networks

Clients can use encrypted DNS when communicating with the organization’s DNS infrastructure across networks where plaintext DNS would otherwise be visible.

For example:

Remote client
     |
     | Internet / untrusted network
     |
     | DNS-over-TLS
     | TCP/853
     v
+---------+
| NetWall |
+----+----+
     |
     | Internal network
     | DNS/TCP 53
     v
+-------------+
| Corporate   |
| DNS Server  |
+-------------+

Centralize the DoT service on NetWall

Instead of configuring and maintaining TLS certificates on multiple DNS servers, NetWall can act as the common encrypted DNS endpoint.

The backend DNS infrastructure can remain unchanged.

How It Works

DNS-over-TLS is defined to use TCP port 853 by default.

A DoT client first creates a TCP connection to NetWall and then performs a TLS handshake.

Client                                        NetWall

   |                                             |
   | -------- TCP SYN :853 --------------------> |
   | <------- TCP SYN/ACK ---------------------- |
   |                                             |
   | -------- TLS ClientHello -----------------> |
   | <------- TLS ServerHello + Certificate ---- |
   |                                             |
   | ======== Encrypted DNS Query =============> |
   |                                             |

NetWall presents the configured server certificate and terminates TLS.

The decrypted payload is standard DNS-over-TCP traffic. The IP Policy then performs destination address and port translation and forwards the connection to the configured DNS server on TCP port 53.

                    NetWall
              +-----------------+
DoT TCP/853   |                 |
============> | TLS termination |
              |        |        |
              |        v        |
              | Plain DNS/TCP   |
              |        |        |
              | SAT 853 -> 53   |
              +--------+--------+
                       |
                       | TCP/53
                       v
                  DNS Resolver

No DNS protocol conversion is required. Once the TLS layer has been removed, the payload is already formatted as DNS over TCP.

Prerequisites

Before configuring the IP Policy, the following are required:

• A DNS server reachable from NetWall.
• The DNS server must accept DNS over TCP on port 53.
• A TCP service representing TCP/853.
• A server certificate that NetWall can present to DoT clients.
• The certificate name must match the DNS hostname configured by the clients.
• Any intermediate CA certificates required to construct the server certificate chain must be imported into NetWall.

For example, if clients are configured to use:

dns.example.com

the certificate presented by NetWall should contain:

DNS:dns.example.com

in its Subject Alternative Name.

Example Network

The following example is used throughout this article:

DoT Client
192.0.2.10
     |
     |
     | dns.example.com
     | 203.0.113.10:853
     |
     v
+-------------------------+
| NetWall                 |
|                         |
| DoT endpoint            |
| TCP/853                 |
|                         |
| TLS certificate:        |
| dns.example.com         |
+------------+------------+
             |
             | SAT
             | TCP/853 -> TCP/53
             |
             v
+-------------------------+
| DNS Server              |
| 10.0.0.53               |
|                         |
| TCP/53                  |
+-------------------------+

Configuration

1. Create a TCP/853 Service

Create a service for DNS-over-TLS using:

Protocol: TCP
Destination Port: 853

For example, name the service:

DoT

The service is used to identify incoming DoT connections.

2. Import the TLS Certificate

Import the certificate and private key that NetWall will present to DoT clients.

For example:

Host certificate:
gw

The certificate must contain the DNS hostname used by the DoT clients.

Example:

dns.example.com

The client must trust the CA that issued the certificate.

Certificate Chain

Make sure that the complete required intermediate certificate chain is available to NetWall.

For example:

Server certificate
       |
       v
Intermediate CA
       |
       v
Intermediate / Root CA
       |
       v
Trusted Root CA

A common symptom of an incomplete chain is that an OpenSSL connection succeeds but a DoT client refuses to establish the connection because it cannot verify the certificate.

For example:

unable to get local issuer certificate

or:

unable to verify the first certificate

3. Create the IP Policy

The IP Policy performs three functions:

1. Accepts the incoming TCP/853 connection.
2. Terminates TLS using the configured Host Certificate.
3. Translates the destination to the DNS server and changes the destination port to TCP/53.

A verified example configuration is:

add IPPolicy \
    DestAddressTranslation=SAT \
    DestAddressAction=SingleIP \
    DestNewIP=internal_dns \
    DestPortAction=SinglePort \
    DestNewSinglePort=53 \
    TLSControl=True \
    TLSHostCert=gw \
    TLSRootCert="isrg-root-x2-cross-signed-04, isrg-root-ye-03, letsencrypt-ye2-02" \
    Name=DoT \
    SourceInterface=any \
    DestinationInterface=any \
    SourceNetwork=all-nets \
    DestinationNetwork=all-nets \
    Service=DoT

In this example:

Name
    DoT

Service
    DoT
    TCP/853

TLSControl
    Enabled

TLSHostCert
    gw

DestAddressTranslation
    SAT

DestNewIP
   internal_dns

DestNewSinglePort
    53

The resulting flow is:

Client
   |
   | TCP/853
   | TLS encrypted
   v
NetWall
   |
   | TLSHostCert=gw
   | TLS termination
   |
   | DestAddressTranslation=SAT
   | DestNewIP=internal_dns
   | DestNewSinglePort=53
   v
internal_dns
TCP/53

Recommended Production Policy

The example above uses:

SourceInterface=any
DestinationInterface=any
SourceNetwork=all-nets
DestinationNetwork=all-nets

This is useful for testing but should normally be restricted in a production configuration.

Where possible, specify:

• The interface on which DoT clients arrive.
• The NetWall address exposed as the DoT service.
• The client networks that should be allowed to use the service.
• The interface toward the DNS server.

For example:

SourceInterface=lan
SourceNetwork=corp_clients
DestinationNetwork=dot_public_ip
Service=DoT

This prevents the TLS termination policy from matching unrelated TCP/853 traffic.

Testing

Test the TLS Endpoint with OpenSSL

The TLS configuration can first be tested independently of DNS.

For example:

openssl s_client \
  -connect 203.0.113.10:853 \
  -servername dns.example.com \
  -showcerts

A successful connection should show a negotiated TLS session and the certificate presented by NetWall.

For stricter certificate verification, use:

openssl s_client \
  -connect 203.0.113.10:853 \
  -servername dns.example.com \
  -verify_return_error

The certificate verification should complete successfully.

Test DNS-over-TLS with kdig

kdig can be used to test DoT without changing the operating system DNS configuration.

For example:

kdig @203.0.113.10 \
  +tls \
  +tls-hostname=dns.example.com \
  www.example.com A

A successful response confirms the complete flow:

kdig
 |
 | DNS-over-TLS
 | TCP/853
 v
NetWall
 |
 | TLS termination
 | SAT
 v
DNS Server
 |
 | DNS response
 v
NetWall
 |
 | encrypted DoT response
 v
kdig

The returned result should look similar to a normal DNS lookup:

;; ANSWER SECTION:
www.example.com.    300    IN    A    192.0.2.50

Troubleshooting

TLS handshake succeeds with OpenSSL but kdig fails

For example:

WARNING: TLS, handshake failed
Error in the certificate.

Check the certificate chain presented by NetWall:

openssl s_client \
  -connect 203.0.113.10:853 \
  -servername dns.example.com \
  -showcerts

Make sure all required intermediate CA certificates are available.

Do not rely only on the server/leaf certificate.

Certificate hostname mismatch

The DNS hostname configured on the client must match the certificate presented by NetWall.

For example:

Client configuration:
dns.example.com

should correspond to a certificate containing:

Subject Alternative Name:
DNS:dns.example.com

Connecting by IP address does not remove the requirement for hostname validation when a TLS hostname is configured.

TLS succeeds but DNS queries time out

First verify that the backend DNS server accepts TCP DNS requests.

From a suitable host, test:

dig @10.0.0.53 www.example.com A +tcp

DoT uses DNS-over-TCP underneath TLS. Consequently, the backend server must support TCP/53.

Also verify:

NetWall -> DNS Server -> TCP/53

routing and policy.

UDP/53 works but the DoT configuration does not

Testing normal DNS with:

dig @10.0.0.53 www.example.com

will normally use UDP and therefore does not prove that the server accepts DNS over TCP.

Explicitly test:

dig @10.0.0.53 www.example.com +tcp

Security Considerations

The DNS traffic is encrypted only between the client and NetWall.

Client             NetWall              DNS Server

      encrypted                plaintext
      DNS/TLS                   DNS/TCP

   =============>            ------------>
      TCP/853                    TCP/53

Anyone able to observe the connection between NetWall and the DNS server may therefore be able to inspect the DNS traffic.

For this reason, the backend connection should preferably traverse a trusted network.

If end-to-end encrypted DNS between NetWall and an upstream resolver is required, a different architecture is needed.

DNS Security and Filtering

Using NetWall as the DoT endpoint provides an interesting integration point for centralized DNS security.

The basic configuration described in this article provides:

DoT client
     |
     | encrypted DNS
     v
NetWall
     |
     | TLS termination
     v
DNS server

This allows organizations to expose existing DNS infrastructure through an encrypted client-facing interface without modifying the DNS server itself.

Depending on the required deployment, DNS inspection and security controls may also be applied after TLS termination where supported by the applicable cOS Core configuration.

Summary

NetWall can be configured as a DNS-over-TLS gateway by combining the TLS functionality of an IP Policy with destination address and port translation.

The resulting architecture is:

                        NetWall
                 +--------------------+
                 |                    |
Client           |  TLS termination   |
DNS-over-TLS     |        |           |
TCP/853  ======> |        v           |
                 |   DNS-over-TCP     |
                 |        |           |
                 |   SAT to TCP/53    |
                 |        |           |
                 +--------+-----------+
                          |
                          v
                    DNS Resolver
                      TCP/53

This provides a simple method of adding DoT support in front of an existing DNS server while keeping the backend DNS infrastructure unchanged.

Related articles