Email and DNS security
Encrypted DNS and a final zone review
Separate DNSSEC validation from encrypted transport, then inspect one real zone from delegation through web, mail, and security records.
Classic DNS travels in plain text. Anyone on the path between you and your resolver, the coffee shop wifi, your ISP, can read every name you look up and change the answers. Encrypted DNS fixes that first hop.
DoT and DoH
DNS over TLS, or DoT, wraps DNS in a TLS connection on its own port, 853. DNS over HTTPS, or DoH, sends DNS queries inside ordinary HTTPS traffic on port 443, so it blends in with web traffic.
Both encrypt the exchange between your device and a resolver that supports them. A local observer can’t read the names or tamper with the replies.
What encryption doesn’t change
Encryption moves the trust. It doesn’t remove it. The resolver you chose still sees every name you ask for. It can still log, filter, or block.
And only the first hop is encrypted. When your resolver goes on to ask the authoritative servers, those queries are whatever they’ve always been.
DNSSEC is a different thing
People mix these up constantly, so here’s the split:
- DoH and DoT protect the transport between you and the resolver.
- DNSSEC lets the resolver authenticate the data it receives.
Encrypted transport can deliver a wrong answer very securely. DNSSEC can authenticate a correct answer while the whole world watches you ask. You want both. They solve different problems.
A debugging gotcha
Browsers can use their own DoH resolver and skip the operating system entirely. Then Firefox resolves names through Cloudflare while dig on the same machine uses your router. They can disagree, and internal company names or local filtering vanish inside the browser.
When something resolves differently in a browser than in the terminal, find out which resolver each one is really using before you blame DNS.
The final review
Time to put the course together. Pick a domain you control, or one you can inspect safely, and review the whole zone from the top:
dig +trace example.com
dig SOA example.com
dig A example.com
dig AAAA example.com
dig MX example.com
dig TXT example.com
dig +dnssec A example.com
curl -I https://example.com/For every answer, write down the owner, type, value, TTL, which provider is authoritative for it, and which service consumes it.
Keep observations and conclusions apart. An A answer proves address data exists, not that HTTPS works. An SPF record proves a policy is published, not that every legitimate sender passes DMARC.
Then propose one safe change. Old value, new value, current TTL, when you’d lower it, how you’d test the new service with curl --resolve, the direct-authority check, the resolver comparison, the rollback trigger, and when the old service can go.
Try this as your last exercise: produce that one-page zone review. End with the three biggest risks you found, and for each one the exact evidence that would prove it’s gone.
Lesson completed