Conflict Resolution
To provide a measure of protection against unintentional changes of DNS data, the DHCP server can first check the record set to verify that it matches the client that originally inserted the record. This process provides assurance that the updates are from the same client. that originally triggered the creation of the record. These security checks are based upon inserting a cryptographic hash of the client identification (mac address, client id or DUID) into a DNS DHCID record and then verifying that value before updating. You can configure the DHCP server to update records only after passing verification or without any type of verification. When using verification you can adjust the way DHCP handles updates to require more or less stringent verification requirements.
Your specific requirements might benefit from less-stringent verification of the DHCID, or might require skipping verification entirely. Verification checks might cause complications in some specific cases described below:
Mobility: The DHCID is unique to each client and is usually based on the MAC address or DUID of the interface. Devices such as laptops that connect to both wired and wireless networks have different MAC addresses or DUIDs and different DHCID values for each interface. In this scenario, after either one of the network interfaces inserts a DNS record, updates are allowed from that interface only. This results in a disruption of service for DDNS updates when roaming between wired and wireless networks.
Migration: The second problem occurs during migration from non-ISC based systems to ISC systems. For example, if the user is migrating from a Microsoft-based system, the clients have A or AAAA and PTR records in the DDNS updates. As a result, new DDNS updates fail after the migration.
Mixed Environments: The final problem occurs in mixed ISC and non-ISC environments. For example, assume that both Microsoft and ISC DHCP servers update DNS records on the appliance. In a mixed environment, since the Microsoft DHCP server does not insert the DHCID, DDNS updates from ISC-based systems fail while updates from the Microsoft DHCP server are committed into the database.
Universal DDI offers four modes to handle DDNS updates as described in the DDNS Update Verification Mode table :
Mode | If a Record at Lease Grant | Then DHCID Record at Lease Grant | Lease Grant Action | Lease Expire Action |
---|---|---|---|---|
Update DNS if DHCID values match
| Exists | Must match | Delete A or AAAA, DHCID if exists | Delete A or AAAA, DHCID if DHCID matches and no other A or AAAA RRs Delete PTR |
| No A or AAAA record | No check | Add A or AAAA. |
|
Update DNS if DHCID record exists (match not required)
| Exists | Must exist | Delete A or AAAA. | Delete A or AAAA if DHCID exists and no other A or AAAA RRs |
| No A or AAAA record | No check | Add A or AAAA |
|
Update DNS and add or update DHCID records
| Exists | No check | Delete A or AAAA | Delete A or AAAA |
| No A or AAAA record | No check | Add A or AAAA |
|
Update DNS without checking for or creating DHCID records
| Exists | No check | Delete A or AAAA Add A or AAAA Add PTR | Delete A or AAAA |
| No A or AAAA record | No check | Add A or AAAA |
|
If you are migrating from NIOS, the equivalent DDNS update verification modes are as follows:
DHCID Update Mode (Universal DDI) | DDNS Update Method (NIOS) |
---|---|
Update DNS if DHCID values match | Standard ISC |
Update DNS if DHCID record exists (match not required) | Check TXT only |
Update DNS and add or update DHCID records | ISC Transitional |
Update DNS without checking for or creating DHCID records | No TXT record |
If you are migrating from NIOS to Universal DDI, ensure that the DDNS Update Method in NIOS is configured as Standard so that DHCID records are created.