DNS and DHCP

Overview

DNS (Domain Name System) and DHCP (Dynamic Host Configuration Protocol) are core services in almost every networked environment. In server administration, you will often:

• Design and manage internal DNS zones for your organization.
• Provide DHCP leases to clients on different subnets/VLANs.
• Integrate DNS and DHCP so that clients get names automatically.
• Secure and harden these services, especially on Internet-facing systems.
• Troubleshoot name resolution and address assignment issues.

This chapter provides a practical, server‑focused view of DNS and DHCP on Linux: how they fit into a typical infrastructure, their interactions, and key design and operational considerations.

Roles of DNS and DHCP in a Network

DNS: Naming and Service Discovery

DNS maps human‑readable names (e.g. www.example.com) to IP addresses and other data. In a server environment, DNS is used for:

• Host naming: Servers, clients, appliances (db01.internal.example.com).
• Service discovery: Locating services via SRV or TXT records (e.g. LDAP, Kerberos, SIP).
• Mail routing: Using MX records to direct email.
• Reverse lookups: Mapping IP addresses back to hostnames (PTR records).
• Delegation: Splitting control across teams or regions via zones.

On internal networks, you typically maintain at least one authoritative DNS server for your own domain (e.g. corp.example.com), and one or more recursive/caching DNS servers used by clients and servers as resolvers.

DHCP: Automatic IP Configuration

DHCP automates configuration of network parameters on clients. In a typical infrastructure, DHCP provides:

• IP address (lease) and subnet mask.
• Default gateway.
• DNS servers (and often search domain).
• Optionally, NTP servers, PXE boot information, VoIP options, etc.

DHCP servers are usually per subnet (or reached via DHCP relay) and must be carefully designed to avoid overlapping address pools and conflicting configuration.

Typical Deployment Architectures

Small Office / Lab

• One server (or router) provides:
• DHCP for one or a few networks.
• DNS (caching/forwarding resolver) pointing to ISP or upstream DNS.
• Optional local authoritative zone for simple hostnames (nas.local, printer.local).

This is often simplified further when a consumer router acts as both DNS forwarder and DHCP server.

Enterprise / Multi‑Subnet

Common patterns:

• Centralized DNS:
• One or more authoritative DNS servers for internal zones (corp.example.com, 10.in-addr.arpa).
• A tier of recursive resolvers for all clients and application servers.
• Distributed DHCP:
• DHCP servers per site or data center.
• DHCP relay (IP helper) on routers to funnel client broadcasts to central DHCP at HQ or DC.
• Split-horizon DNS:
• Internal view: www.example.com resolves to private IP.
• External view: same name resolves to public IP.

Integration points:

• DNS servers may dynamically update records when DHCP assigns or releases addresses.
• Authentication and auditing backends (e.g. LDAP, RADIUS) may link device identity to DHCP.

Cloud Environments

Cloud providers (AWS, Azure, GCP) often provide:

• Managed DNS services (Route 53, Azure DNS, Cloud DNS).
• Built‑in DHCP functionality in virtual networks (VPC/VNet) that auto‑assign addresses.

Even so, you may still deploy:

• Internal DNS: for service discovery in Kubernetes clusters, hybrid networks, or cross‑region private zones.
• Custom DHCP: for bare‑metal nodes, PXE boot, or appliances that cannot use cloud‑native metadata services.

DNS and DHCP Interaction

DNS and DHCP solve different problems but often work together:

• DHCP gives the client an IP address and tells it which DNS servers to use.
• DHCP optionally tells the client its own hostname or allows the client to send a hostname.
• The DNS server (or an intermediate daemon) uses DHCP events to create or update DNS records:
• Forward mapping: hostname.example.com → IP (A/AAAA record).
• Reverse mapping: IP → hostname.example.com (PTR record).

This integration can be:

• Static: Admin manually creates DNS records; DHCP just hands out IPs.
• Dynamic but insecure: DHCP directly updates DNS with no authentication.
• Dynamic and secure: Updates are authenticated (TSIG, GSS‑TSIG) and possibly restricted per subnet or group.

Understanding this relationship is crucial when dealing with:

• Rapidly changing environments (VDI, Wi‑Fi clients).
• Automated provisioning (PXE, cloud‑init, configuration management).
• Security policies that rely on hostname logging (firewall, proxy, SIEM).

Design Considerations

Addressing and Lease Strategy

When planning DHCP:

• Static vs dynamic:
• Servers usually have static IP addresses (manual or reservations).
• Clients usually get dynamic addresses from pools.
• Lease times:
• Laptops/Wi‑Fi devices: shorter leases (e.g. 2–12 hours).
• Stable wired desktops or phones: longer leases (days).
• Critical equipment: static assignment or very long leases to avoid churn.

Address pool sizing:

• Account for:
• Peak concurrent clients.
• Address fragmentation (exclusions, static assignments).
• Future growth.
• Reserve ranges for static assignments to infrastructure devices (routers, firewalls, servers).

Namespaces and Zones

For DNS:

• Internal vs external zones:
• Use a distinct internal domain, e.g. corp.example.com or example.internal.
• Avoid naming collisions with public domains.
• Subdomain delegation:
• Large organizations often delegate per region or department (emea.corp.example.com, lab.corp.example.com).
• Reverse zones:
• Create reverse DNS zones at least for server subnets and critical infrastructure.
• Many tools (logging, monitoring, security) rely on PTR lookups.

Redundancy and Availability

Both DNS and DHCP must be resilient:

• DNS:
• At least two authoritative servers for every zone.
• At least two recursive resolvers configured on clients.
• Use anycast or load‑balanced virtual IPs for high‑traffic resolvers.
• DHCP:
• DHCP failover or hot‑standby (implementation‑specific).
• Split scopes between servers (e.g. 50/50 or 80/20 split) as a simple redundancy model.
• DHCP relay redundancy through multiple IP helpers on routers.

Network segmentation:

• Ensure firewalls, ACLs, and routing allow:
• DHCP (UDP 67/68) between clients, relays, and servers.
• DNS (UDP/TCP 53) between clients and resolvers, and between resolvers and authoritative servers.

Security and Policy

Security issues:

• Rogue DHCP servers:
• A malicious or misconfigured device can offer fake IP settings, redirecting traffic.
• Poisoned DNS:
• Compromised or misconfigured resolvers can direct traffic to hostile servers.
• Cache poisoning or on‑path attacks can inject fake responses.

Mitigation strategies:

• Port security and switch features to prevent unauthorized DHCP servers.
• Limit DHCP and DNS services to controlled VLANs and IP ranges.
• Use DNSSEC on public‑facing zones to protect integrity of records (and, optionally, validate on resolvers).
• Restrict which hosts may perform zone transfers (AXFR/IXFR) from authoritative servers.
• Log DNS queries and DHCP leases for auditing and incident response.

Operational Practices

Managing Changes

• DNS change control:
• Treat DNS zone files as configuration-managed assets (version control).
• Use staged deployment: update secondary servers after verifying zone syntax.
• Use low TTLs during migrations (e.g. moving services between IPs).
• DHCP change control:
• Coordinate pool changes with network team (subnets, VLANs, routes).
• Document static assignments and reservations.
• Avoid overlapping scopes, especially when multiple DHCP servers or relays are involved.

Monitoring and Logging

Key metrics and logs:

• DNS:
• Query volume and latency.
• SERVFAIL and NXDOMAIN rates.
• Unusual query patterns (possible malware/beaconing).
• Zone transfer attempts and failures.
• DHCP:
• Pool utilization (remaining free leases).
• Declined IPs (possible ARP conflicts).
• Lease assignment failures.
• Rogue or repeated DISCOVER from misbehaving devices.

Tools:

• Native logs from your DNS/DHCP daemon (usually under /var/log or systemd journal).
• SNMP or Prometheus exporters for statistics.
• SIEM integration for correlating DNS and DHCP with security events.

Troubleshooting Patterns

Common DNS troubleshooting steps:

• Verify name with dig or nslookup from:
• Local machine.
• A known‑good resolver.
• Check:
• Forward and reverse records.
• TTL and record propagation (especially after changes).
• That clients are using the intended DNS servers (check resolv.conf or equivalent).
• Validate zone loading and syntax on authoritative servers.

Common DHCP troubleshooting steps:

• Confirm client is on the correct VLAN/subnet.
• Verify DHCP relays (IP helper addresses) on routers.
• Check DHCP server pool usage: ensure free addresses.
• Examine logs for DISCOVER/OFFER/REQUEST/ACK sequences.
• For conflicts:
• Look at ARP tables and switch MAC tables to locate the conflicting host.

Combining DNS and DHCP debugging:

• Map a problematic client by:
• MAC address → DHCP lease → IP address → hostname → DNS records.
• Use that chain to verify each layer:
• Is the client getting the intended lease?
• Is the hostname matching what logs and monitoring expect?
• Are forward and reverse DNS records consistent?

Integration with Other Services

PXE Boot and Provisioning

In environments with automated OS installs:

• DHCP provides:
• TFTP server IP and boot file name (PXE options).
• Potentially HTTP or iSCSI boot parameters.
• DNS provides:
• Names for provisioning servers (pxe01.corp.example.com).
• Records for newly provisioned hosts (static or dynamic).

This tight integration allows fully automated bare‑metal provisioning pipelines.

Directory Services and Authentication

In domains using centralized authentication (e.g. LDAP, Kerberos, Active Directory‑like environments):

• DNS:
• Hosts SRV records for domain controllers and LDAP servers.
• Supports service discovery for clients (Kerberos, LDAP, AutoDiscover, etc.).
• DHCP:
• Distributes domain search suffixes and DNS server addresses to clients.
• Optionally distributes configuration for VoIP phones, thin clients, and specialized devices that rely on directory services.

Logging, Security, and Compliance

Many security systems depend on DNS and DHCP data:

• Firewall and proxy logs often contain only IPs.
• SIEMs correlate:
• DHCP leases → map IPs to MAC/hostnames and user sessions.
• DNS queries → detect suspicious domains or C2 traffic.

For compliance:

• Preserve DNS and DHCP logs for the required retention period.
• Ensure time synchronization (NTP) so timestamps across systems align.

Practical Administration Tips

• Keep a consistent hostname and naming scheme; avoid renaming hosts frequently.
• Use documented IP plan and host inventory; DNS and DHCP configs should reflect it, not replace it.
• Prefer automation:
• Generate parts of DNS/DHCP configs from source of truth (e.g. CMDB, Git, IPAM).
• For public services:
• Separate public and internal DNS administration.
• Use low TTLs when planning cutovers; raise them afterwards to reduce load.
• For Wi‑Fi and guest networks:
• Place them in dedicated subnets and scopes.
• Consider using separate recursive resolvers with stricter logging or filtering.

Summary

For a Linux server administrator, DNS and DHCP are foundational network services that must be:

• Correctly designed (namespaces, address plans, redundancy).
• Securely operated (access control, logging, monitoring).
• Closely integrated (dynamic updates, provisioning, directory services).
• Easily troubleshootable via clear logs, metrics, and tooling.

Strong mastery of DNS and DHCP is a prerequisite for successfully running higher‑level services such as web, email, directory, and cluster/HA infrastructures.