DNS over TLS Explained: How DoT Protects Resolver Traffic

Traditional DNS queries are commonly sent without encryption. Anyone able to observe the path between a device and its recursive resolver may be able to see the names being requested, and an active attacker on that path may try to interfere with the exchange. DNS over TLS, usually shortened to DoT, protects this part of resolution by carrying DNS messages through an encrypted TLS connection.

DoT improves confidentiality and integrity between the client and the selected resolver. It does not hide every network destination, make the user anonymous, or automatically protect communication beyond the resolver. Understanding that boundary is essential when deciding where and how to deploy it.

How DNS over TLS works

A device first establishes a TCP connection to a DoT-capable recursive resolver, conventionally on port 853. It then performs a TLS handshake, validates the resolver’s identity according to the configured authentication policy, and sends ordinary DNS messages inside the encrypted connection.

The DNS questions and answers retain their normal wire format. TLS changes the transport channel rather than the records themselves. Connections can be reused for multiple queries, which avoids repeating the full setup for every lookup and reduces overhead.

The recursive resolver still performs the rest of the lookup process: it uses cached data when available or queries root, top-level-domain, and authoritative servers. The existing article Recursive DNS server explained describes that role in more detail.

DoT compared with traditional DNS

Conventional DNS commonly uses UDP on port 53 and switches to TCP when required. Those transports do not provide encryption or server authentication by themselves. DoT places DNS inside TLS, adding confidentiality, integrity protection, and the ability to authenticate the resolver endpoint.

Encryption prevents a local observer from directly reading the DNS payload between client and resolver. It also makes undetected modification of that protected exchange much harder. However, an observer may still infer activity from destination IP addresses, connection timing, traffic volume, and other metadata.

DoT compared with DNS over HTTPS

DNS over HTTPS, or DoH, also encrypts DNS messages with TLS, but it carries them through HTTPS and normally uses port 443. DoT uses a dedicated DNS-over-TLS service, conventionally on port 853. A practical comparison is available in the ClouDNS guide to DoT and DoH, placed here in the first half of the article.

The dedicated port makes DoT easier for network administrators to identify, permit, redirect, or block. DoH can blend with ordinary HTTPS traffic and is frequently configured inside a browser or application. That can be useful on restrictive networks but may bypass local DNS policy, internal zones, or organization-approved filtering.

Neither protocol is universally superior. A managed network may prefer system-level DoT for clear policy control, while a browser or application may use DoH for portability. The important questions are who selects the resolver, how its identity is authenticated, what happens when encryption fails, and whether all applications follow the same policy.

Privacy and security benefits

Protection on untrusted local networks

On public Wi-Fi or another network you do not control, plaintext DNS can expose query names to nearby or on-path observers. DoT encrypts the DNS exchange from the device to the configured resolver, reducing this local visibility.

Integrity of the client-to-resolver channel

TLS detects modification of protected messages and authenticates the server when certificate verification and resolver naming are configured correctly. This helps prevent a network attacker from silently replacing DNS answers on that segment.

Consistent resolver choice

A device configured with a known DoT resolver can use the same service across multiple networks rather than automatically accepting the DNS server advertised by each local router. This creates a clearer trust relationship, although it also makes the selected resolver an important dependency.

The limits of DNS over TLS

DoT protects only the connection between the client and recursive resolver. The resolver sees the questions it must process and may associate them with connection metadata. Resolver selection therefore matters. Review the operator’s logging, retention, filtering, jurisdiction, security, and availability policies.

Communication from the recursive resolver to authoritative DNS servers is not automatically encrypted merely because the client used DoT. The resolver may use ordinary DNS upstream unless the architecture explicitly supports additional protected transports.

DoT also does not conceal the IP address contacted after resolution, secure an unsafe website, replace HTTPS, block malware by itself, or guarantee anonymity. It is one privacy and transport-security control within a larger system.

DoT and DNSSEC solve different problems

DoT encrypts and authenticates a transport channel to a resolver. DNSSEC allows a validating resolver to verify signatures on DNS data and build a chain of trust from the root. A resolver can use both: DoT protects the client connection, while DNSSEC validation checks the authenticity and integrity of signed records.

The article DNSSEC explained covers that separate security model. Neither mechanism repairs an incorrect record; authenticated incorrect data remains incorrect.

Strict authentication and fallback behavior

Encryption without reliable endpoint authentication may connect the client securely to the wrong resolver. A strong deployment knows the intended resolver identity and validates its certificate. The client should also have a defined policy for connection failure.

A strict policy refuses to send the query in plaintext when the authenticated DoT service is unavailable. This preserves privacy but can interrupt DNS resolution during an outage or blocked connection. An opportunistic policy may fall back to ordinary DNS, improving reachability but allowing a network to force a downgrade and observe queries.

The appropriate choice depends on the environment and risk model. Whichever behavior is chosen should be visible, documented, and monitored rather than silently assumed.

Where DoT can be configured

Operating system

System-level configuration can protect queries from multiple applications and give administrators a consistent policy. Implementation details vary, and applications that use their own resolver libraries may bypass the system setting.

Router or gateway

A local gateway can accept DNS from client devices and forward it to an external resolver over TLS. This protects the gateway-to-resolver segment, but client-to-gateway queries may remain unencrypted unless the local network uses an encrypted mechanism as well.

Local forwarding resolver

A managed forwarding service on the device or network can provide caching, policy, and DoT upstream. Administrators must secure the local listener and ensure that firewall rules do not expose an unintended open resolver.

Testing a DNS over TLS deployment

Begin with ordinary lookups to establish expected answers. The site’s DNS lookup guide explains common tools, but note that a standard dig query does not prove the operating system used DoT.

Verify the deployment at several layers:

1. Confirm resolver identity. Check the configured endpoint name and successful certificate validation.
2. Verify the transport. Use client logs, resolver logs, packet capture, or platform diagnostics to confirm TLS on the expected connection.
3. Test normal records. Resolve A, AAAA, MX, and other types used by applications.
4. Test DNSSEC behavior. Confirm that valid signed domains resolve and known validation failures are handled as expected.
5. Test failure policy. Block or stop the DoT endpoint temporarily in a controlled environment and observe whether the client fails closed or falls back.
6. Check internal names. Ensure corporate, VPN, split-horizon, and local-service names continue to resolve under the selected policy.
7. Measure performance. Compare connection setup, reused-connection latency, cache behavior, and failure recovery.

Operational considerations

Port 853 must be reachable through relevant firewalls and captive networks. The resolver needs valid certificates, capacity for TLS connections, connection reuse, monitoring, and protection against resource exhaustion. Clients need accurate time for certificate validation and a trusted certificate store.

High availability is important because an enforced encrypted resolver becomes a critical dependency. Configure supported backup endpoints carefully and make sure failover does not silently select a resolver with a different privacy or filtering policy.

The protocol requirements and message framing for DNS over TLS are defined in RFC 7858: Specification for DNS over Transport Layer Security.

Conclusion

DNS over TLS protects DNS messages between a client and recursive resolver with an authenticated encrypted connection. Its dedicated transport is well suited to system and network policy, but the privacy benefit depends on correct certificate validation, a trustworthy resolver, explicit fallback behavior, and reliable operations. Use DoT alongside HTTPS, DNSSEC validation, secure endpoints, and clear monitoring rather than treating it as a complete privacy solution.

How to Set Up DMARC: Policy, Alignment, and a Safe Rollout

A domain can have working email and still be vulnerable to impersonation. Attackers may place its name in the visible From address, hoping recipients will trust a message that did not come from an approved system. DMARC gives domain owners a way to connect SPF and DKIM authentication to that visible identity, request reports, and tell participating receivers how to handle messages that fail.

A safe DMARC setup is a process rather than a single aggressive DNS change. The reliable approach is to inventory every legitimate sender, make SPF or DKIM align correctly, begin with a monitoring policy, study the reports, fix gaps, and then move gradually toward quarantine or rejection.

What DMARC does

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. A receiving mail system evaluates SPF and DKIM results, checks whether the authenticated domain aligns with the domain shown in the message’s From header, and applies the published DMARC policy.

A message can pass DMARC when at least one of these paths succeeds:

• SPF passes and its authenticated MailFrom domain aligns with the visible From domain.
• DKIM passes and the domain in a valid DKIM signature aligns with the visible From domain.

Requiring alignment is important. SPF alone authenticates the envelope sender used during delivery, which may differ from the address a person sees. DKIM authenticates the signing domain, which also may be different. DMARC connects a successful authentication result to the visible identity. For a broader overview of the mechanism and its anti-phishing purpose, see this guide to DMARC.

Prepare SPF and DKIM first

Confirm every legitimate sending source

Create an inventory of systems that send mail using the domain: primary mail providers, marketing platforms, support desks, transaction services, billing tools, monitoring systems, website forms, and any service that sends on behalf of a subdomain. An incomplete inventory is the most common reason legitimate mail begins failing when enforcement increases.

Check SPF authorization and alignment

SPF lists which systems may send for an envelope domain. Make sure each legitimate source is covered without creating multiple SPF records or exceeding the protocol’s DNS-lookup limits. The existing article on how the SPF record works explains the authorization side in more detail.

For DMARC, an SPF pass is useful only when the authenticated MailFrom domain aligns with the visible From domain. Under relaxed alignment, the domains may share the same organizational domain. Strict alignment requires an exact match. A third-party platform may therefore pass its own SPF check but still fail the SPF path for your DMARC policy unless it supports a custom aligned return-path domain.

Enable DKIM signing with an aligned domain

DKIM adds a cryptographic signature to the message. The receiver retrieves the public key from DNS and verifies that signed parts of the message were not altered. Review the DKIM record guide if you need a refresher on selectors and public keys.

For DMARC alignment, the domain in the DKIM signature’s d= value must align with the visible From domain. Many email platforms support custom DKIM signing for this reason. DKIM often survives forwarding better than SPF, although mailing-list modifications can invalidate a signature if they change signed content.

Create the DMARC TXT record

Publish DMARC as a TXT record at _dmarc.example.com, replacing example.com with the domain used in the visible From address. A sensible monitoring record can look like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100

The essential tags are straightforward:

• v=DMARC1 identifies the protocol version and must appear first.
• p=none requests monitoring without asking receivers to quarantine or reject failures.
• rua provides one or more addresses for aggregate reports.
• pct specifies the percentage of applicable messages subject to the requested policy; 100 is the default.

Use a real, monitored mailbox or a suitable report-processing service for aggregate reports. Reports are typically XML files and may arrive in volume. Confirm that the receiving mailbox can handle the traffic and treat report data according to the organization’s privacy and retention requirements.

Understand policy and alignment options

Policy levels

• p=none: Request reporting and normal receiver handling. Use it to discover legitimate senders and authentication gaps.
• p=quarantine: Ask receivers to treat failing messages as suspicious, often by placing them in spam or applying extra scrutiny.
• p=reject: Ask receivers to reject messages that fail DMARC evaluation.

These are requested policies, and final message handling remains with the receiver. Moving directly to p=reject can block legitimate traffic if a forgotten service lacks alignment.

Relaxed and strict alignment

The aspf and adkim tags control SPF and DKIM alignment. Relaxed mode, represented by r, is the default and permits aligned subdomains within the same organizational domain. Strict mode, represented by s, requires the domains to match exactly. Strict alignment is not inherently necessary for every domain; use it only when sending architecture and policy require the tighter match.

Subdomain policy

The sp tag can define a separate requested policy for subdomains. Before setting it, identify subdomains that send mail and those used only for websites or services. A domain that should never send mail can often use stronger controls, but verify that no operational tool depends on it first.

Read aggregate reports before enforcing

Aggregate reports summarize how participating receivers see mail claiming to use the domain. They commonly show source IP addresses, message counts, SPF and DKIM results, alignment outcomes, and the policy applied. They do not automatically tell you whether a source is legitimate; administrators must map sources to known services and investigate unfamiliar traffic.

Use the monitoring period to answer practical questions:

• Which approved platforms send mail for the domain?
• Does each source pass aligned SPF, aligned DKIM, or both?
• Are forwarding and mailing-list flows producing expected failures?
• Do unknown sources indicate spoofing, stale systems, or an incomplete inventory?
• Are high-volume failures concentrated in one provider or subdomain?

Move to enforcement gradually

1. Start with p=none. Collect enough representative reports to cover normal campaigns, billing cycles, and infrequent systems.
2. Fix legitimate senders. Configure aligned DKIM or a custom return path, remove obsolete sources, and correct DNS records.
3. Test quarantine. Move to p=quarantine after known sources pass consistently. Continue checking reports and support feedback.
4. Increase coverage deliberately. If using pct during rollout, increase it only after reviewing the affected traffic and understanding receiver behavior.
5. Adopt reject when ready. Use p=reject when legitimate sources are aligned, exceptions are documented, and monitoring is ongoing.

DMARC does not replace correct mail routing. MX records still identify where inbound mail should be delivered, while DMARC evaluates messages that claim to come from a domain. The article MX record: Why is it important? explains that separate role.

Verify and maintain the deployment

After publishing the TXT record, query the exact _dmarc name from multiple resolvers and confirm that only one syntactically valid DMARC record is returned. Send controlled tests through every approved platform, inspect authentication results in message headers, and verify that aggregate reports begin arriving.

Continue reviewing reports after enforcement. Vendors, sending IPs, return-path domains, and DKIM selectors change over time. Add DMARC review to the onboarding and removal process for every email service, protect access to DNS and mail-provider accounts, and rotate DKIM keys according to provider capabilities and policy.

The protocol’s discovery, alignment, policy, and reporting model is defined in RFC 7489: Domain-based Message Authentication, Reporting, and Conformance.

Conclusion

A successful DMARC setup begins with visibility. Inventory legitimate senders, establish aligned SPF or DKIM, publish a monitoring record, analyze aggregate reports, and correct failures before enforcement. Gradual movement from none to quarantine and then reject protects legitimate mail while making domain impersonation harder and giving administrators useful feedback about abuse.

DNSSEC explained

DNSSEC can be spotted as an application to, in other cases, insecure DNS. It brings cryptography within and a complete line of trust. That is a guarantee for each level and implements top-notch security for your domain. 

What is DNSSEC?

The short DNSSEC is an acronym for Domain Name System Security Extensions. The primary DNS is reliable and fast, but its downside is that it lacks security. Back in the days when it was created, it wasn’t that of a problem. Later on, things change.