Saucepan

User Tools

Site Tools

Trace: • sed
infoblox_nios:ddns

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
infoblox_nios:ddns [2023/12/12 14:41] – [Dynamic DNS] bstaffordinfoblox_nios:ddns [2025/03/05 11:43] (current) – [Dynamic DNS] bstafford
Line 1: Line 1:
 ======= Dynamic DNS ====== ======= Dynamic DNS ======
 +
 +NIOS DDNS Updates are processed by the primary member, synced to GM, GM then pushes to secondaries. If GM is offline, secondaries don't get data. If Secondary if offline, GM will queue until it is back online. For NIOS-X, members proxy DDNS update to cloud, cloud processes change, cloud pushes to all NIOS-X members. Cloud only queues for a few seconds. If NIOS-X host is offline, it won't get the updates.
  
 DHCP can be impacted by separate DNS appliances. DHCP pauses lease issuing until a DDNS update is completed. DHCP can be impacted by separate DNS appliances. DHCP pauses lease issuing until a DDNS update is completed.
Line 6: Line 8:
  
 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 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. 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 [[https://docs.infoblox.com/space/nios90/280762554/Configuring+DHCP+for+DDNS#Defining-the-Default-Primary-for-DDNS-Updates-to-Zones-with-Multiple-Primaries|Defining the Default Primary for DDNS Updates to Zones with Multiple Primaries]].
 +
 +===== TXT Record Handling =====
 +  * **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.
 +
 +===== Hosts =====
 +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)
 +===== Protect Records from DDNS =====
 +Under Data Management > DNS Grid DNS Properties > Updates > Advanced.
 +  * Prevent dynamic updates to RRsets containing static records
 +  * Prevent dynamic updates to RRsets containing protected records
 +
 +
 +
 +===== DNS Update on DHCP Renewal =====
 +For this NIOS option [[infoblox_nios:dhcp#dns_update_on_dhcp_renewal|see here]].
 +
  
 ===== Multi-Master DDNS ===== ===== Multi-Master DDNS =====
Line 13: Line 48:
  
 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 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.
 +
 +===== Domain Controllers =====
 +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.
 +<code>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)</code>
  
 ===== DDNS Update on DHCP Renew===== ===== DDNS Update on DHCP Renew=====
infoblox_nios/ddns.1702392112.txt.gz · Last modified: by bstafford