HOWTO Design a fault-tolerant DHCP + DNS solution

From Consultancy.EdVoncken.NET

In this article, we will describe a design for a fault-tolerant (redundant) DHCP + DNS solution on Linux.

Design criteria:

• Failure of one DHCP server should not prevent Clients from obtaining a valid IP address.
• Failure of one DNS server should not prevent Clients from executing DNS queries.
• The design should allow for Dynamic DNS updates.

Contents 1 Design Overview 2 Fault-Tolerant DHCP Service 3 Fault-Tolerant DNS Service 3.1 DNS Master / Slave 3.2 DNS Multi-Master 3.3 Design Decision 4 Operational Issues 4.1 Managing combined Static and Dynamic DNS

[edit] Design Overview

In the image below, you can see the design involving DNS Master / Slave as well as DHCP Primary / Secondary servers.

The sequence of events is as follows:

1. The Client initiates a DORA (Discover, Offer, Request, Accept) communications sequence with the DHCP servers.
2. Depending on the Client MAC address, one of the DHCP servers will respond with a DHCP_OFFER.
3. The Client obtains an IP address as well as additional network settings.
4. The DHCP server communicates the new lease to its partner.
5. The DHCP server sends a DNS update to the DNS Master server.
6. The DNS Slave server(s) are kept in sync using DNS Zone Transfers.

[edit] Fault-Tolerant DHCP Service

In this design, we will use the ISC DHCP daemon. One of the features includes a DHCP Primary / Secondary failover configuration, consisting of exactly 2 DHCP servers.

The DHCP servers share a pool of IP addresses, and keep the lease database for this pool in sync between them. If one DHCP server fails, the remaining server will continue to issue IP addresses. This guarantees uninterrupted service to the Clients.

• See Also: HOWTO Configure DHCP failover

[edit] Fault-Tolerant DNS Service

In this design, we will use the ISC DNS daemon. There are two ways to achieve fault tolerance:

1. Master / Slave configuration
2. Multi-Master configuration

[edit] DNS Master / Slave

DNS Master / Slave configuration is fairly straightforward. All zone data is kept on the DNS Master. The Master is configured to allow zone transfers from the DNS Slaves. Each DNS Slave performs zone transfers to obtain the most recent DNS information from the DNS Master.

Clients obtain a list of DNS servers through DHCP. If a DNS server fails, the Client will attempt to contact one of the remaining DNS servers. This guarantees uninterrupted DNS resolution service to the clients.

If the DNS Master fails, the situation becomes more severe. The DHCP servers communicate their updates only to the DNS Master server. In case of an outage, Dynamic DNS updates could be lost. One possible solution is the use of a DNS Multi-Master configuration.

[edit] DNS Multi-Master

DNS Multi-Master configuration is more complicated to configure and maintain than a Master / Slave configuration.

In case of a DNS server failure, both DNS Query and DNS Update services remain operational.

[edit] Design Decision

For our design, it is sufficient if DNS Queries from Clients remain operational. We will choose the DNS Master / Slave approach here as it is less complex, and still satisfies the design criteria.

• See Also: HOWTO Configure Dynamic DNS

how

[edit] Operational Issues

[edit] Managing combined Static and Dynamic DNS

Dynamic DNS is an all-or-nothing feature. If DDNS is enabled for a specific DNS zone, it should no longer be edited manually - your changes may be corrupted or overwritten. This often conflicts with existing systems management practices.

There are two approaches to avoid potential DNS corruption issues when managing a combined Static / Dynamic DNS environment:

Create a separate DNS zone for Dynamic DNS records

Static DNS records can still be managed in their own zone (example.local) as usual. Dynamic DNS records will be managed automatically in a separate DNS (sub-)domain, like "ddns.example.local".

Keep all DNS records in one Dynamic zone

All entries, both static and dynamic, are in the same DNS zone (example.local). Static entries should be managed using the "nsupdate" utility - this means that system management practices and tooling may need to be changed.

In this design, we will use a single Dynamic zone. Static entries will be managed using the "nsupdate" utility.

GhDDHf <a href="http://oboaunxjgebl.com/">oboaunxjgebl</a>, [url=http://fkkdyxbeywse.com/]fkkdyxbeywse[/url], [link=http://dysdlhcphjxn.com/]dysdlhcphjxn[/link], http://dxrsbdueozph.com/