Dns Security - Learning Module

Loading content...

0/228

DNS over TLS: Dedicated Encrypted DNS Transport

A Different Approach to DNS Encryption

While DNS over HTTPS (DoH) disguises DNS traffic as web browsing, DNS over TLS (DoT) takes a more direct approach—it wraps DNS queries in TLS encryption on a dedicated port (853). This design philosophy difference has significant implications for deployment, privacy, and network management.

DoT was standardized before DoH (RFC 7858, May 2016 vs. RFC 8484, October 2018) and represents the DNS community's initial solution to the DNS privacy problem. It answers the question: "How do we encrypt DNS with minimal protocol changes?" Rather than building on HTTP infrastructure, DoT simply adds TLS to the existing DNS-over-TCP transport.

What You Will Learn

By the end of this page, you will understand: (1) How DoT operates on port 853 with pure TLS encryption, (2) The connection establishment and message framing protocol, (3) Opportunistic vs. strict TLS modes and their security implications, (4) Authentication using SPKI pins and certificate chains, (5) Performance characteristics compared to traditional DNS and DoH, (6) Key differences between DoT and DoH for various use cases, and (7) Deployment considerations for clients and servers.

DoT Protocol Fundamentals

DNS over TLS takes the simplest possible approach to encrypting DNS: establish a TLS connection to a DNS server, then send standard DNS queries over that encrypted connection. This mirrors how HTTPS works with HTTP—the underlying protocol remains unchanged, only wrapped in encryption.

Core protocol characteristics:

Port 853 — Dedicated, well-known port for encrypted DNS (IANA assigned)
TLS 1.2/1.3 — Standard TLS encryption; TLS 1.3 preferred for performance
TCP transport — DoT uses TCP exclusively (no UDP option)
Standard DNS messages — Wire format identical to RFC 1035 DNS-over-TCP
Length-prefixed framing — Each DNS message preceded by 2-byte length field

Why port 853?

The dedicated port has advantages and disadvantages:

✅ Easy identification — Network operators can identify and manage DoT traffic
✅ No HTTP overhead — Simpler, more efficient than DoH
✅ Clear protocol separation — Distinct from web traffic

❌ Easy blocking — Firewalls can trivially block port 853
❌ Visible intent — Observers know you're using encrypted DNS
❌ Port may be restricted — Some networks only allow HTTP/HTTPS ports

Converting Mermaid diagram...

Message framing:

DoT uses the same length-prefixed framing as traditional DNS-over-TCP:

Each DNS message is preceded by a 2-byte length field (network byte order)
Length indicates the size of the following DNS message in bytes
Multiple queries can be pipelined on a single connection
Responses may arrive out of order (matched by transaction ID)

This is identical to DNS-over-TCP, making DoT implementation straightforward—existing DNS-over-TCP code works with DoT by simply wrapping the socket in TLS.

Connection management:

RFC 7858 recommends persistent connections:

Clients SHOULD reuse connections for multiple queries
Clients SHOULD NOT pipeline more than a few outstanding queries (prevents HoL blocking)
Servers SHOULD implement idle timeouts (recommended several seconds to minutes)
Either party can close the connection at any time

dot-wire-format.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# DNS over TLS Wire Format
# Connection: TCP to port 853, wrapped in TLS
 
# Step 1: TCP 3-way handshake (standard)
# Step 2: TLS handshake (standard TLS 1.3)
# Step 3: DNS query with length prefix
 
# DNS-over-TLS message format:
+------------------------+
| 2-byte length (MSB)    |  0x00 0x29 (41 bytes)
+------------------------+
| DNS Query Message      |  41 bytes of DNS wire format
|  - Transaction ID      |
|  - Flags               |
|  - Questions           |
|  - QNAME, QTYPE, QCLASS|
+------------------------+
 
# Example query for example.com A record:
# Length: 0x0029 (41 bytes)
# Transaction ID: 0xABCD
# Flags: 0x0100 (RD=1)
# QDCOUNT: 0x0001
# QNAME: 0x07example0x03com0x00
# QTYPE: 0x0001 (A)
# QCLASS: 0x0001 (IN)
 
00 29                              # Length: 41 bytes
AB CD 01 00 00 01 00 00 00 00 00 00 # Header
07 65 78 61 6D 70 6C 65            # "example"
03 63 6F 6D 00                     # "com"
00 01 00 01                        # Type A, Class IN
 
# Response follows same format:
# [2-byte length][DNS Response Message]

Padding for Privacy

RFC 7830 defines EDNS(0) Padding to obscure query/response sizes in encrypted DNS. Without padding, the length of encrypted messages can reveal information about queried domain names (e.g., google.com vs someverylongdomainname.example). DoT and DoH both support optional padding.

Authentication and Trust Models

DoT provides encryption, but encryption alone doesn't guarantee you're talking to the intended resolver. Authentication verifies the server's identity—crucial for preventing man-in-the-middle attacks where an attacker intercepts your encrypted DNS and decrypts it with their own certificate.

RFC 8310 defines two authentication modes:

Opportunistic TLS (unauthenticated encryption):

Client accepts any valid certificate
Encrypts traffic but doesn't verify server identity
Protects against passive eavesdroppers
Vulnerable to active MITM attacks
Appropriate when authentication is impossible

Strict TLS (authenticated encryption):

Client verifies server certificate validity
Validates certificate chain to trusted CA
Optionally verifies SPKI (public key) pin
Protects against both passive and active attacks
Recommended when resolver identity is known

DoT Authentication Methods
Method	Security Level	Configuration	Limitations
None (opportunistic)	Passive protection only	Accept any certificate	Vulnerable to MITM; false sense of privacy
PKIX (CA validation)	Standard TLS security	Verify cert chain; check hostname	Relies on CA trust; subject to CA compromise
SPKI Pin	Maximum security	Pin specific public key hash	Requires out-of-band pin distribution; pin rotation complexity
DANE (TLSA record)	DNS-secured authentication	TLSA record in DNSSEC-signed zone	Requires DNSSEC deployment; chicken-and-egg problem

SPKI (Subject Public Key Info) pinning:

For maximum security, clients can pin the resolver's public key. Instead of trusting any certificate from a valid CA, the client only accepts certificates containing a specific public key. This protects against:

CA compromise (attacker obtains fraudulent certificate)
Certificate misissuance (CA accidentally issues wrong certificate)
Government coercion of CAs (forced certificate issuance)

How SPKI pinning works:

Obtain resolver's public key hash (SPKI pin) via trusted channel
Configure client with resolver hostname and SPKI pin
On connection, client extracts public key from certificate
Client computes hash and compares to configured pin
Connection only proceeds if pin matches

DANE (DNS-Based Authentication of Named Entities):

DANE uses DNSSEC to publish certificate information in DNS:

TLSA records contain certificate/public key constraints
DNSSEC signatures authenticate the TLSA records
Client validates certificate against TLSA record

Challenge: Using DNS to authenticate DNS creates a chicken-and-egg problem—you need authenticated DNS to get TLSA records, but you're trying to establish authenticated DNS. Solutions involve trust-on-first-use or out-of-band bootstrapping.

dot-authentication.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
# DoT Server Authentication Examples
 
# 1. Opportunistic Mode (no authentication)
# Client connects but accepts any certificate
# Only protects against passive eavesdropping
 
[Network.DoT]
servers = ["9.9.9.9:853"]
mode = "opportunistic"  # Accept any cert
 
---
 
# 2. Strict Mode with Hostname Verification
# Validates certificate against hostname and CA chain
 
[Network.DoT]
servers = ["dns.quad9.net:853"]
mode = "strict"
hostname = "dns.quad9.net"  # Verify CN/SAN
 
---
 
# 3. SPKI Pinning (maximum security)
# Only accept certificate with specific public key
 
# Get SPKI pin for Cloudflare:
$ echo | openssl s_client -connect 1.1.1.1:853 2>/dev/null | \
    openssl x509 -pubkey -noout | \
    openssl pkey -pubin -outform der | \
    openssl dgst -sha256 -binary | \
    openssl enc -base64
 
# Output: GP8Knf7qBae+aIfythytMbYnL+yowaWVeD6MoLHkVRA=
 
[Network.DoT]
servers = ["1.1.1.1:853"]
mode = "strict"
hostname = "cloudflare-dns.com"
spki_pins = ["GP8Knf7qBae+aIfythytMbYnL+yowaWVeD6MoLHkVRA="]
 
---
 
# 4. DANE/TLSA (DNSSEC-based)
# TLSA record in DNS zone:
 
_853._tcp.dns.example.com. IN TLSA 3 1 1 (
    E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
)
 
# Usage Type 3: Domain-issued certificate
# Selector 1: Match SubjectPublicKeyInfo
# Matching Type 1: SHA-256 hash

Opportunistic Is Not Secure

Opportunistic DoT protects only against passive observers. An active attacker can intercept the connection, present their own certificate (which the client accepts), decrypt queries, forward to the real resolver, and observe everything. For security against active attackers, use strict mode with hostname verification or SPKI pinning.

DoT vs DoH: A Detailed Comparison

DoT and DoH both encrypt DNS queries but differ significantly in their design philosophies, deployment characteristics, and suitability for different use cases. Understanding these differences helps choose the right protocol for specific scenarios.

Design philosophy difference:

DoT: "Add encryption to DNS with minimal changes" — Uses dedicated port, standard DNS framing, straightforward implementation.
DoH: "Make DNS indistinguishable from web traffic" — Uses HTTPS infrastructure, benefits from HTTP features, harder to block/detect.

Comprehensive DoT vs DoH Comparison
Aspect	DNS over TLS (DoT)	DNS over HTTPS (DoH)
Port	853 (dedicated)	443 (shared with HTTPS)
Protocol Stack	TLS → TCP → DNS	TLS → TCP → HTTP/2 → DNS
Detectability	Easily identified on port 853	Indistinguishable from web traffic
Blockability	Trivially blocked by firewall	Requires IP blocking or inspection
Overhead	Minimal (TLS only)	HTTP framing adds ~50-100 bytes
Multiplexing	No (one query per round-trip)	Yes (HTTP/2 streams)
Caching	No HTTP cache support	Standard HTTP caching works
Implementation Complexity	Simpler (TLS wrapper)	More complex (full HTTP stack)
Connection Setup	2 RTT (TCP + TLS)	2-3 RTT (TCP + TLS + HTTP)
Network Operator Control	Can monitor/block encrypted DNS	Cannot distinguish from web
Browser Support	Limited (mostly mobile)	Extensive (Firefox, Chrome, Edge)
OS Support	Android 9+, iOS, some Linux	Windows 11, macOS, iOS 14+

When to Use DoT

•Network operators want visibility — DoT's dedicated port allows operators to permit encrypted DNS while monitoring its use
•Minimal protocol overhead needed — IoT devices, embedded systems with limited resources
•Enterprise deployment — Easier to proxy/inspect at network edge when needed
•Android 9+ devices — Native 'Private DNS' setting uses DoT
•Simple implementation required — Adding TLS to existing DNS code is straightforward

When to Use DoH

•Maximum censorship resistance — Traffic looks like web browsing; hard to block without collateral damage
•Browser-integrated privacy — Firefox, Chrome have built-in DoH support
•Restrictive networks — Only ports 80/443 allowed; port 853 blocked
•HTTP/2 benefits needed — Multiplexing for many simultaneous queries
•CDN caching desired — HTTP cache semantics enable edge caching

The network operator perspective:

DoT and DoH have dramatically different implications for network operators:

With DoT:

Operators can see encrypted DNS is in use (port 853 traffic)
Operators can allow/block encrypted DNS as policy dictates
Operators can redirect port 853 to internal encrypted resolver
Security teams can monitor for unusual DoT usage patterns

With DoH:

Operators cannot distinguish DNS from web traffic
Blocking requires IP-level blocking (affects all services on that IP)
Users can bypass network DNS policy entirely
Security visibility is significantly reduced

The user perspective:

For privacy-focused users, the calculus is different:

DoT advantages:

Slightly lower latency (no HTTP overhead)
Simpler protocol may have fewer bugs
Works well on mobile (Android native support)

DoH advantages:

Cannot be selectively blocked
Hides the fact that you're using encrypted DNS
Works on restrictive networks (port 443 rarely blocked)

The Political Dimension

The DoT vs DoH debate isn't purely technical—it's also about control. DoT was designed with network operator interests in mind (identifiable, manageable). DoH was designed with user privacy against network operators in mind (undetectable, unblockable). Both designs are technically valid; preference depends on threat model and trust assumptions.

Performance Analysis

Performance is a critical consideration for encrypted DNS. Users won't accept significant latency increases for privacy. Understanding DoT's performance characteristics helps optimize deployments.

Latency breakdown:

Initial connection (cold start):

TCP handshake: 1 RTT
TLS 1.3 handshake: 1 RTT
DNS query/response: 1 RTT
Total: 3 RTT for first query

Subsequent queries (warm connection):

DNS query/response: 1 RTT
Total: 1 RTT per query

Connection resumption (TLS session ticket):

TCP handshake: 1 RTT
TLS resumption: 0-1 RTT (0-RTT with early data)
DNS query/response: piggybacked on TLS
Total: 1-2 RTT for resumed connection

Performance Comparison Across DNS Protocols
Metric	Traditional DNS (UDP)	Traditional DNS (TCP)	DoT	DoH
First Query Latency	1 RTT	3 RTT	3 RTT	3-4 RTT
Subsequent Queries	1 RTT each	1 RTT each	1 RTT each	1 RTT each
Connection Overhead	0 bytes	~60 bytes (TCP)	~60 bytes (TCP)	~100+ bytes (HTTP)
TLS Handshake Size	N/A	N/A	~2KB typical	~2KB typical
Query Multiplexing	❌	Limited	Limited	✅ HTTP/2 streams
Connection Persistence	❌ Stateless	✅ Optional	✅ Recommended	✅ Standard
TLS Session Resumption	N/A	N/A	✅ Supported	✅ Supported

Optimization strategies:

Connection pooling — Maintain persistent connections to avoid repeated TLS handshakes
TLS 1.3 — Reduces handshake from 2 RTT (TLS 1.2) to 1 RTT; supports 0-RTT resumption
0-RTT early data — TLS 1.3 allows sending DNS query in resumption handshake (security caveats apply—replay possible)
TCP Fast Open — Sends data in SYN packet; reduces TCP handshake to 0 RTT for resumed connections
Connection warming — Proactively establish connections during idle time
Pipelining — Send multiple queries without waiting for responses (limited by head-of-line blocking)

Head-of-line blocking:

Unlike DoH with HTTP/2 multiplexing, DoT over TCP suffers from head-of-line blocking. If one query's response is delayed or lost, subsequent responses queue behind it. This is why RFC 7858 recommends limiting outstanding pipelined queries.

Comparison with UDP DNS:

Traditional DNS over UDP has inherent performance advantages:

No connection establishment (stateless)
Single RTT per query
No TLS overhead

However, UDP DNS lacks reliability—lost packets require application-layer retries with exponential backoff. On lossy networks, DoT's TCP reliability can outperform UDP's retries.

dot-performance-test.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
#!/bin/bash
# DoT Performance Testing with kdig (from knot-dns)
 
# Install: apt install knot-dnsutils
 
# Test DoT query latency
$ time kdig +tls @1.1.1.1 example.com A
 
# Output:
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(AES-256-GCM)
;; Query time: 45 msec
;; SERVER: 1.1.1.1#853(1.1.1.1)
;; WHEN: ...
;; MSG SIZE rcvd: 56
 
---
 
# Compare with traditional DNS
$ time kdig @1.1.1.1 example.com A
 
;; Query time: 12 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
 
---
 
# Test with connection reuse (-k = keepalive)
$ kdig +tls -k @1.1.1.1 example.com A google.com A github.com A
 
# First query: ~45ms (includes TLS handshake)
# Subsequent: ~12ms (connection reused)
 
---
 
# Test TLS 1.3 0-RTT resumption
# First connection caches session ticket
$ kdig +tls +fastopen @1.1.1.1 example.com A
 
# Second connection uses 0-RTT
$ kdig +tls +fastopen @1.1.1.1 google.com A
;; TLS session resumed (0-RTT)
;; Query time: 15 msec
 
---
 
# Benchmark multiple resolvers
for resolver in 1.1.1.1 8.8.8.8 9.9.9.9; do
    echo "Testing $resolver (DoT):"
    for i in {1..5}; do
        kdig +tls +short @$resolver example.com A 2>&1 | tail -1
    done
done

Real-World Performance

In practice, DoT performance is acceptable for most users. With connection reuse, the per-query overhead is minimal. The initial connection setup (3 RTT) is noticeable but amortized across many queries. Well-configured DoT typically adds 10-30ms to resolution—imperceptible in most applications.

Deployment and Implementation

Deploying DoT requires configuration at both client and server levels. The ecosystem has matured significantly, with native support in major operating systems and numerous resolver implementations.

Client deployment options:

DoT Client Configuration

•Android 9+ (Private DNS) — Settings → Network → Private DNS → Enter hostname (e.g., dns.google). Native OS-level DoT; applies to all apps.
•iOS/macOS — Configuration Profile with DNS Settings payload. Install profile to enable DoT for specific resolvers. Third-party apps like DNSecure also work.
•Linux (systemd-resolved) — Edit /etc/systemd/resolved.conf; set DNS= and DNSOverTLS=yes. Applies system-wide.
•Linux (Stubby) — Lightweight DoT stub resolver. Configure /etc/stubby/stubby.yml with upstream resolvers. Point /etc/resolv.conf to 127.0.0.1.
•Windows — No native DoT (Windows 11 has DoH only). Use Stubby, dnscrypt-proxy, or similar local resolver.
•Router-level — OpenWrt with Stubby or Unbound. Provides DoT for all network devices. Example: AdGuard Home, Pi-hole with Unbound.

dot-configuration.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
# Android Private DNS Configuration
# Settings → Network & internet → Private DNS
# Enter hostname: dns.google, one.one.one.one, or dns.quad9.net
 
---
 
# Linux: systemd-resolved DoT Configuration
# /etc/systemd/resolved.conf
 
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com
DNSOverTLS=yes
# Options: yes (strict), opportunistic, no
 
# Restart: systemctl restart systemd-resolved
# Verify: resolvectl status
 
---
 
# Linux: Stubby DoT Resolver
# /etc/stubby/stubby.yml
 
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
 
upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: GP8Knf7qBae+aIfythytMbYnL+yowaWVeD6MoLHkVRA=
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 9.9.9.9
    tls_auth_name: "dns.quad9.net"
 
listen_addresses:
  - 127.0.0.1
  - 0::1
 
---
 
# macOS: DNS Configuration Profile (mobileconfig)
# Create with Apple Configurator or Profile Creator
 
<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
    <key>PayloadContent</key>
    <array>
        <dict>
            <key>DNSSettings</key>
            <dict>
                <key>DNSProtocol</key>
                <string>TLS</string>
                <key>ServerAddresses</key>
                <array>
                    <string>1.1.1.1</string>
                    <string>1.0.0.1</string>
                </array>
                <key>ServerName</key>
                <string>cloudflare-dns.com</string>
            </dict>
        </dict>
    </array>
</dict>
</plist>

Server-side DoT deployment:

Organizations can deploy their own DoT servers:

Popular DoT-capable resolvers:

Unbound — Full-featured recursive resolver with TLS frontend
Knot Resolver — Modern resolver with native DoT/DoH support
dnsdist — DNS load balancer with DoT termination/forwarding
CoreDNS — Kubernetes-native DNS with TLS plugins
BIND 9.17+ — Added DoT support in recent versions

Certificate management:

DoT servers need valid TLS certificates:

Use Let's Encrypt for free, automated certificates
Certificate must match hostname clients use for authentication
Implement automated renewal (certbot + reload script)
Consider certificate monitoring for expiration alerts

Firewall Considerations

DoT servers listen on TCP port 853. Ensure firewall rules allow inbound connections. Unlike UDP DNS, DoT requires persistent TCP connections—ensure connection tracking and timeout settings accommodate this. NAT timeout should exceed server idle timeout to prevent connection drops.

Security Considerations

While DoT significantly improves DNS security, understanding its limitations and potential attack vectors is essential for proper implementation.

What DoT protects against:

Passive eavesdropping — Observers cannot read DNS query contents
Query manipulation — Encrypted queries cannot be modified in transit
ISP tracking — ISP cannot log which domains you query
Local network snooping — Café WiFi operators cannot see your DNS traffic

What DoT does NOT protect against:

DoT Security Limitations

•Resolver operator surveillance — Your DoT resolver sees all your queries (you've moved trust, not eliminated it)
•Traffic analysis — Connection timing and sizes can reveal information even without content
•IP address exposure — The resolver knows your IP address; queries are linked to you
•Malicious resolver responses — If resolver lies, DoT doesn't detect it (DNSSEC needed)
•DNS rebinding attacks — DoT doesn't prevent malicious record content
•Endpoint compromise — If client device is compromised, all queries are visible locally
•Certificate attacks — Compromised CA could enable MITM against opportunistic mode

Side-channel attacks:

Encrypted DNS can still leak information through side channels:

Message size analysis — Query length correlates with domain name length; response size reveals record count/type. Padding (RFC 7830) mitigates but doesn't eliminate.
Timing analysis — Resolution timing patterns reveal caching behavior, query frequency, and potentially visited domains.
Connection destination — IP address of DoT resolver is visible. Using well-known resolvers (1.1.1.1, 8.8.8.8) reveals you're using encrypted DNS.
TLS fingerprinting — Client TLS fingerprint may identify specific applications/configurations.

Downgrade attacks:

Strict DoT provides protection, but opportunistic mode is vulnerable:

Attacker blocks port 853 → client falls back to unencrypted DNS
Attacker intercepts connection → presents own certificate (accepted in opportunistic mode)
User thinks DNS is encrypted but it's completely compromised

Mitigation: Always use strict mode with authentication when possible. If resolver identity is known, configure hostname verification and/or SPKI pinning.

DoT Security Recommendations
Scenario	Recommendation	Configuration
General privacy	Strict mode with hostname verification	Verify certificate CN/SAN matches expected host
High-security environment	Strict mode with SPKI pinning	Pin resolver's public key hash
Untrusted network	Strict mode + DoT-only (no fallback)	Disable fallback to unencrypted DNS
Mobile devices	Android Private DNS feature	Use hostname-based configuration
Enterprise	Internal DoT resolver + certificate	Company CA or managed certificates
Maximum anonymity	DoT through VPN/Tor + separate resolver	Chain privacy layers

Defense in Depth

DoT is one layer in a complete privacy strategy. For comprehensive protection: (1) Use DoT/DoH for query encryption, (2) Choose a trusted resolver with strong privacy policy, (3) Enable DNSSEC validation for response authenticity, (4) Use VPN/Tor for IP privacy, (5) Use HTTPS everywhere for content encryption, and (6) Consider Encrypted Client Hello for SNI privacy.

Summary: DNS over TLS

DNS over TLS provides a straightforward approach to encrypting DNS queries using standard TLS on a dedicated port. Its design favors simplicity and network manageability over the censorship-resistance focus of DoH.

Let's consolidate the key concepts:

Key Takeaways

•DoT wraps DNS in TLS on port 853 — Same wire format as DNS-over-TCP, just encrypted.
•Dedicated port enables network management — Operators can identify, allow, or block encrypted DNS traffic.
•Authentication matters critically — Opportunistic mode (no verification) only protects against passive observers; strict mode with hostname/SPKI verification protects against active attacks.
•Performance is acceptable with connection reuse — Initial 3-RTT latency amortizes across many queries on persistent connections.
•DoT vs DoH is a design philosophy difference — DoT: manageable, dedicated, simpler. DoH: unblockable, hidden, HTTP-integrated.
•Client support is strongest on mobile — Android 9+ has native DoT; iOS via profiles; desktop requires stub resolvers.
•DoT encrypts but doesn't authenticate responses — Combine with DNSSEC for complete DNS security.

What's next:

Encrypted DNS protects against network-level threats, but DNS infrastructure faces many other attack vectors. The next page examines DNS attacks—the various ways attackers exploit DNS weaknesses, from cache poisoning and amplification attacks to DNS tunneling and hijacking. Understanding attack techniques is essential for implementing effective defenses.

Page Complete

You now understand DNS over TLS: its protocol mechanics, authentication models, performance characteristics, and how it compares to DoH. Combined with DNSSEC and DoH knowledge, you can evaluate encrypted DNS solutions for various deployment scenarios. Next, we'll explore the threats these security measures protect against.