DHCP can be impacted by separate DNS appliances. DHCP pauses lease issuing until a DDNS update is completed.

The DNS server and NIOS DB is single threaded. So it pauses when doing an DDNS update. If you have thousands of DDNS updates happening, this can impact recursive DNS if it is happening on the same box as the DDNS updates.

This is why a dedicated primary (internal) is useful if internal authoritative is the first layer of recursion. However, you can also have the recursive servers forward internally as required.

This is also why it is good for the hidden primary (internal) to be HA (for resiliency) while it is good for all the secondaries to be standalone and then use Anycast and BFD for resiliency.

Note the word “dedicated”, since it is internal, the NIOS won't “find” the internal domain by recursion from root so you will have had to set up a forwarder for your recursive resolver to reach it. For this reason, the primary (SOA) does not “have” to be hidden because nothing should be finding it automatically. You can hide the dedicated primary by removing from NS records but you will have to keep it in the SOA record which means it is not truly hidden.

For Dynamic DNS updates, you can configure permissions based on TSIG or based on source address but not both. If a system tries to use both, it may succeed if either TSIG or address is correct.

For NIOS DHCP boxes updating NIOS DNS boxes, there is a private TSIG key used to permit the updates. (DHCP_UPDATER_default)

For NIOS DHCP updating a NIOS zone, TSIG is used for the updates, and there is a zone {} statement at the bottom of dhcpd.conf that explicitly says where to send updates. If you're using multiple primaries for a zone, you can specify which primary will get the updates. See Defining the Default Primary for DDNS Updates to Zones with Multiple Primaries.

• Standard ISC (Strictest). Only create record if no A record exists already or, if one does exist, only update the existing record if the new TXT matches existing TXT.
• Check-Only (Less Strict). Only create record if no A record exists already or, if one does exist, only update the existing record if there is a TXT record for it as well (regardless of whether the TXT records match).
• ISC Transitional (Temporary). No checks in place. Should only be used during a migration. Then change to ISC or Check-Only.
• No TXT Record. This method should be used with caution because anyone can send DDNS updates and overwrite records. This method is useful when both ISC and non-ISC-based DHCP servers and clients are updating the same zone.

If you have a host that has the same MAC and two IP addresses in separate networks (e.g. effectively two fixed IP addresses. e.g. one for DC1 and one for DC2)

If you want DNS to update, make sure DHCP is doing DDNS and that you UNtick “Enable in DNS” in the Hosts “General” properties. This means DDNS does its thing as you move the host around the network. If you tick “Enable in DNS” then the DNS server (if the DNS server is NIOS) will return all the IP addresses associated with the Host when asked (rather than the 'active' IP).

Note: The DDNS update will use the hostname provided by the client (not the name typed into the Host record)

For this NIOS option see here.

If you have Multi-Master DNS, you may want to specify which nameserver should be used to do the updates.

If the SOA MNAME records points to a hidden server, NIOS may choose one of the NS servers instead. This was seen once in a multi-master configuration.

If you add a domain controller to a Microsoft Active Directory domain and find that the new domain controller cannot update records in DNS (e.g. NIOS DNS), make sure you enable the 'register in DNS' setting in the TCP/IP settings of the domain controller's network interface. If you do not, you may see the following error in the NIOS logs.

client @0xffffffffffff 192.168.11.22#58685: view 3: updating zone 'ad.domain.com./IN': update unsuccessful: ad.domain.com: 'name not in use' prerequisite not satisfied (YXDOMAIN)

There is no reason to enable “Update DNS on DHCP Lease Renewal”. This feature is already implemented in BIND with the deferred update mechanism. If a DDNS update is lost for some reason, it will be re-queued and re-attempted later. Which is basically also what the “Update on Lease Renewal” feature does.

“Update DNS on DHCP Lease Renewal” was designed for situations where Infoblox is running DHCP and Microsoft is the DNS server. Microsoft DNS scavenging only uses one parameter - time of last dynamic update. So the client needs to update every time it renews its lease, or it risks having its record scavenged.

It is sometimes when clients are regularly switching between interfaces, such as moving from the docking station to the wireless network and back again, while leases are active on both networks with the same hostname but with different MAC addresses.

Support will recommend turning it off because it can have major performance implications. Particularly where lease times are low. Keep it disabled for most environments. If you think it may be necessary, engage support or PS because enabling it.

Palo Alto Networks Prisma Access supports DDNS and the documentation is here.

It is not possible for clients to update the same zone in multiple network views via DDNS updates.