DNS vs DHCP: What's the Difference Explained Simply

DNS and DHCP are two of the most foundational protocols underpinning every modern IP network. Ask a junior admin to explain the difference and you will often get a blank stare or a half-correct answer that conflates the two. That confusion is understandable — both protocols operate silently in the background, and both are required before a host can do anything useful on the network. But they solve fundamentally different problems, operate at different phases of network bootstrapping, and fail in completely different ways when something goes wrong.

This article breaks down both protocols from first principles, walks through how each one works step by step, shows real configuration examples using realistic infrastructure, and explains how DNS and DHCP are designed to complement each other — including the integration point known as Dynamic DNS (DDNS) that causes the most operational confusion of all.

What Is DNS?

DNS stands for Domain Name System. It is a distributed, hierarchical database whose primary job is name resolution — translating a human-readable hostname like

mail.solvethenetwork.com

into a machine-usable IP address like

192.168.10.25

, and vice versa.

Without DNS, every application would need to know the raw IP address of every server it wants to reach. That worked in the 1970s when ARPANET had a few hundred hosts and a single

HOSTS.TXT

file was distributed centrally. It does not work today. DNS replaced that flat file with a globally distributed namespace that can be delegated, cached, secured with DNSSEC, and served redundantly from multiple authoritative servers around the world.

DNS operates on UDP port 53 for standard queries, falling back to TCP for responses larger than 512 bytes, zone transfers, and DNS over TLS. It uses a client-server model where a resolver — typically your operating system's stub resolver — contacts a recursive resolver (often an internal DNS server), which in turn walks the DNS tree from the root down to find the authoritative answer.

How DNS Resolution Works

A full recursive resolution for

sw-infrarunbook-01.solvethenetwork.com

follows this sequence:

1. The application calls

   getaddrinfo("sw-infrarunbook-01.solvethenetwork.com")

   .
2. The OS stub resolver checks its local cache. Cache miss — it forwards the query to the configured recursive resolver at

   192.168.10.10

   .
3. The recursive resolver checks its own cache. Cache miss — it queries a root nameserver for the

   com.

   TLD delegation.
4. A root server responds with the NS records for

   com.

   .
5. The recursive resolver queries a

   com.

   TLD nameserver for the

   solvethenetwork.com.

   delegation.
6. The TLD nameserver responds with the NS records for

   solvethenetwork.com.

   .
7. The recursive resolver queries the authoritative nameserver for

   solvethenetwork.com.

   for the A record of

   sw-infrarunbook-01.solvethenetwork.com.

   .
8. The authoritative server returns:

   192.168.10.40

   with a TTL of 3600 seconds.
9. The recursive resolver caches this result and returns it to the stub resolver.
10. The application receives

    192.168.10.40

    and opens its connection.

The entire round trip typically completes in under 100 milliseconds for a cold cache lookup against a geographically local authoritative server. Subsequent lookups for the same record within the TTL window are served from cache in microseconds.

DNS Zone File: A Real Example

Below is a simplified forward zone file for

solvethenetwork.com

as it would appear in a BIND configuration managed by

infrarunbook-admin

:

; Zone file for solvethenetwork.com
; Managed by infrarunbook-admin

$TTL 3600
@   IN  SOA  ns1.solvethenetwork.com. infrarunbook-admin.solvethenetwork.com. (
            2026033001  ; serial
            3600        ; refresh
            900         ; retry
            604800      ; expire
            300 )       ; negative cache TTL

; Name servers
@           IN  NS   ns1.solvethenetwork.com.
@           IN  NS   ns2.solvethenetwork.com.

; A records for name servers
ns1         IN  A    192.168.10.10
ns2         IN  A    192.168.10.11

; Infrastructure hosts
sw-infrarunbook-01  IN  A    192.168.10.40
mail                IN  A    192.168.10.25
vpn                 IN  A    192.168.10.30
ntp                 IN  A    192.168.10.12

; CNAME alias
webmail     IN  CNAME  mail.solvethenetwork.com.

; MX record
@           IN  MX  10  mail.solvethenetwork.com.

; TXT record (SPF)
@           IN  TXT  "v=spf1 mx ip4:192.168.10.25 -all"

Notice that DNS is entirely concerned with name-to-address mappings and mail routing metadata. There is nothing in a zone file about lease durations, gateway addresses, or subnet masks. DNS does not know or care how a host obtained its IP address — only what name maps to what address at this moment in time.

What Is DHCP?

DHCP stands for Dynamic Host Configuration Protocol. It is a client-server protocol defined in RFC 2131 whose job is IP address assignment and network parameter distribution. When a device joins a network with no pre-configured IP address, DHCP is what gives it one — along with the subnet mask, default gateway, DNS server addresses, domain search suffix, NTP server addresses, and any number of vendor-specific options.

Without DHCP, every device on every network would need to be manually configured with a static IP, subnet mask, gateway, and DNS server addresses. That is manageable for a server rack of ten machines. It is completely untenable for a campus network with ten thousand endpoints, a warehouse with hundreds of IoT sensors, or a guest WiFi segment that cycles through hundreds of devices per day.

DHCP operates on UDP port 67 (server) and UDP port 68 (client). Because the client has no IP address at the time it needs DHCP, the protocol relies on limited broadcast (

255.255.255.255

) for the initial discovery phase. This means DHCP traffic does not naturally cross router boundaries — a problem solved with DHCP relay agents.

How DHCP Works: The DORA Process

DHCP bootstraps an IP address in four steps, universally referred to as DORA:

1. Discover — The client broadcasts a DHCPDISCOVER on the local segment. Source IP:

   0.0.0.0

   . Destination:

   255.255.255.255

   . The message carries the client's MAC address and optionally a requested IP or hostname.
2. Offer — One or more DHCP servers respond with a DHCPOFFER containing a proposed IP address, subnet mask, lease duration, default gateway, and DNS server list.
3. Request — The client broadcasts a DHCPREQUEST selecting one offer. This broadcast also informs non-selected servers to withdraw their offers.
4. Acknowledge — The selected server sends a DHCPACK confirming the lease. The client configures its interface. It is now on the network.

DHCP Scope Configuration: A Real Example

Below is a representative ISC DHCP server configuration serving multiple VLANs, managed by

infrarunbook-admin

:

# /etc/dhcp/dhcpd.conf
# Managed by infrarunbook-admin

authoritative;

default-lease-time 86400;     # 24 hours
max-lease-time 172800;        # 48 hours

option domain-name "solvethenetwork.com";
option domain-name-servers 192.168.10.10, 192.168.10.11;

# VLAN 10 - Internal LAN
subnet 192.168.10.0 netmask 255.255.255.0 {
    range 192.168.10.100 192.168.10.200;
    option routers 192.168.10.1;
    option broadcast-address 192.168.10.255;
    option ntp-servers 192.168.10.12;
}

# VLAN 20 - Server DMZ
subnet 192.168.20.0 netmask 255.255.255.0 {
    range 192.168.20.50 192.168.20.100;
    option routers 192.168.20.1;
    option broadcast-address 192.168.20.255;
}

# VLAN 100 - Out-of-band management
subnet 10.10.100.0 netmask 255.255.255.0 {
    range 10.10.100.50 10.10.100.200;
    option routers 10.10.100.1;
    option broadcast-address 10.10.100.255;
}

# Static reservation for sw-infrarunbook-01
host sw-infrarunbook-01 {
    hardware ethernet 00:1a:2b:3c:4d:5e;
    fixed-address 192.168.10.40;
    option host-name "sw-infrarunbook-01";
}

DHCP is entirely concerned with address assignment and network parameters. The server distributes the IP addresses of the DNS servers as DHCP option 6, but it performs no name resolution itself. DHCP knows nothing about zone files, TTLs, NS records, or recursive queries.

Key Differences Between DNS and DHCP

The distinctions between the two protocols span purpose, transport, state, scope, and failure behavior:

• Purpose: DNS resolves names to addresses. DHCP assigns addresses to hosts.
• RFC: DNS is defined in RFC 1034 and RFC 1035. DHCP is defined in RFC 2131.
• Transport: DNS uses UDP/TCP port 53. DHCP uses UDP ports 67 and 68.
• State: DNS is mostly stateless — the authoritative server does not track who queried it. DHCP is fully stateful and maintains a persistent lease database.
• Persistence: DNS records persist until manually changed or the TTL expires. DHCP leases have explicit expiry times and must be actively renewed.
• Scope: DNS is globally routable — a record in

  solvethenetwork.com

  is resolvable from anywhere on the internet. DHCP is link-local by default and requires relay agents to cross subnet boundaries.
• Failure mode: DNS failure causes name resolution to stop, breaking virtually all application traffic. DHCP failure prevents new address acquisition, but hosts with valid unexpired leases continue working.
• Data stored: DNS stores resource records (A, AAAA, MX, CNAME, TXT, SRV, NS, SOA, PTR). DHCP stores lease bindings — MAC-to-IP mappings with lease timestamps and distributed options.

How DNS and DHCP Work Together: Dynamic DNS

DNS and DHCP are designed to be complementary. DHCP hands out the address; DNS makes that address reachable by name. In a statically managed environment, a sysadmin manually adds an A record to the DNS zone file after assigning an IP — a perfectly valid workflow for servers and network infrastructure with predictable addresses.

For dynamic endpoint environments — user workstations, laptops, ephemeral VMs — manual DNS registration is impractical. This is where Dynamic DNS (DDNS) comes in. When the DHCP server grants a lease, it automatically registers or updates DNS records for that host using the DNS UPDATE protocol defined in RFC 2136. The DHCP server sends a TSIG-authenticated update to the DNS server, creating or refreshing the A record and the PTR record in the appropriate reverse zone.

Here is what a DDNS-enabled ISC DHCP configuration looks like:

# /etc/dhcp/dhcpd.conf (DDNS section)
# Managed by infrarunbook-admin

key "dhcp-ddns-key" {
    algorithm hmac-sha256;
    secret "dGhpcyBpcyBhIHNhbXBsZSBiYXNlNjQ=";
};

zone solvethenetwork.com. {
    primary 192.168.10.10;
    key dhcp-ddns-key;
}

zone 10.168.192.in-addr.arpa. {
    primary 192.168.10.10;
    key dhcp-ddns-key;
}

ddns-update-style interim;
ddns-domainname "solvethenetwork.com.";
ddns-rev-domainname "in-addr.arpa.";
update-static-leases on;
do-forward-updates on;

On the BIND side, the zone must permit updates from the DHCP server using the same TSIG key:

# /etc/named.conf (update permissions)
# Managed by infrarunbook-admin

key "dhcp-ddns-key" {
    algorithm hmac-sha256;
    secret "dGhpcyBpcyBhIHNhbXBsZSBiYXNlNjQ=";
};

zone "solvethenetwork.com" IN {
    type master;
    file "/var/named/solvethenetwork.com.zone";
    allow-update { key dhcp-ddns-key; };
};

zone "10.168.192.in-addr.arpa" IN {
    type master;
    file "/var/named/192.168.10.rev";
    allow-update { key dhcp-ddns-key; };
};

With this in place, when a client on VLAN 10 receives a DHCP lease, the DHCP server pushes an A record for that hostname into

solvethenetwork.com

and a PTR record into

10.168.192.in-addr.arpa

. The host becomes resolvable by name within seconds, without manual intervention.

Split-Horizon DNS and DHCP: Enterprise Considerations

In enterprise environments, DHCP and DNS are rarely simple flat deployments. A common pattern is split-horizon DNS, where internal clients on

192.168.10.0/24

or

10.10.0.0/16

receive different DNS answers than external resolvers. The DHCP server is configured to distribute the IP of an internal authoritative DNS server, ensuring that internal clients resolve

sw-infrarunbook-01.solvethenetwork.com

to a private RFC 1918 address, while external resolvers see a public-facing IP if one exists.

# /etc/named.conf - Split-horizon views
# Managed by infrarunbook-admin

acl "internal-nets" {
    192.168.10.0/24;
    192.168.20.0/24;
    10.10.100.0/24;
    127.0.0.1;
};

view "internal" {
    match-clients { internal-nets; };
    recursion yes;

    zone "solvethenetwork.com" IN {
        type master;
        file "/var/named/internal/solvethenetwork.com.zone";
        allow-update { key dhcp-ddns-key; };
    };
};

view "external" {
    match-clients { any; };
    recursion no;

    zone "solvethenetwork.com" IN {
        type master;
        file "/var/named/external/solvethenetwork.com.zone";
    };
};

DHCP ensures all clients on internal subnets point to

192.168.10.10

as their resolver, which serves the

internal

view. An external resolver hitting the same server from outside the ACL is matched to the

external

view — a completely separate zone file with no RFC 1918 addresses exposed.

Troubleshooting DNS and DHCP: Common Failure Modes

Understanding the distinction between DNS and DHCP is essential for effective troubleshooting. The symptom I cannot reach the server branches into very different diagnostic trees depending on root cause:

• Cannot ping by IP, can ping by name: Routing or firewall issue. Neither DNS nor DHCP is at fault.
• Cannot ping by name, can ping by IP: DNS failure. Check the configured resolver, zone files, and authoritative server reachability.
• Cannot get an IP address at all: DHCP failure. Check DHCP server status, scope exhaustion, relay agent configuration, and UDP 67/68 firewall rules.
• Gets IP but wrong DNS server address: DHCP option 6 misconfiguration on the scope.
• DNS resolves stale IP after host moved: TTL has not expired or DDNS update did not fire. Check TSIG key configuration and

  named

  logs for UPDATE rejections.
• Reverse DNS broken after DDNS update: The reverse zone (

  10.168.192.in-addr.arpa

  ) may be missing from the DHCP server's zone stanza, or the

  allow-update

  ACL may not cover the PTR zone.

Diagnostic discipline: Always start by running

ip addr

to verify the assigned address and DNS server, then

dig @192.168.10.10 sw-infrarunbook-01.solvethenetwork.com

to test resolution directly against the server. These two commands isolate whether you are dealing with an address acquisition problem (DHCP) or a name resolution problem (DNS) in under thirty seconds.

---

Related Articles

• [DNS] What is DNS and How Resolution Works
• [DNS] What Happens When DNS Fails (Real Impact Explained)
• [DNS] What Is Reverse DNS Lookup and Where It Is Used
• [DNS] DNS Recursion – What It Is, Why It’s Dangerous, How to Check & Disable It