DNS Maps Names to Data, Not Trust

Humans like names. Networks route using addresses.

The Domain Name System helps applications map names to records such as IP addresses. That is useful, but name resolution is not the same thing as proving the destination is trustworthy.

Follow the question

A fictional client wants:

status.robotnix.example

The supplied DNS response is:

question: status.robotnix.example A
answer:   198.51.100.20
TTL:      300

A narrow claim:

The supplied DNS response maps the queried name to IPv4 address 198.51.100.20 for the represented answer lifetime.

Do not claim:

• the host is online;
• the web service is healthy;
• the certificate is valid;
• the answer came from an uncompromised resolver; or
• the human organization behind the site is trustworthy.

DNS contributes destination data. Other layers contribute other evidence.

Resolver, authoritative data, and cache are different roles

A simplified path:

APPLICATION
   ↓
LOCAL RESOLVER / STUB
   ↓
RECURSIVE RESOLVER
   ↓
DNS HIERARCHY / AUTHORITATIVE DATA
   ↓
ANSWER
   ↓
CACHE

Real DNS behavior is more detailed, but this model is enough to diagnose common classes of failure.

A cached answer can remain available until its lifetime expires.

That means a configuration change at an authoritative source may not appear everywhere instantly.

A record types answer different questions

Common examples include:

• A — IPv4 address;
• AAAA — IPv6 address;
• CNAME — alias relationship;
• MX — mail exchange information;
• TXT — arbitrary text used by many systems;
• NS — name-server delegation information.

Do not treat every record as “the IP.”

Supplied failure: stale destination

Baseline answer:

status.robotnix.example → 198.51.100.20

Service moved in the fictional model to:

203.0.113.20

Changed client evidence:

DNS cache answer → 198.51.100.20
route to old address → works
TCP old address:443 → timeout

Another client after cache expiry receives:

status.robotnix.example → 203.0.113.20
TCP new address:443 → handshake success

A defensible hypothesis is that the first client was using a stale cached DNS answer.

Do not say “DNS was hacked.” Nothing in the supplied evidence supports that.

DNS failure and network failure can look similar to users

Compare:

name lookup fails before an IP is obtained

with:

name lookup returns an IP, but transport to that IP fails

Both may produce “site cannot be reached” in a browser. They occur at different layers.

The first diagnostic question is:

Did the client obtain the expected destination data?

Optional local observation

If your environment permits local name-resolution observation, use a teacher-approved name or a supplied transcript. Do not probe arbitrary domains for this activity.

Commands differ by operating system. On Linux, getent hosts can query configured name-service resolution, but the classroom goal is interpretation, not internet enumeration.

Activity: build a DNS evidence table

For each supplied case, record:

Notice that DNS can succeed while the application still fails.

Start your Web Path Evidence Stack

Record:

Requested name:
Record type:
Returned value:
TTL/cache context:
Expected value in the fictional design:
What DNS proves:
What it does not prove:
Next layer to test:

Lesson 2 adds HTTP behavior after the path is established.