You need your DDI services to be highly available. So you need to build redundancy into your DDI server architecture. How much redundancy is a question of risk, the business impact of any failure and available budget.
DNSBOX makes redundancy easier for you, because of the way the DNSBOX range is designed and priced, with multiple redundancy options. For a given budget, you can build more redundancy into your architecture.
DNSBOX gives you redundancy in layers:
- It encourages the inherent redundancy of the DNS master-slave approach, by making it easy and affordable.
- Its CFast architecture gives you an extra layer of redundancy for free.
- You can add extra servers for redundancy to your architecture, without adding high cost. DNSBOX makes redundant servers easier to deploy and more reliable than alternatives.
- A failover master eliminates a single point of failure and is recommended in more demanding environments.
- Multiple slave appliances can be clustered for high availability and load balancing.
- DHCP failover is notoriously difficult to implement. DNSBOX makes it easy.
For added redundancy, DNSBOX masters can be deployed with a failover unit. This is deployed in a standby mode and configured to synchronise data from the active master. In the event of the active server failing, the failover is restarted in active mode and starts to respond to zone transfer requests and name queries.
When the original active machine becomes available again, it is placed in standby mode until the data has been fully synchronised back. Both machines are then restarted and their modes reversed.
In some lower-risk deployments, a failover unit may be a luxury if budget is tight. In other cases, it is the sensible option to avoid a possible single point of failure. Unlike other vendors, ApplianSys prices failover units significantly cheaper than the first master unit.
If changes to authoritative DNS are made very often (including via Dynamic DNS), then any downtime of the master is a bad thing. If DNS data is fairly static, the remaining risk is that, in the unlikely case of the master failing, zones on slave units expire before the master is restored. So in a deployment where the DNS data is static, zones are set with long TTLs and the resulting tiny risk of a zone expiring would not have a disastrous impact on your business, you may decide not to spend your budget on a failover master.
In some scenarios, the normal DNS approach to redundancy, designed into BIND, won’t deliver the performance you need.
For example, some real-time applications timeout if a DNS query is not resolved fast enough. The standard approach – with alternate DNS servers on different IP addresses and clients configured to switch between them – can be too slow to beat the timeout.
So a single IP address must deliver 100% uptime. This demands high availability and rapid cutover in the event of a DNS server becoming unavailable.
DNSBOX achieves this by clustering two or more slaves. This combines failover and load-balancing functionality to give you a highly available, high performance DNS caching service. Unlike the standard approach, a DNSBOX cluster has a single IP address, so client configuration is simplified.
DNSBOX makes it easy to deliver ‘always on’ DHCP services. With just a few clicks the user interface helps you configure failover pairs to deliver high availability DHCP.
In a DHCP failover deployment, multiple DNSBOXes are clustered to respond to DHCP requests. The load of requests is balanced between boxes and IP lease information is continuously synchronised across the cluster.
A regular exchange of status messages tells each DHCP server that other units in its cluster are operational. In the event that a DNSBOX fails to send its status message, the rest of the cluster will continue to manage the load whilst SNMP traps notify network administrators.
The DNSBOX200 authoritative slave has a useful redundancy feature engineered by ApplianSys.
Normal BIND behaviour is that when a slave zone expires, if the master is for some reason unavailable, the zone will no longer be served to clients.
Offline master mode avoids this problem:
- DNSBOX200 takes zone backups regularly for use if the master becomes unavailable
- If connectivity with the master is lost, you can enable Offline Master Mode
- DNSBOX200 then assumes the role of a master, continuing to serve the zones from their last known ‘good’ state – effectively ‘freezing’ their TTLs
This offline feature is also useful in planned instances of master-slave disconnection:
- Before upgrades
- During migration or major re-organisation of DNS data
- If master-slave connectivity is known in advance to be intermittent – such as on board ships
