DNS (the Domain Name System) and DHCP (the Dynamic Host Configuration Protocol). They solve the fundamental problem of network legibility: without them, humans would have to memorise numeric IP addresses for every website, and every new device joining a network would require manual configuration. For the LPIC-2 exam, understanding how these two services work and how to configure them is critical because they form the backbone of every modern network, from a home Wi-Fi to a corporate data centre.
Jump to a section
A simple way to picture DNS and DHCP Configuration
The Hotel Concierge. She manages the arrival and the identity of every guest in a busy city hotel. This role perfectly mirrors the combined work of DNS and DHCP on a network.
When a new guest arrives (a new device, say a laptop, connects to the network), the concierge (the DHCP server) checks her reservation list (the DHCP scope) and assigns the guest a specific room number (an IP address). She also hands them a welcome pack containing the hotel map (subnet mask), the key to the main exit (default gateway), and the phone number for room service (DNS server address). Without this initial assignment, the guest would have no room and no way to navigate the hotel. The concierge also sets a check-out time (the lease time) so she can reassign the room if the guest leaves without formally checking out.
Once the guest has a room, they want to send postcards to friends or order food from a specific restaurant they heard about. They don't know the restaurant's exact street address (IP address), only its name (domain name, like "www.pizzaplace.com"). So they call the concierge again (the DNS server). The concierge consults the hotel's guest directory (the DNS zone file), which maps famous names to their exact street addresses. "Room 312, 'Pizza Place' is at 10 Downing Street." The concierge does not just match names to rooms; she might also tell the guest the restaurant's main switchboard number (mail exchange record) or the address of its fancier sister restaurant (alias records).
Crucially, both the arrival and directory systems are separate but intertwined. The concierge gives the guest the directory's phone number when they first check in. The directory only works because guests have a room. This division of labour keeps the hotel running instead of descending into chaos where guests wander the halls looking for a room or have no way to find the places they want.
Let us start with the absolute foundation. A computer network is just a group of devices connected so they can talk to each other. Every device on a network needs a unique identifier, much like every house needs a unique street address. In the world of Internet Protocol (IP) networking, this identifier is called an IP address. An IP address is a string of numbers, separated by dots, for example 192.168.1.10. Humans are terrible at remembering strings of numbers. We are much better at remembering words, like "google.com" or "bbc.co.uk". DNS is the system that translates these human-friendly domain names into the machine-friendly IP addresses. DHCP is the system that automatically assigns those IP addresses (and other network settings) to devices when they first connect, so you do not have to type them in manually on every single phone, laptop, and printer.
Let us break down DNS first. Think of DNS as the internet's phonebook. When you type "www.example.com" into your web browser, your computer does not know where that is. It sends a query to a DNS server (which is just a specialised computer running DNS software) asking, "What is the IP address of www.example.com?" The DNS server looks up the answer in its database (called zone files) and sends back the IP address, for example 93.184.216.34. Your browser then uses that IP address to connect to the web server hosting the website. The hierarchy is important. The root DNS servers sit at the top, knowing where the servers for each top-level domain (like .com, .org, .uk) are. Then the TLD servers know where the authoritative name servers for each domain (like example.com) are. Finally, the authoritative name server for the domain itself knows the exact IP addresses for all its subdomains (like www, mail, or ftp). A caching DNS server (like the one your internet service provider runs) remembers recent answers so it does not have to ask the full chain again every time.
For the LPIC-2 exam, you need to understand how to configure the BIND (Berkeley Internet Name Domain) software, which is the most common DNS server on Linux. You will configure zone files that define the mappings for a domain, and you will set up forwarders (trusted DNS servers to query when your server does not know an answer). You must also understand the concept of recursive queries (where your server does all the work of finding the answer) versus iterative queries (where it tells the client to ask the next server in the chain). You will need to know about the tools like 'dig' (domain information groper) and 'nslookup' for testing DNS resolution.
Now, DHCP. DHCP is all about automation. When a device first connects to a network, it has no IP address. It broadcasts a discovery message (a DHCPDISCOVER) saying, "Is there a DHCP server out there? I need an address." A DHCP server on the network responds with a DHCPOFFER, offering a specific IP address and other settings (like subnet mask, default gateway, and DNS server addresses). The device then sends a DHCPREQUEST message to formally accept the offer. The server acknowledges with a DHCPACK, and the device can now use the IP address. This is all automatic, happens in milliseconds, and is called the DORA process (Discover, Offer, Request, Acknowledge). IP addresses are not assigned permanently. They are leased for a specific period (the lease time). Once the lease expires, the device must renew it or obtain a new address. This allows the DHCP server to reclaim addresses from devices that leave the network.
For LPIC-2, you need to know how to configure the DHCP server itself (commonly ISC DHCPd on Linux). You must understand the DHCP configuration file (usually /etc/dhcp/dhcpd.conf), where you define:
The range of IP addresses available for assignment (the pool or scope).
The subnet mask (which tells the device what part of the address is the network and what part is the host).
The default gateway (the router that sends traffic to other networks).
The DNS server addresses the device should use.
The lease time.
You also need to know about DHCP reservations: assigning a specific IP address to a specific device based on its unique hardware address (the MAC address, which is a permanent identifier burned into the network card). This is useful for servers or printers that need a fixed address but still benefit from DHCP's other settings. You should also understand DHCP relays (agents that forward DHCP broadcasts across different network segments) because a DHCP server cannot see broadcasts from other networks by default.
Both DNS and DHCP are critical services. If DHCP fails, new devices cannot join the network. If DNS fails, users cannot access websites by name, even though the network is technically working. On LPIC-2, you will be tested on configuring, troubleshooting, and securing both services.
Install the DHCP Server Software
On a Debian-based system, you run 'apt update' then 'apt install isc-dhcp-server'. On Red Hat-based systems, use 'yum install dhcp'. This installs the dhcpd daemon and creates the base configuration file at /etc/dhcp/dhcpd.conf. Without this step, no devices can automatically receive IP addresses.
Define the DHCP Subnet and Pool
In dhcpd.conf, you define a 'subnet' block. For example: subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.100 192.168.1.200; option routers 192.168.1.1; option domain-name-servers 8.8.8.8, 8.8.4.4; default-lease-time 600; max-lease-time 7200; }. This tells the server which IP addresses to hand out, what the default gateway is, which DNS to use, and how long the lease lasts.
Create a Static DHCP Reservation
Inside the subnet block, add a 'host' statement: host printer { hardware ethernet aa:bb:cc:dd:ee:ff; fixed-address 192.168.1.10; }. This ensures the device with MAC address aa:bb:cc:dd:ee:ff always gets IP 192.168.1.10. This is crucial for servers and printers that need a predictable address.
Install and Configure BIND DNS Server
Install BIND with 'apt install bind9' (Debian) or 'yum install bind' (Red Hat). The main configuration file is /etc/bind/named.conf (or /etc/named.conf). Define zone statements: zone "example.com" { type master; file "/etc/bind/db.example.com"; };. This tells BIND to be the authoritative server for the example.com domain.
Create a Zone File for the Domain
Create the zone file, e.g., /etc/bind/db.example.com. It must contain a SOA record (start of authority) and at least one NS record. Then add A records for hostnames like 'www' and '@' (the domain itself), and possibly CNAME or MX records. For example: www IN A 192.168.1.20. Then run 'named-checkzone example.com /etc/bind/db.example.com' to validate.
Test and Troubleshoot the Setup
Use 'systemctl start isc-dhcp-server' and 'systemctl start bind9'. Check status with 'systemctl status'. Test DHCP by connecting a client device and running 'ip addr show' to see its assigned IP. Test DNS with 'dig www.example.com @192.168.1.5' (where 192.168.1.5 is your DNS server). If it returns the correct IP, the configuration works.
Picture this: you are a junior systems administrator at a medium-sized company called 'WidgetCorp' with 200 employees across three floors of an office building. The network has a single server room containing a Linux server running BIND for DNS and ISC DHCPd for DHCP. Today is your first day, and your senior tells you the Wi-Fi has been unreliable. Employees on the second floor cannot connect at all.
Your first step is to check the DHCP server. You log into the Linux server and examine the DHCP log file (typically /var/log/syslog or a dedicated log). You see errors suggesting that the DHCP server is running out of addresses in its pool. You check the configuration file (/etc/dhcp/dhcpd.conf) and see that the address range is 192.168.1.100 to 192.168.1.200. That is only 100 addresses for 200 people. Worse, the lease time is set to 24 hours, meaning addresses are not being recycled quickly. You change the lease time to 4 hours and expand the pool to 192.168.1.50 to 192.168.1.250. You restart the service (systemctl restart isc-dhcp-server). You then walk to the second floor, test a connection, and it works.
But there is a deeper issue. The CEO's printer, which has a DHCP reservation (always gets IP 192.168.1.10), suddenly cannot print. You check the reservation in the dhcpd.conf file. It is configured with the printer's MAC address: aa:bb:cc:dd:ee:ff. But the printer's label shows MAC address aa:bb:cc:dd:ee:ff:01. Someone replaced the printer's network card without telling you. You update the reservation with the new MAC address and the printer comes back online.
Now, a user complains they cannot access the internal company wiki at "wiki.widgetcorp.com". This is a DNS problem. You run the command 'dig wiki.widgetcorp.com' from your Linux terminal. You get an answer that shows the IP address of the wiki server is 192.168.1.15. That matches the server's static IP, so the DNS record looks correct. But then you run 'nslookup wiki.widgetcorp.com' and it returns 'server failed'. This tells you the DNS server itself is not properly resolving the query. You check the BIND configuration file (/etc/bind/named.conf) and the zone file for 'widgetcorp.com'. You notice the zone file has a missing dot at the end of one of the hostnames. In DNS, a missing trailing dot is a common mistake that means the name is interpreted as a relative name instead of an absolute one. You add the missing dot, reload the zone, and the wiki becomes accessible.
Later, you need to set up a new internal application server. You want it to have a static IP but also get its DNS server address from DHCP. You configure a DHCP reservation for its MAC address, setting a fixed IP. Then you add a DNS record (an 'A' record) for the server's name in the zone file. The application team then uses the hostname to connect to the server, and because the server got the correct DNS server address from DHCP, it can resolve other internal names.
Finally, you set up a DHCP relay agent on the router on the second floor because the DHCP server is in the server room on the ground floor, and you want the second floor's devices to be able to get addresses from the central DHCP server. Without the relay, the second floor's broadcasts would never reach the server. You configure the relay to point to the DHCP server's IP address (192.168.1.5) and set the interface it should listen on. This solves the connectivity problem for the second floor permanently.
LPIC-2 exam objective 201.3 is notoriously detailed. The exam expects you to know the configuration files, daemon names, and key directives for both BIND (named) and ISC DHCPd (dhcpd). This is not just theory; you must be able to identify correct syntax in multiple-choice questions and fill-in-the-blank scenarios.
The exam loves to test your understanding of the DORA process for DHCP. A typical question might ask: "After a DHCP client sends a DISCOVER message, what type of message does the server send back?" The answer is an OFFER. They will try to trap you by offering 'ACK' or 'REQUEST' as options.
For DNS, they frequently test the difference between an authoritative answer and a non-authoritative (cached) answer. They will show you output from 'dig' and ask you to interpret the 'flags' field. If the 'aa' flag is set, it is authoritative. If not, it is cached. They also love the concept of a full query (recursive) versus an iterative query. Know that the root hint file (named.ca) is used for recursive queries when the server is not authoritative for a domain.
Configuration file syntax is a goldmine for traps. For BIND's named.conf file, you need to know:
The 'options { }' block contains global settings like 'directory' and 'forwarders'.
The 'zone "example.com" { type master; file "db.example.com"; };' block defines a zone.
The zone file (db.example.com) uses SOA (Start of Authority), NS (Name Server), A (IPv4 address), AAAA (IPv6 address), CNAME (canonical name, an alias), and MX (Mail Exchange) records.
For DHCP's dhcpd.conf file, you need to know:
The 'subnet 192.168.1.0 netmask 255.255.255.0 { }' block defines a scope.
Inside the scope, 'range 192.168.1.100 192.168.1.200;' defines the pool.
'option routers 192.168.1.1;' sets the default gateway.
'option domain-name-servers 8.8.8.8;' sets the DNS.
'host printer { hardware ethernet aa:bb:cc:dd:ee:ff; fixed-address 192.168.1.10; }' creates a reservation.
The exam also tests the 'dhcp-lease-list' command for viewing active leases and 'dhcpd -t' for testing the syntax of the configuration file before restarting. For BIND, 'named-checkconf' and 'named-checkzone' are the tools to validate configuration and zone files.
Another common trap is the logging configuration. BIND logs to syslog by default, but can be customised. DHCP can log to its own file. Questions might ask where to find DHCP lease files (typically /var/lib/dhcp/dhcpd.leases).
You must understand the difference between dynamic DNS (where DHCP updates DNS automatically when a device gets an address) and static DNS (manual editing of zone files). The exam might ask about the 'ddns-update-style' directive in DHCP configuration.
Finally, be prepared for questions about IPv6. DHCPv6 (the IPv6 version of DHCP) and SLAAC (Stateless Address Autoconfiguration) are both tested. Know that SLAAC uses router advertisements, while DHCPv6 can assign addresses and other options. The exam may ask which protocol is used for what in an IPv6 environment.
DNS translates domain names to IP addresses, acting as the phonebook of the internet.
DHCP automatically assigns IP addresses and network settings to devices when they connect, using the DORA process (Discover, Offer, Request, Acknowledge).
The BIND DNS server uses named.conf for global options and zone files for individual domain records (A, AAAA, CNAME, MX, NS, SOA).
The ISC DHCP server uses dhcpd.conf to define subnets, address pools, lease times, and static reservations by MAC address.
Use 'dig' and 'nslookup' for troubleshooting DNS resolution; use 'dhcpd -t' and 'named-checkconf' to validate configuration syntax before restarting services.
DHCP leases have a set lifetime; changing DHCP scope ranges does not force existing clients to update until their lease expires or they reconnect.
A CNAME record can only point to another domain name, never directly to an IP address.
In IPv6, SLAAC and DHCPv6 both perform address assignment, but DHCPv6 offers more control over options like DNS server addresses.
These come up on the exam all the time. Here's how to tell them apart.
DHCP (Dynamic Host Configuration Protocol)
Automatically assigns IP addresses and network settings to devices upon connection.
Centralised management: changes to the network are made only on the DHCP server.
IP addresses are leased and can be recycled when devices leave the network.
Static IP Configuration
IP addresses are manually entered on each device, which is time-consuming and error-prone.
No central management; each device must be reconfigured individually if the network changes.
IP addresses are permanently assigned to each device, potentially wasting addresses if devices are decommissioned.
A Record (Address Record)
Maps a hostname directly to an IPv4 address (e.g., ftp.example.com -> 192.168.1.10).
Only one A record per hostname is typical, though round-robin is possible.
Required for DNS resolution to complete; a CNAME always points to an A record eventually.
CNAME Record (Canonical Name Record)
Maps a hostname to another hostname (an alias), like alias.example.com -> www.example.com.
Cannot point directly to an IP address, only to another name.
Often used for services like 'www' pointing to the same server as the domain root '@'.
DHCPD (ISC DHCP Server)
Listens on port 67 (UDP) and assigns IP addresses to clients via DHCP messages.
Configuration file is /etc/dhcp/dhcpd.conf (or /etc/dhcpd.conf on some systems).
Manages leases, pools, and static reservations by MAC address.
BIND (Berkeley Internet Name Domain)
Listens on port 53 (UDP/TCP) and resolves domain names to IP addresses.
Configuration files are named.conf and individual zone files (e.g., db.example.com).
Manages authoritative zones, caching, and forwarders for DNS queries.
Mistake
DNS and DHCP are the same service because they both deal with IP addresses.
Correct
DNS translates domain names to IP addresses. DHCP assigns IP addresses to devices when they connect to a network. They are separate services that frequently work together but solve different problems.
Beginners hear both terms in networking contexts and assume they are interchangeable because both involve IP addresses. The exam clearly tests them as distinct services with separate configuration files and daemons.
Mistake
When you change a DHCP scope range, all existing clients automatically get new addresses from the new range immediately.
Correct
Existing clients keep their leases until they expire. Only when a client renews its lease or reconnects will it get an address from the new range. You may need to force a renew or wait for lease expiry.
People assume changes are instant, like a web page refresh. DHCP works on a lease-based system, so changes take effect at the next renewal, not immediately.
Mistake
A CNAME record can point to an IP address directly.
Correct
A CNAME (canonical name) record can only point to another domain name (canonical name), not an IP address. To point a name to an IP address, you use an A (or AAAA) record.
The name 'CNAME' sounds like it should be a generic alias for any address. The exam tests the strict definition that a CNAME must resolve to another name, not an IP.
Mistake
If a DNS server returns a 'NXDOMAIN' response, the domain exists but is temporarily unreachable.
Correct
NXDOMAIN (Non-Existent Domain) means the domain name does not exist in DNS at all. The domain might be unregistered, the record may have been deleted, or there is a typo. It is not a 'temporarily down' error.
Users see 'server not found' and assume the server is offline. DNS distinguishes clearly between 'domain does not exist' and 'server is busy' (SERVFAIL).
Mistake
You need to restart the DHCP service every time you add a new static reservation for a device that is already connected.
Correct
DHCP reservations are only applied when a device requests a lease (upon boot or network connection). A device already holding a lease will not be affected until that lease expires. You do not need to restart the service; the next time the device requests an address, it will receive the reserved one.
People think of configuration files as 'live updates'. DHCPd reads the config on start, but reservation assignments happen on a per-request basis, not retroactively.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A DHCP reservation is configured on the DHCP server: the server always assigns the same IP to a specific MAC address. A static IP is manually entered on the device itself, bypassing DHCP entirely. DHCP reservations are easier to manage centrally.
SOA (Start of Authority) is the first record in a zone file. It defines the primary name server, the admin email, and timing parameters like refresh and expiry intervals for secondary servers. It is essential for zone transfers and replication.
Check that the DHCP server is running ('systemctl status isc-dhcp-server'), check its configuration syntax ('dhcpd -t'), and look at the log file (/var/log/syslog or a custom log). Common issues include the server not being on the same network segment without a relay agent.
An A record maps a hostname directly to an IPv4 address. A CNAME record maps a hostname to another hostname (an alias). The final resolution still requires an A record for the target hostname. CNAMEs cannot point directly to an IP address.
No. Devices use the DNS server address they received during their last DHCP lease assignment. They will only receive the new DNS server address when they renew or obtain a new lease. You may need to restart the network service on clients or wait for lease expiry.
A DHCP relay agent is a device (usually a router) that forwards DHCP broadcast messages from one network segment to a DHCP server on another segment. You use it when your DHCP server is not on the same subnet as the clients, because broadcasts do not cross routers normally.
You've finished DNS and DHCP Configuration. Continue through the LPIC-2 study guide to build a complete picture of the exam.
Done with this chapter?