DNS and DHCP: names, addresses and automatic configuration

Two problems keep a host usable: others must find it by name, and it must be given an address that works. DNS answers the first, DHCP the second — separate services, usually deployed together and often confused.

The model: two different problems

Read both services through one frame. A host needs a name that others can resolve, and a configuration it did not get typed in by hand. DNS provides the first as a distributed database of names; DHCP provides the second by handing out an address and its parameters.

one host, two independent needs
  find me by name         -> DNS   (a distributed database of names)
  give me a valid config  -> DHCP  (an address and its parameters)
neither replaces the other

The two are independent: a host with a static address needs no DHCP and still needs DNS, and a host that never resolves names still needs an address. Everything below applies the frame twice — what DNS resolves, then what DHCP configures.

Terms. Name resolution: turning a name into data, an address or another name. Zone: the administrative unit of the DNS name space. Lease: the period for which DHCP lends an address.

DNS: resolving a name

An IP address is what the network uses to deliver a packet; a name is what a person can remember. DNS (Domain Name System) is a distributed database that maps names to records, so a client can resolve a name without a central list of every host. The name space is a tree, and its administrative unit is the zone: whoever controls a zone can change its data, add nodes, or delegate subzones to another party, and delegation records in the parent point to the child (RFC 1034).

Resolution takes two forms. A recursive server pursues the query for the client and returns an answer or an error, never a referral; a non-recursive server answers from local knowledge or refers the client closer to the answer. RFC 1034 requires every server to implement the non-recursive (iterative) form; recursion is optional, which is why a stub client normally asks a recursive resolver to do the walking.

A record carries a type and a value: A and AAAA for addresses, CNAME for an alias, MX for mail, NS for an authoritative server, PTR for reverse lookups, TXT for text (RFC 1035; RFC 3596 for AAAA). Each record also carries a TTL, “the time limit on how long an RR can be kept in a cache” (RFC 1034), set by the administrator of the zone where the data originates. DNS is served on port 53 over both UDP and TCP.

DHCP: configuring a host

DHCP (Dynamic Host Configuration Protocol) supplies a host with an IP address, a subnet mask, a default router and the addresses of other services, instead of those values being typed in by hand (RFC 2131). Allocation follows four messages:

DHCPDISCOVER (client broadcast) -> DHCPOFFER (server)
        -> DHCPREQUEST (client broadcast) -> DHCPACK (server)

The client broadcasts a DHCPDISCOVER to find servers; each may answer with an offer carrying an address; the client broadcasts a request that selects one server and declines the rest; the selected server commits the address and the remaining parameters. The mnemonic “DORA” is widespread but does not appear in the RFC. The parameters arrive as options (RFC 2132).

The address is leased, not owned. The client renews it over time — first with the server that issued it, then with any server — and the lease expires if neither succeeds (RFC 2131). A reservation pins a specific address to a client identifier; without one, dynamic allocation may return a different address once the lease ends.

A common misconception

Two beliefs cause most confusion. The first is that DNS “propagates”. There is no propagation: there are caches, and a changed record becomes visible only as cached copies expire under their TTL or are flushed, so different resolvers can legitimately return different answers for the same name. The second is that DHCP always returns the same address. That holds only while a binding or a reservation survives; a plain dynamic client can get a different address once its lease expires.

Security note

Neither service authenticates itself by default. RFC 2131 is blunt: “DHCP in its current form is quite insecure”, and an unauthorised server can hand out incorrect addresses, spoof a router, or point clients at a spoofed name server. DNSSEC (RFC 4033) adds origin authentication and integrity to DNS data through signed records, but it requires signed zones and a configured trust anchor and provides no confidentiality. Both exposures are structural: they are exploited by running a rogue server or resolver on the path or segment, not by breaking cryptography.

Level and prerequisites. L1 — fundamentals. Prerequisites: a rough idea of what an IP address is. No configuration experience is required.

Where to go next

• Networking — the area this sheet belongs to.

References

• RFC 1034 — Domain Names: Concepts and Facilities (Nov 1987).
• RFC 1035 — Domain Names: Implementation and Specification (Nov 1987).
• RFC 2131 — Dynamic Host Configuration Protocol (Mar 1997).
• RFC 2132 — DHCP Options and BOOTP Vendor Extensions (Mar 1997).
• RFC 3596 — DNS Extensions to Support IP Version 6 (Oct 2003).
• RFC 4033 — DNS Security Introduction and Requirements (Mar 2005).