DHCP and DNS are the two fundamental services in an IT network. Whilst DNS makes sure that servers, clients, and services can be found in the network, DHCP ensures that the clients in the network are also provided with the information they require to participate in the communication.
Dynamic Host Configuration Protocol or just DHCP
DHCP stands for Dynamic Host Configuration Protocol and is a network protocol via which a client can request an IP configuration and in turn be assigned one by a DHCP server. This negates the need for manual setup of the client’s network interface, which saves a considerable amount of time and administrative effort. Instead, the client itself communicates with the server and procures all the necessary parameters such as the IP address, network mask, and gateway independently.
In addition, it is also possible to communicate a whole range of other DHCP options such as the boot server for the PXE-based rollout, time server, and even the proxy configuration via WPAD.
Generally speaking, a server only assigns this information for a certain period of time (lease time), meaning that clients are required to renew their configuration regularly.
Whereas the DHCP protocol plays a particularly fundamental role in IPv4 networks, IPv6 features mechanisms via which clients can assign themselves unique IPv6 addresses autonomously (SLAAC). Nevertheless, the use of a DHCP server can also be practical in IPv6 networks for the distribution of additional information such as time servers to clients as in IPv4.
DNS stands for Domain Name System and its function can be compared to that of a telephone directory. Network devices maintain one or more IP addresses, which are either statically configured or assigned via DHCP. These IP addresses allow the devices to communicate with one another via the IP protocol.
However, it is very difficult for people to remember IP addresses – in contrast to easily pronounceable domain names such as “www.univention.com”. DNS now keeps an account of the assignment of the pronounceable name, i.e., the domain name, to the respective IP address and can provide devices submitting requests with information in one direction or the other at any time.
In this way, DNS is primarily an extensive, hierarchical network of thousands of Internet servers around the world, which compare themselves with each other and divide specific namespaces amongst themselves in so-called zones (e.g., top level domains (TLD) like “.com” and “.de”.
Not only that, a DNS server is also generally used for name resolution in internal networks. This DNS server knows all the devices in the internal domain and can assign them the respective name. For outgoing requests – in other words, requests to the Internet – this internal DNS server can contact one or more external DNS servers and answer the requests in this way via the DNS network.
At this point, I’d like to recommend the great web comic https://howdns.works/, which illustrates the technical contexts and functions wonderfully.
Dynamic DNS (DDNS) describes a process in which the name servers in the DNS are updated automatically. This is especially important for the fluid interaction between DHCP (assignment/amendment of IP addresses) and DNS (logging of assignment of name to IP address). For example, once a DHCP server has assigned an IP address to a client which has submitted a request, it can also communicate this information directly to a DNS server. In this way, the DNS information concerning the client in question can also be automatically updated/corrected.
In another version, the client itself can also communicate this information to the DNS server. The latter system is employed by Windows clients, for example. Depending on the source, this is referred to as a DNS update (RFC 2136) or dynamic update (Microsoft).
UCS and DHCP / DNS
UCS now always provides a DNS server on the master, backup, and slave server roles, too (BIND). On the same server roles, it is also optionally possible to operate a DHCP server (ISC DHCP). More on this in the UCS manual. The respective services procure the information concerning both the DNS and DHCP from the OpenLDAP directory service provided by UCS. That means that the DHCP and DNS configuration can also be processed with the standard tools such as UMC and UDM and that changes are automatically copied to other UCS systems via the listener/notifier replication mechanism, which ensures the information is synchronized across all systems.
In the case of DNS, there is also another distinctive feature: If Samba is employed as an Active Directory-compatible domain controller, the DNS demon uses Samba’s own directory service and not OpenLDAP as the source for its information. This is an essential requirement for the dynamic DNS update of Windows clients mentioned above, for example. At this point, the S4 connector then ensures that the DNS information is synchronized between Samba and OpenLDAP.
Possible DHCP configurations:
In the default setting, the UCS DHCP server only assigns IP addresses to clients known in the directory service, i.e., which have been created via UMC or UDM in advance. These clients also always receive the same IP address via DHCP, so it is a reservation. The DNS information (assignment of IP to client name) is created accordingly and then replicated to additional UCS DNS servers via the listener/notifier mechanism.
However, if IP addresses are distributed to all clients submitting requests via an IP range on the DHCP pool – irrespective of whether created in the directory service in advance or not – two things must be observed:
- The clients must notify the DNS server of their updated IP address automatically (dynamic DNS update)
- If more than one DHCP server is employed for failsafe performance reasons, a failover peer must be set up so that the DHCP servers can coordinate the IP address assignment directly and ensure that addresses are not assigned twice.
In UCS, DHCP, DNS, and DDNS are automatically preconfigured, which saves a considerable amount of administrative effort. However, the standard administration tools (UMC as the web interface and UDM as the CLI tool) can also be used to expand the services further and customize them to suit individual requirements. UCS’ strengths such as the central administration in combination with the automatic replication of the DNS and DHCP information to other UCS systems pay off in complex and distributed environments with many clients and DNS-based services in particular.
We hope, you enjoyed this article. Feel free to comment below if you have any further questions or contact us via our forum.