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.

---

Frequently Asked Questions

Q: Can a network function without DHCP?

A: Yes. Every host can be manually configured with a static IP address, subnet mask, default gateway, and DNS server addresses. This approach is standard practice for servers, network appliances, printers, and any host that needs a predictable persistent address. DHCP is primarily a convenience protocol for dynamic user-facing endpoints where manual address management would be operationally expensive at scale.

Q: Can a network function without DNS?

A: Technically yes if all communication is done by raw IP address. In practice, virtually no modern application works this way. HTTP virtual hosting, email delivery, TLS certificate validation, Kerberos authentication, and SRV-based service discovery all depend on DNS. A network without functional DNS is effectively broken for end users even if IP connectivity is perfect.

Q: Does DHCP assign DNS server addresses, or does DNS assign IP addresses?

A: DHCP assigns IP addresses to clients and, as part of that process, distributes the IP addresses of DNS servers as DHCP option 6. DNS does not assign anything — it only answers queries about what name maps to what address. The relationship is one-directional: DHCP tells clients where the DNS servers are; DNS has no awareness of DHCP at all unless DDNS integration is configured.

Q: What is a DHCP reservation and how does it relate to a static DNS record?

A: A DHCP reservation binds a specific MAC address to a fixed IP address in the DHCP server's lease database. The host still performs the full DORA exchange — it simply always receives the same IP. A static DNS A record is a manually authored resource record in a zone file. A reservation without a matching DNS record gives the host a stable address but no resolvable hostname. Pairing a reservation with a static A record (or configuring DDNS to create it automatically) gives the host both a stable address and a persistent name.

Q: What happens when a DHCP lease expires?

A: The client attempts renewal at the 50% mark of the lease duration (T1) by unicasting a DHCPREQUEST to the original server. If that fails, it attempts rebinding at 87.5% of lease duration (T2) by broadcasting. If the lease fully expires without a successful renewal, the client must release the address and restart the DORA process. If DDNS is enabled, expired leases trigger automatic DNS record removal, which can cause brief name resolution gaps until the client obtains a new lease and new DNS records are registered.

Q: What is Dynamic DNS and why does it matter operationally?

A: Dynamic DNS (DDNS) is the integration layer between DHCP and DNS where the DHCP server automatically creates or updates DNS resource records whenever it grants a lease. It matters because in environments where hosts receive different IPs over time — workstations, ephemeral VMs, IoT endpoints — static DNS records go stale rapidly. DDNS keeps the DNS namespace synchronized with actual IP assignments without requiring manual zone file edits. It requires TSIG key authentication between the DHCP server and the DNS server to prevent unauthorized zone modifications from untrusted sources.

Q: What is the difference between a DNS A record and a PTR record, and which does DHCP update?

A: An A record maps a hostname to an IPv4 address (forward lookup: name to IP). A PTR record maps an IP address back to a hostname (reverse lookup: IP to name). PTR records live in the

in-addr.arpa

namespace. For example, the PTR record for

192.168.10.40

lives in the zone

10.168.192.in-addr.arpa

and resolves

40.10.168.192.in-addr.arpa.

to

sw-infrarunbook-01.solvethenetwork.com.

. A properly configured DHCP DDNS setup updates both the forward A record and the reverse PTR record atomically when granting a lease.

Q: Why do some organizations run DHCP and DNS on the same server?

A: Co-locating both roles — common with

dnsmasq

in smaller environments or Windows Server with both roles installed — simplifies DDNS integration, reduces the number of managed servers, and keeps address assignment and name registration tightly coupled. The tradeoff is a single point of failure: if that server goes down, both address assignment and name resolution fail simultaneously. Enterprise environments typically run dedicated, redundant DHCP failover pairs (RFC 2131 failover protocol) and at least two authoritative DNS servers in geographically or topologically separate locations.

Q: How does DHCP option 15 relate to DNS?

A: DHCP option 15 is the domain name option. It tells the receiving client what DNS search suffix to append when resolving unqualified hostnames. If option 15 is set to

solvethenetwork.com

, a user running

ssh sw-infrarunbook-01

will have the OS automatically attempt to resolve

sw-infrarunbook-01.solvethenetwork.com

before returning NXDOMAIN. Option 119 (domain search list) extends this to multiple ordered suffixes, which is useful in environments with subdomains across multiple business units.

Q: Is DHCP secure by default?

A: No. Base DHCP as defined in RFC 2131 has no built-in client or server authentication, making it vulnerable to rogue DHCP server attacks where an attacker distributes malicious gateway or DNS server addresses. Standard mitigations include DHCP snooping on layer-2 switches (which restricts DHCP offer traffic to trusted uplink ports), 802.1X port authentication before address assignment, and private VLAN configurations for untrusted segments. DDNS updates are secured separately through TSIG shared keys, which authenticate the DHCP server to the DNS server so that only authorized sources can create or modify zone records.

Q: Can a host have a static IP and still be registered in DNS automatically?

A: Yes. The

update-static-leases on

directive in ISC DHCP tells the server to send DDNS updates even for hosts with static reservations. Alternatively, a host can self-register using the DNS UPDATE protocol (RFC 2136) directly, bypassing DHCP entirely — this is common with Windows clients joined to Active Directory, where the host registers its own A record and the DHCP server registers the PTR record. Both approaches result in accurate forward and reverse DNS without manual zone file editing.

Q: What diagnostic tools distinguish DNS problems from DHCP problems?

A: For DNS, use

dig

— it queries DNS directly and shows the full response including answer section, TTL, record type, and which server responded. Run

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

to bypass the OS resolver and query the internal server directly. For DHCP, use

dhclient -v

in verbose mode to observe the full DORA exchange, or review

journalctl -u NetworkManager

and

/var/lib/dhcpd/dhcpd.leases

for lease state. At the packet level,

tcpdump -i eth0 port 67 or port 68

captures the raw DHCP exchange for deep protocol debugging.