Articles

DNS records and resolution: which record answers a query, and where it comes from

How the common DNS record types answer different questions, how a resolver walks the delegations to the authoritative server that owns a name, and how a Cisco IOS-XE device resolves and serves names.

Reading: 5 minNetworking

Article cover: DNS records and resolution: which record answers a query, and where it comes from

A DNS query asks for one name and one type; the answer is the record set the zone authoritative for that name publishes. A resolver serves it from cache until the TTL expires, or walks the NS delegations down to that zone — publishing records, and knowing which server may answer, are the two halves of running DNS.

The model: a name is not one record

Read every question through one rule: a client asks for a name plus a type, never for “the name” as one object, and a name can carry several types, each answered as its own record. A zone is served authoritatively from its cut downward, except where a child is delegated (RFC 1034).

client stub resolver
   |  query: name + type
   v
recursive resolver            cache hit, TTL still valid?  --> answer
   |  miss
   v
follow the NS delegations:   root  ->  TLD  ->  zone
   |  (each of these answers is a referral, not the answer)
   v
authoritative server  -->  the RRset for name + type
   |  cached for its TTL
   v
answer returned to the client

What a client sees is a copy: the zone changed at once, and only caching makes it look gradual.

Terms

  • Resource record (RR) — an owner name, a type, a class, a TTL and the RDATA.
  • RRset — records sharing one owner name, class and type; their TTLs must match (RFC 2181; RFC 8499).
  • Zone — part of the name space served authoritatively from its cut downward.
  • Stub / recursive resolver — the client function that only asks, and the resolver that walks delegations and caches (RFC 8499).
  • Authoritative server — a server that knows a zone from local data and sets the AA bit (RFC 8499).
  • Delegation — an NS RRset in the parent naming the child’s servers (RFC 8499).
  • TTL — the maximum time a record may be cached, 0 to 2^31 − 1 (RFC 2181 §8).

Which record answers which question

The type is the second half of every query: it is what makes two records at one name different answers.

Type Code The value it carries
A 1 the IPv4 address of a name (RFC 1035)
AAAA 28 the IPv6 address of a name (RFC 3596)
CNAME 5 the canonical name for an alias (RFC 1035)
MX 15 the mail exchanger for a domain (RFC 1035)
NS 2 an authoritative name server; also the delegation and the referral (RFC 1035)
SOA 6 the start of a zone of authority and the zone’s parameters (RFC 1035)
PTR 12 a domain-name pointer, used for reverse lookups (RFC 1035)
TXT 16 text strings (RFC 1035)
SRV 33 service location: priority, weight, port, target (RFC 2782)

Codes: IANA DNS Parameters registry. The SOA is the zone’s identity: its serial changes on each edit, and its MINIMUM field bounds negative caching (RFC 2308). A CNAME is an alias and nothing else, so a name holding one may hold no other data: it cannot sit beside an A record, nor be the zone apex, where SOA and NS are mandatory (RFC 2181 §10.1).

How a resolver finds the answer

  1. The application asks its stub resolver for a name and a type; the stub sends the query to the resolver configured on the host ( the L1 sheet).
  2. The resolver checks its cache; a miss sends it downward from the servers it knows, at worst the root.
  3. A server not authoritative for the name replies with a referral (NS records closer to the answer); iterative mode is mandatory, recursion optional (RFC 1034 §2.2).
  4. At the zone owning the name the authoritative server answers: the RRset for the requested type, or “no such name” with the SOA attached.
  5. The resolver caches the answer for its TTL, and caches a nonexistent name for the minimum of the SOA MINIMUM field and the SOA’s TTL (RFC 2308).
  6. Two resolvers can return different answers for one name: they differ only in cache state.

On a Cisco IOS-XE device

Cisco IOS-XE is the reference platform; the concepts are portable, the commands are not. As a client, the device needs a resolver — ip name-server, ip domain lookup, ip domain name. As a local server it can publish its own records: ip dns server and ip dns primary … soa make it authoritative, ip host adds name-to-address entries and ip host <domain> ns <server> the NS records.

ip domain lookup
ip domain name example.com
ip name-server 192.0.2.53
ip host ntp1.example.com 192.0.2.11
! the device as a small authoritative/caching server for its own host table
ip dns server
ip dns primary example.com soa ns1.example.com hostmaster.example.com
ip host example.com ns ns1.example.com

show hosts shows the default domain, the lookup style, the name servers and the cached entries; ping <name> tests resolution. Locally defined records carry a ten-second TTL whatever the SOA parameters say, and the IOS DNS server does not perform zone transfers. Warning: ip dns server and ip dns primary change the device’s role, and clients pointed at it then depend on it; no ip domain lookup disables the device’s own name resolution.

Limits and a common misconception

A TTL is a maximum, not a promise: a resolver may cache for less, and may clamp a too-large value (RFC 2181 §8). Shortening a TTL helps only if the shorter value is already in the caches, and a new name stays “not found” until its negative answer expires (RFC 2308).

The common error is to treat a name as one object: “the record” does not exist — there are records, one per type, answered independently, and a CNAME never coexists with another type (RFC 2181 §10.1). The other error is “propagation”: nothing propagates — the zone changed at once, and only stale caches make it look gradual.

Security note: DNS answers are not authenticated by default; DNSSEC adds origin authentication and integrity for signed zones (RFC 4033). DNS security and traffic control belong to a later sheet.

Level and prerequisites. L2 — operational: read a zone’s records and configure a device’s resolver, not run a zone at scale. Prerequisites: the L1 sheet DNS and DHCP and a working idea of IP addressing; Cisco IOS-XE is the reference platform.

Where to go next

References

  • RFC 1034 — Domain Names: Concepts and Facilities (Nov 1987).
  • RFC 1035 — Domain Names: Implementation and Specification (Nov 1987).
  • RFC 2181 — Clarifications to the DNS Specification (Jul 1997).
  • RFC 2308 — Negative Caching of DNS Queries (DNS NCACHE) (Mar 1998).
  • RFC 2782 — A DNS RR for specifying the location of services (DNS SRV) (Feb 2000).
  • RFC 3596 — DNS Extensions to Support IP Version 6 (Oct 2003).
  • RFC 4033 — DNS Security Introduction and Requirements (Mar 2005).
  • RFC 8499 — DNS Terminology (BCP 219) (Jan 2019).
  • IANA — Domain Name System (DNS) Parameters: Resource Record (RR) TYPEs registry.
  • Cisco — IP Addressing: DNS Configuration Guide, Cisco IOS Release 15M&T.
  • Cisco — Cisco IOS IP Addressing Services Command Reference.