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

The DNS server 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 hidden 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.

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

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.