Document toolboxDocument toolbox

Guidelines for DDNS Updates

Before attempting to configure DDNS, please familiarize yourself with how the Infoblox Portal and BloxOne DNS server process DDNS updates. The Infoblox Portal, which is the cloud component of Universal DDI, is always the primary DNS server; by contrast, all BloxOne DNS servers are NIOS-X Servers with the DNS service enabled and are secondary DNS servers.

The diagram below illustrates how DDNS updates work in Universal DDI:

  1. BloxOne DHCP initiates a DDNS update after providing a lease to a DHCP client according to the MNAME lookup.

  2. To process the update, the NIOS-X Server forwards the update to the Infoblox Portal, which is the primary server.

  3. The DDNS update is not performed locally. Instead, the cloud processes and then sends the update to all secondary BloxOne DNS servers.

The following characterizes DNS zones managed by Universal DDI:

  • The MNAME defaults to ns.b1ddi.<zone_name>, but this can be overridden through the Infoblox Portal.

  • The A record for this zone points to the queried BloxOne DNS server. This gives the appearance of there being multiple primary servers.

  • An NS record exists for all secondary BloxOne DNS servers.

  • Universal DDI does not provide a stealth option for NS records.

When the Infoblox Portal is down or loses connectivity with the NIOS-X Server, the updates are queued to be sent to the cloud when the Infoblox Portal is back online. If the DDNS service is restarted on the NIOS-X Server, the queue is lost. The NIOS-X Server makes three attempts at one-minute intervals, and then the attempts are discarded. If the queue is full, the DDNS service stops accepting new entries until the queue is reduced to 80%. This behavior is specific to the BloxOne DDNS service performing the updates. Other than the DDNS updates made by the DHCP server, no types of DDNS updates are retried.

If Universal DDI gets a DDNS update from another source, such as a Microsoft domain controller, the DNS server attempts to send the update but does not retry. It is up to the DHCP client to retry.