What is the difference between DNS and DHCP?

Sajjad
DNS
10 Oct, 2026

DNS and DHCP are two separate network services that work closely together. DHCP (Dynamic Host Configuration Protocol) automatically gives a device its network settings when it joins a network: an IP address, a subnet mask, a default gateway, and the addresses of the DNS servers it should use. DNS (Domain Name System) then translates human-readable names such as www.example.com into IP addresses, so the device can actually reach things. Put simply, DHCP tells your device who it is and who to ask, and DNS answers the question where is that name?

Because both services are involved the moment a laptop joins Wi-Fi, they're easy to mix up, and problems with one often look like problems with the other. This article explains what each service does, how DHCP hands out DNS settings, how the two can be integrated so that devices get DNS names automatically, a side-by-side comparison, example configurations, and how to tell which one is at fault when something goes wrong.

What DHCP Does

Every device on an IP network needs a few settings before it can communicate. You could configure them by hand on each machine, but on any network with more than a handful of devices that quickly becomes impractical and error-prone. DHCP automates it.

When a device connects, a DHCP server leases it:

An IP address, such as 192.0.2.120, taken from a configured pool.
A subnet mask, such as 255.255.255.0, which defines the local network.
A default gateway, the router used to reach other networks.
DNS server addresses, telling the device which resolvers to use.
A domain name and search list, such as lan.example.com, used to complete short hostnames.
A lease time, after which the device must renew or give the address back.

The DORA Process

An IPv4 DHCP exchange has four steps, often remembered as DORA:

Discover: The new device broadcasts a message asking if any DHCP servers are available. It has no IP address yet, so it uses broadcast from UDP port 68 to port 67.
Offer: A DHCP server replies with an available IP address and settings.
Request: The device formally asks for the offered address. This also tells any other DHCP servers that their offers weren't chosen.
Acknowledge: The server confirms the lease, and the device configures its network interface.

Before the lease expires, usually at the halfway point, the device contacts the server again to renew it, often getting the same address back.

DHCP for IPv6

IPv6 networks can use DHCPv6, which runs on UDP ports 546 and 547, or SLAAC (stateless address autoconfiguration), where devices build their own addresses from router advertisements. Either can supply DNS settings: DHCPv6 has its own option for DNS servers, and router advertisements can carry DNS server addresses using the RDNSS option defined in RFC 8106. Many networks combine SLAAC for addresses with one of these for DNS.

What DNS Does

DNS is the internet's directory. When an application wants to connect to www.example.com, it asks a DNS resolver for the address. The resolver either answers from its cache or looks the name up by walking down the DNS hierarchy to the domain's authoritative nameservers, which hold the actual records.

dig www.example.com A +short

192.0.2.10

DNS doesn't assign anything. It only answers questions about names that someone has already configured. It typically runs on port 53 over UDP and TCP, and increasingly over encrypted transports such as DNS over HTTPS (port 443) and DNS over TLS (port 853).

How DHCP and DNS Work Together

The two services meet at one key point: DHCP is usually how a device learns which DNS servers to use. The DNS server addresses are sent as a DHCP option, option 6 for IPv4, alongside the IP address and gateway.

You can see what your device was given. On macOS, ipconfig getpacket shows the last DHCP reply for an interface:

ipconfig getpacket en0

op = BOOTREPLY
htype = 1
yiaddr = 192.0.2.120
siaddr = 192.0.2.1
Options count is 8
dhcp_message_type (uint8): ACK 0x5
server_identifier (ip): 192.0.2.1
lease_time (uint32): 0x15180
subnet_mask (ip): 255.255.255.0
router (ip_mult): {192.0.2.1}
domain_name_server (ip_mult): {192.0.2.53}
domain_name (string): lan.example.com
end (none):

On Windows, ipconfig /all lists the DHCP server, the lease times and the DNS servers it received:

ipconfig /all

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : lan.example.com
   DHCP Enabled. . . . . . . . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.0.2.120(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Monday, 12 October 2026 09:02:11
   Lease Expires . . . . . . . . . . : Tuesday, 13 October 2026 09:02:11
   Default Gateway . . . . . . . . . : 192.0.2.1
   DHCP Server . . . . . . . . . . . : 192.0.2.1
   DNS Servers . . . . . . . . . . . : 192.0.2.53

On Linux systems using systemd-resolved, resolvectl status shows the DNS servers per interface, including those learned from DHCP:

resolvectl status eth0

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.0.2.53
       DNS Servers: 192.0.2.53
        DNS Domain: lan.example.com

This is why changing the DNS servers in your router's DHCP settings changes them for every device on the network the next time they renew their leases.

Dynamic DNS Updates From DHCP

On business networks there's a second link between the services. When the DHCP server hands out an address, it can also register the device's name in DNS, creating an A record (and often a reverse PTR record) so that other machines can reach laptop-42.lan.example.com by name. The standard mechanism for this is the DNS UPDATE message defined in RFC 2136.

Active Directory networks do this as a matter of course: Windows DHCP Server and Windows clients register their names in AD-integrated DNS zones. On Linux, ISC Kea's DHCP-DDNS component (kea-dhcp-ddns) can send updates to a DNS server such as BIND.

Smaller networks often use dnsmasq, which combines a DHCP server and a caching DNS forwarder in one process, so devices are resolvable by name automatically without any update protocol at all.

DNS vs DHCP at a Glance

Feature	DHCP	DNS
Main purpose	Assign IP addresses and network settings	Translate names to IP addresses and other data
Question it answers	"What settings should I use on this network?"	"What is the address for this name?"
Scope	Usually a single local network or subnet	Global, plus private internal zones
Transport and ports	UDP 67/68 (IPv4), UDP 546/547 (DHCPv6)	UDP and TCP 53, plus 443 for DoH and 853 for DoT
When it's used	When a device joins a network and when it renews its lease	Every time an application looks up a name
Data it holds	Address pools, leases, reservations, options	Zones and records such as A, AAAA, MX and TXT
Typical servers	Routers, Windows DHCP Server, ISC Kea, dnsmasq	BIND, Unbound, PowerDNS, Windows DNS, cloud DNS providers
Relationship to the other	Tells devices which DNS servers to use	Can be updated with names of DHCP clients

Example: dnsmasq for a Small Network

This dnsmasq.conf runs DHCP and DNS together for a small office or home lab. Devices get addresses from a pool, are told to use the dnsmasq machine as their DNS server, and can find one another by name:

# Listen on the LAN interface only
interface=eth0
bind-interfaces

# DHCP pool: addresses .100 to .200 with a 12-hour lease
dhcp-range=192.0.2.100,192.0.2.200,12h

# Settings sent to clients
dhcp-option=option:router,192.0.2.1
dhcp-option=option:dns-server,192.0.2.53

# Local domain: client hostnames become name.lan.example.com
domain=lan.example.com
local=/lan.example.com/
expand-hosts

# Always give the printer the same address
dhcp-host=aa:bb:cc:dd:ee:ff,printer,192.0.2.50

# Forward everything else to public resolvers
no-resolv
server=1.1.1.1
server=9.9.9.9

After a laptop called laptop-42 gets a lease, any other device on the network can resolve it:

dig @192.0.2.53 laptop-42.lan.example.com +short

192.0.2.137

Example: ISC Kea Handing Out DNS Settings

ISC's older isc-dhcp-server reached end of life in 2022, and Kea is its replacement. Kea uses JSON configuration. This minimal kea-dhcp4.conf serves one subnet and tells clients which DNS servers and search domain to use:

{
  "Dhcp4": {
    "interfaces-config": {
      "interfaces": ["eth0"]
    },
    "lease-database": {
      "type": "memfile",
      "persist": true,
      "name": "/var/lib/kea/kea-leases4.csv"
    },
    "valid-lifetime": 43200,
    "subnet4": [
      {
        "id": 1,
        "subnet": "192.0.2.0/24",
        "pools": [
          { "pool": "192.0.2.100 - 192.0.2.200" }
        ],
        "option-data": [
          { "name": "routers", "data": "192.0.2.1" },
          { "name": "domain-name-servers", "data": "192.0.2.53, 192.0.2.54" },
          { "name": "domain-name", "data": "lan.example.com" },
          { "name": "domain-search", "data": "lan.example.com" }
        ]
      }
    ]
  }
}

Here the DHCP server's only job with respect to DNS is to point clients at 192.0.2.53 and 192.0.2.54. What those servers do, whether they're an internal BIND server, a filtering resolver or a forwarder, is entirely a DNS matter.

Static Addresses, Reservations and DNS

Servers, printers and network equipment usually need addresses that don't change, so that DNS records pointing to them stay correct. There are two ways to achieve that:

Static configuration: The address is set manually on the device, outside the DHCP pool.
DHCP reservation: The DHCP server always gives the same address to a device's MAC address, as with the dhcp-host line in the dnsmasq example.

Either way, if you then create a DNS record such as printer.lan.example.com A 192.0.2.50, it keeps working. Pointing DNS records at addresses from a dynamic pool without a reservation is a common cause of "it worked yesterday" problems, because the device can get a different address when its lease renews.

Troubleshooting: Is It DHCP or DNS?

When a device "has no internet", working out which service failed saves a lot of time. Use this order:

Check for a valid address: If the device has a 169.254.x.x address on IPv4, it didn't get a DHCP lease. That's a DHCP problem, or a physical or Wi-Fi problem before DHCP.
Check the gateway: Ping the default gateway. If that fails, the problem is local network connectivity.
Check connectivity by IP: Try reaching a well-known address directly, such as ping 1.1.1.1. If this works but websites don't load, routing is fine.
Check DNS: Run a lookup against the configured DNS server, then against a public one:

dig www.example.com +short
dig @1.1.1.1 www.example.com +short

If the first fails but the second works, the DNS server handed out by DHCP is the problem. It may be down, unreachable, or misconfigured, or DHCP may be handing out the wrong address.

Renew the lease: If DHCP settings have changed recently, renew the lease so the device picks up the new DNS servers. On Windows:

ipconfig /release
ipconfig /renew

On Linux with NetworkManager:

nmcli connection down "Wired connection 1" && nmcli connection up "Wired connection 1"

Common Problems That Involve Both

Rogue DHCP servers: A second DHCP server on the network, such as a misconfigured home router plugged into an office network, can hand out the wrong DNS servers. Some devices then fail to resolve names while others work fine.
Stale dynamic DNS records: A device gets a new address but its old DNS record isn't updated or removed, so other machines connect to the wrong host. Scavenging or aging settings on the DNS server help clean these up.
DNS servers that point to themselves through DHCP: If a DNS server gets its own settings from DHCP and is told to use itself or a server that's down, it can fail in confusing ways. Servers should normally have static network configuration.
VPN clients overriding DNS: A VPN can replace the DNS servers that DHCP provided, which changes which names resolve while the VPN is connected.

FAQ: DNS vs DHCP

Yes. DNS works perfectly well on devices with manually configured network settings. DHCP is just the most common way devices learn which DNS servers to use.

Yes. DHCP can assign addresses without any DNS server being involved, and devices can still communicate by IP address. In practice, though, almost every network also hands out DNS servers because people need names to reach websites.

Many home routers run a small caching DNS forwarder and give their own address as the DNS server via DHCP. The router then forwards queries to your ISP's resolvers or to whichever upstream servers you configure.

It's convenient on small networks, and it lets the DNS server know every client's name and address automatically. Tools such as dnsmasq and Windows Server combine both roles for that reason.

Change the DNS server addresses in your DHCP server or router settings. Devices pick up the new values when they renew their leases, which you can force by reconnecting or renewing manually.

It's when the DHCP server or client automatically creates and updates DNS records for each device as it receives an address, so devices can be found by name even though their addresses change.

Conclusion

DHCP and DNS solve different problems. DHCP hands each device its address, gateway and DNS server settings when it joins a network, and DNS translates names into addresses every time an application needs to connect somewhere. They meet at a single important point: DHCP is usually how a device learns which DNS servers to trust.

Keeping that division clear makes troubleshooting much faster. No address or a 169.254 address points to DHCP, while a working IP connection with failing lookups points to DNS or to the DNS servers DHCP handed out. Use reservations or static addresses for anything you name in DNS, keep an eye on dynamic records in larger networks, and the two services will quietly do their jobs together.