Networking / Intermediate: lifecycle, trust, and application protocols / Lesson 9

Trace DNS resolution, caching, and trust

Separate authoritative data, recursive behavior, negative caching, DNSSEC validation, and encrypted resolver transport in a naming diagnosis.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Follow delegation and record-type-specific answers.
Interpret positive and negative cache lifetimes.
Distinguish DNSSEC integrity from DNS transport privacy.

Resolution follows a hierarchy of authority

A recursive resolver can follow delegations from parent zones to authoritative servers and cache the resulting record sets. A zone cut and an ordinary record are different pieces of the naming design. CNAME aliases introduce another lookup relationship, while the requested type still matters at the eventual answer. Split DNS can intentionally return different data to different resolver populations. Therefore compare the exact query, resolver view, and authority before declaring disagreement a fault. A browser or operating-system cache can add another layer between the user and the resolver being examined.

Each cached record set has its own clock

TTL applies to the relevant cached data under DNS rules. In an alias chain, different record sets can have different lifetimes; a complete derived answer may need several still-valid pieces. Do not assume updating one authoritative record instantly removes every client’s old result. Plan changes by accounting for existing TTLs, negative caches, application reuse, and connection pools. A cached answer is not a lease of an address to a client. Preserve the observed remaining TTL and query time rather than treating a screenshot as permanently representative.

python Compare two synthetic cache clocks

records = {'alias': {'ttl': 60, 'age': 45}, 'address': {'ttl': 300, 'age': 45}}
for name, record in records.items():
    print(f"{name}_remaining={max(0, record['ttl'] - record['age'])}")

Expected output

alias_remaining=15
address_remaining=255

The alias has 15 seconds remaining and the address record 255. They are separate fixture records, not a real resolver query or a universal caching implementation.

Different negative outcomes require different actions

NXDOMAIN states that the queried name does not exist in the relevant DNS context, while a no-data result can mean the name exists without the requested record type. Referrals, empty answers, and temporary failures need their surrounding response fields for correct interpretation. Negative caching uses protocol-defined information rather than blindly copying a positive record’s TTL. SERVFAIL can reflect upstream trouble or validation failure and should not be converted into a permanent nonexistent-name conclusion. A diagnosis should preserve response category, authority context, and whether validation was requested or performed.

Data validation and encrypted transport solve different problems

DNSSEC can authenticate data origin and integrity through a validated chain of trust for signed DNS data. It does not encrypt the query or prove that the named application is safe. DNS over TLS or HTTPS protects a resolver transport hop under its own authentication and trust model; it does not replace authoritative DNSSEC validation. Validation can fail because of broken chains, expired signatures, incorrect time, or other conditions. Do not disable validation merely to hide an unexplained failure. Establish which layer failed and compare the relevant trusted configuration and timing in a prepared offline case.

python Keep three trust milestones independent

evidence = {'transport_encrypted': True, 'dnssec_validated': False, 'application_authenticated': False}
for name, value in evidence.items():
    print(f'{name}={value}')

Expected output

transport_encrypted=True
dnssec_validated=False
application_authenticated=False

The declared fixture has encrypted resolver transport only. Printing the booleans performs no validation and does not claim that the other trust properties follow automatically.

Build a naming evidence chain without changing the resolver

Start with the application’s exact requested name and type, then identify the cache and resolver path it used. Compare authoritative intent with the observed answer, TTL, response category, and validation state. Record whether the application reused an existing connection after the DNS change, because no new lookup may have occurred. A direct query from another network can legitimately use another view and is not an equivalent reproduction. This course never sends queries, flushes caches, or changes DNS settings. Its fixtures train the distinctions needed to select a minimal authorized operational check later.

Common errors and fixes

Encrypted DNS is called DNSSEC validation

Why it happens: Transport privacy and data-origin integrity were conflated.
How to fix it: Record the two trust properties independently.
Prevent it next time: Name the protected hop and validation chain.

An old answer proves a broken authority

Why it happens: Cache and application reuse were omitted.
How to fix it: Compare timing, TTLs, and actual lookup behavior.
Prevent it next time: Plan changes around existing cache state.

SERVFAIL becomes permanent absence

Why it happens: Temporary or validation failure was misclassified.
How to fix it: Preserve exact response and validation evidence.
Prevent it next time: Test response classes separately.

Check your understanding

1. An HTTPS-based DNS resolver answers a query. Does that establish DNSSEC integrity?

Show worked solution

No. The transport hop can be authenticated and encrypted while the answer lacks DNSSEC validation. Establish the resolver’s validation behavior and the answer’s chain separately, then still authenticate the application endpoint through its own protocol.

2. Why can a client keep using an old server after the DNS TTL expired?