This series of occasional posts is called Technical Know-How. It will explore a technical aspect of the BlueCat platform in-depth, giving customers the know-how to configure and implement it.
Dynamic DNS (DDNS) automatically updates DNS records when an IP address changes. This includes dynamic IP address assignment by DHCP servers.
Most large IT enterprises use DDNS to deploy devices, helping admins to keep tabs on where they are. As DNS data changes over time, DDNS automatically makes those record updates and redirects devices where they need to go.
And it’s not just IP addresses. Automatic updates to other types of DNS records, such as TXT or SRV records, are equally useful, particularly for Active Directory users.
The alternative to DDNS is to manually update records each time an IP address changes. That’s a significant resource drain and leaves room for human error. With DDNS, network admins don’t have to reconfigure settings every time a change is made.
This Technical Know-How post will explore how to deploy DDNS on the BlueCat Address Manager and BlueCat DNS/DHCP server. Specifically, it will cover DNS and DHCP configuration for DDNS, the importance of zone declarations, and DDNS for mobile clients moving between wired and wireless.
DNS and DHCP configuration for dynamic DNS
To enable DDNS, configure the Allow Dynamic Updates DNS deployment option in Address Manager. It must contain a value matching the DHCP server that will perform the updates.
You can populate this option with any of the following parameters:
- IP address or block of IP addresses
- TSIG key
- Access control list
Where possible, we suggest restricting dynamic updates to DHCP servers.
In cases where you need to allow certain client computers to update DNS, you can add their IP addresses or subnets to the Allow Dynamic Updates option. Alternatively, you can use the Update Policy deployment option in place of Allow Dynamic Updates. For more details regarding these two methods, refer to the Address Manager Administration Guide.
Configure the following parameters to allow a DHCP server to dynamically update forward and reverse DNS zones on behalf of a client:
ddns-domainname: Domain name (where the domain name is the name of the domain DHCP will be updating)
When the DHCP client receives an IP address from a DHCP server configured for DDNS, its DDNS information, including its FQDN and a ddns-txt value (MD5 hash of its MAC address), is stored in the DHCP leases file. The TXT record acts as an identifier, indicating that the DHCP server owns the record.
Zone declarations help DHCP servers perform dynamic DNS
When a DHCP server needs to send a DNS update, it will perform a lookup of the start of authority (SOA) record. The SOA record contains important information about the DNS zone, including the primary nameserver hosting the domain (denoted in the record as MNAME). When a DHCP server has to perform a lookup for each of the IP clients it has given leases to, it can cause undue DNS traffic. Furthermore, it can fail if the incorrect nameserver is returned.
You can use a DHCP zone declaration (also called a statement) to help avoid failures when a DHCP server attempts to perform DDNS updates. The declaration defines a primary DNS server IP address for a specifically defined DNS zone.
A defined zone declaration will direct DDNS updates to the specific authoritative nameserver(s) for a specific domain. This bypasses the normal process of performing an SOA lookup. By eliminating the time for lookups and potential DNS failures, zone declarations can speed up the DHCP process.
BlueCat recommends defining zone declarations to ensure high resiliency for DDNS updates. Refer to the DHCP Zone Groups section of the Address Manager Administration Guide for more details. It includes step-by-step configuration information for DHCP zone declarations.
Dynamic DNS for mobile clients moving between wired and wireless networks
DHCP usually uses the hardware (MAC) address of a network interface to assign IP addresses and perform DDNS updates. As such, when moving from a wireless to a wired segment or vice versa, the client is switching interfaces. To the DHCP server, it’s like a new client.
Unless the client released the previous lease before switching connections (which almost never happens), the lease remains. As a result, the DHCP server will not update the host records that were assigned to the device’s other network interface.
For example, when a laptop is docked and plugged into a wired segment, its hostname can be dynamically updated in DNS by the DHCP server, as long as access control lists are set. However, if the laptop is unplugged and then switches over to a wireless segment, the hostname of the laptop will not resolve to the IP of the wireless address. The hostname is still in Address Manager, assigned to the IP address of the wired segment.
There are two methods to solve this issue: Use a DHCP raw option or use a separate zone for wireless DNS updates.
Use a DHCP raw option
IP clients can be resolvable on both networks with DDNS when you set a raw option to append a suffix to the hostname of the IP client.
On the wireless segment, add the following DHCP raw option:
ddns-hostname = concat(option host-name ,"-wifi");
This will append “-wifi” to the end of each host in the wireless segment. For example, if an IP client has the hostname of client1, the DDNS name would be client1 on the wired segment and client1-wifi on the wireless segment.
Use a separate zone for wireless DNS updates
Let’s suppose your main DNS zone is called example.com. All wired dynamic registrations go to example.com.
Then, for wireless networks, create a new subzone called wireless.example.com, which can be used to keep wireless DDNS updates.
Next, configure a DDNS domain name deployment option for the wireless DHCP subnet to point to this zone for all DDNS registrations.
This will allow a client with the hostname client1 to have a DNS record called client1.example.com for a wired interface and client1.wireless.example.com for a wireless interface.
For help with troubleshooting some common DDNS deployment errors, current customers can visit BlueCat’s Customer Care Portal.
9.3 Integrity Deep Dive On-Demand Replay
Learn how you can get more security data, ramp up automation, and adopt cloud without compromising performance.
For DNS server caching, what is the ideal TTL?
Many factors affect how to set time to live (TTL) for DNS servers. Learn more, plus how BlueCat Edge’s TTL features can bolster your network.
Comparing AWS, Azure, and GCP cloud DNS services
The public cloud presents major challenges for DNS management. Examine various capabilities and limitations of Azure, AWS, and GCP with BlueCat.
Five network pros’ manual error horror stories
Members of BlueCat’s Network VIP community detail the errors they committed, the resulting fallout, and what important lessons they learned.