Before attempting to configure DDNS, please familiarize yourself with how the Cloud Services Portal and BloxOne DNS server process DDNS updates. The Cloud Services Portal, which is the cloud component of BloxOne DDI, is always the primary DNS server; by contrast, all BloxOne DNS servers are hosts with the DNS service enabled and are secondary DNS servers.
The diagram below illustrates how DDNS updates work in BloxOne DDI:
BloxOne DHCP initiates a DDNS update after providing a lease to a DHCP client according to the MNAME lookup.
To process the update, the host forwards the update to the Cloud Services Portal, which is the primary server.
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 BloxOne DDI:
The MNAME defaults to ns.b1ddi.<zone_name>, but this can be overridden through the Cloud Services 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.
BloxOne DDI does not provide a stealth option for NS records.
When the Cloud Services Portal is down or loses connectivity with the host, the updates are queued to be sent to the cloud when the Cloud Services Portal is back online. If the DDNS service is restarted on the host, the queue is lost. The host 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 BloxOne 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.