Page tree

Contents

The DHCP server can send dynamic updates to an external primary server that you specify. For each IP space, you can specify the zone to be updated and the IP address of the primary server for that zone. You can add information for a forward and reverse zone. By default, the reverse zone is empty, which causes the server to ignore the reverse update portions of a request. The DHCP server updates the A record in the forward zone and the PTR record in the reverse zone. During lease reclamation, which is the process through which an expired lease becomes available for assignment to the same or a different client, any DNS entries associated with the expired lease are removed. You can also use keys to secure communications between the servers. Both the DHCP server sending the update and the DNS server receiving it must share the same secret key.

You can enable the DHCP server to send DDNS updates for IPv4 clients at the DHCP global and DHCP server levels. You can specify a different domain name that the application uses specifically for DDNS updates. It combines the hostname from the client and the domain name you specify to create the FQDN that it uses to update DNS. For IPv4 clients, you can specify the DDNS domain name at the DHCP global and server levels.

To enable DDNS, complete the following:

  • From the Cloud Services Portal, click Manage -> IPAM/DHCP -> Global DHCP Configuration.

  • On the Global DHCP Configuration page, click DDNS and complete the following:

    • Enable DDNS Updates: Select this check box to enable DDNS updates. DDNS (Dynamic DNS) is a method to update DNS data (A, TXT, and PTR records) from sources such as DHCP servers and other systems that support DDNS updates.

    • Send DDNS Updates: Select this checkbox to send DDNS updates to external systems that support DDNS updates. 
    • Default DDNS Domain Name: Specify the domain name of the network that the application uses to update DNS. For IPv4 clients, you can specify this at the DHCP global and DHCP server levels.

    • DDNS ZONES: Select the DDNS zones from the column selector. 

    • Add External Zone: Choose this option to add an external zone for sending DDNS requests from the DHCP server to an external server. For example, you can configure another DNS server like NIOS to perform the role of an external primary server. Configure the following options for the external zone:
      • Zone: Enter the FQDN of a valid forward-mapping or reverse-mapping zone to which the DHCP server sends the updates.  
      • DNS Server: Enter the IP address of the external primary server for that zone.
        • Use TSIG: Select this check box to use the standards-based TSIG key that uses the one-way hash function to secure transfers between name servers. For more information, see Configuring TSIG Keys.


    • Add Internal Zone: Choose this option to add an internal zone for sending DDNS requests from DHCP Server to primary zones in BloxOne DDI. Consequently, the resource records are updated in the primary zones. Configure the following options and click Add to add an internal zone:
      • DNS ViewChoose a DNS View from the column selector. For more information, see Configuring DNS Views.
      • DNS ZoneChoose a zone from the column selector. For more information, see Configuring DNS zones
      • DDNS Zone: Select the DDNS zones from the column selector. 
    • Generate hostname if not sent by client: Select this check box to enable the DHCP server to generate a hostname and update DNS with this hostname, when the DHCP request of a client does not include a hostname. For more information, see 54136047.
    • Default DDNS Prefix:  Specify the default DDNS prefix. 
    • Update DNS records on DHCP lease renewals: Select this check box to update the DNS records when the DHCP lease is renewed. The new IP address generated with the new lease gets updated in the DNS record. The DNS record is updated even if the DNS information for the lease (for example, the FQDN or the flag for updating the DNS direction) has not changed. The DHCP server self-heals if it was previously unable to add DNS entries or if the DNS server has lost them. This scenario is applicable only to lease renewals. The check box is not selected by default.
    • Use Conflict Resolution: Conflicts occur when more than one DHCP client attempts to associate with a single FQDN. Select the check box to apply conflict resolution and to ensure that the DNS record's information associated with one DHCP client is not updated by other DHCP clients. The check box is selected by default.
    • CLIENT FQDN HANDLING (OPTION 81)
      • DHCP server overrides client's preference to do update itself and DHCP server performs updateChoose this option to allow the DHCP server to perform an update even if the client's preference is to perform the update. 
      • DHCP server overrides client's preference not to perform updates: Choose this option to allow the DHCP server to override client's preference not to perform an update. 
      • Remove suffix: Choose this option to remove the suffix from the FQDN (option 81) in the incoming client request. The suffix is removed before checking if the suffix matches the default domain name or any domain names in the zone list. This occurs before Kea appends a qualifying suffix. 
    • HOSTNAME REWRITE POLICY
      • Enable hostname rewrite policy: Select this check box to use a hostname rewrite policy for DHCP leases and DDNS updates for IPv4 DHCP clients. From the drop-down list, select the hostname policy you want to use.
      • Invalid Characters: Enter a list of invalid characters that must be replaced in the host name. Ensure that you consider the following rules:

        • You can include only printable ASCII characters, including space.

        • BloxOne DDI includes period (.) as a valid character for label separators by default.

        • You can also use shortcuts for a series or range of characters. For example, when you enter a-d, the application includes the following: A, B, C, D, a, b, c, and d. When you enter 0-5, the application includes the following: 0, 1, 2, 3, 4, and 5. In a character range, ensure that the start character is less than the end character.

        • If you want to use dash (-) as a character, ensure that you put it in front of the valid character pattern. Otherwise, the application treats the string as a range of characters.

        • You can build a POSIX regular expression based on the string you enter here, but you cannot enter an empty string.

        • You cannot use the meta character (^) as a start or end character in a range. For example, a-^ is invalid. You also cannot use duplicate characters as character sets. For example, aa is invalid.


    Note

    BloxOne DDI supports POSIX regex bracket expressions. For more information, refer to http://pubs.opengroup.org/onlinepubs/9699919799/.  

      • Replace Invalid Characters with: Enter a character BloxOne DDI uses to replace invalid characters. Only enter one printable ASCII character. You can specify only a single replacement character.
  1. Click Save & Close to save the details or click Cancel to exit.

About the Client FQDN Option

When an IPv4 DHCP client sends DHCP DISCOVER and DHCP REQUEST messages, it can include option 81, the Client FQDN option. The Client FQDN option contains the FQDN (fully qualified domain name) of the client and instructions on whether the client or the server performs DDNS updates. You can configure the application to replace the FQDN in the option by defining a hostname rewrite policy. For information about adding and enabling a hostname rewrite policy, see Replacing Host Names for DDNS Updates.

The DHCP server can support option 81 for IPv4 clients, and use the FQDN that the client provides for the update. It can also allow or deny the client’s request to update DNS, according to the administrative policies of your organization. The DHCP server indicates its response in the DHCP OFFER message it sends back to an IPv4 client.

Sending Updates with the FQDN Option Enabled

When you enable the DHCP server to support the FQDN option, it uses the information provided by the IPv4 client to update DNS as follows:

  • When an IPv4 DHCP client sends a DHCP request with the FQDN option, it can include either its FQDN or only its host name.

    • If the request includes the FQDN, the DHCP server uses this FQDN to update DNS. You can specify a list of forward-mapping zones to be updated for IPv4 clients using the FQDN option.
    • If the request includes the host name, the DHCP server provides the domain name. It combines the host name of the client and the domain name to create an FQDN for the client. It then updates DNS with the FQDN it created.  
  • When a DHCP client does not send a host name, the DHCP server provides a lease but does not update DNS.

  • If multiple DHCP clients specify the same FQDN or host name, the DHCP server allocates leases to the clients, but updates DNS only for the client that first sent the request. When it tries to update DNS for the succeeding clients, the update fails.

Sending Updates from DHCP Clients or a DHCP Server

When you enable the DHCP server to support the FQDN option, you must decide if you want the DHCP server to allow clients to update DNS. If you allow the client to update DNS, then the client updates its A record only. The DHCP server always updates the PTR record. You can configure the DHCP server as follows:

  • The DHCP server can allow clients to update DNS when they send the request in the FQDN option. This is useful for small sites where security is not an issue or in sites where clients move from one administrative domain to another and want to maintain the same FQDN regardless of administrative domain.

If you configure the DHCP server to allow clients to perform DDNS updates, you must also configure the DNS server to accept these updates from clients. Note that multiple clients can use the same name, resulting in multiple PTR records for one client name.

When a lease expires, the DHCP server does not delete the A record, if it was added by the client.

  • The DHCP server can refuse the DHCP client’s request to update DNS and always perform the updates itself. When the DHCP server updates DNS, it uses the FQDN provided by the DHCP client. Select this option if your organization requires tighter control over your network and does not allow clients to update their own records.

If you do not enable support for the FQDN option and a client includes it in a DHCP request with its FQDN, the DHCP server does not use the FQDN of the client. Instead, it creates the FQDN by combining the host name from the client with the domain name specified.

Generating Host Names for DDNS Updates

Some IPv4 clients do not send a host name with their DHCP requests. When the DHCP server receives such a request, its default behavior is to provide a lease but not update DNS. You can configure the DHCP server to generate a host name and update DNS with this host name when it receives a DHCP request that does not include a host name. It generates a name in the following format: dhcp-ip_address, where ip_address is the IP address of the lease. For example, if this feature is enabled and the DHCP server receives a DHCP REQUEST from an IPv4 DHCP client with IP address 10.1.1.1 and no host name, the DHCP server generates the name dhcp-10-1-1-1 and appends the domain name, if specified, for the DDNS update.

Replacing Host Names for DDNS Updates

In situations where you need to restrict the use of specific characters in a host name for DDNS updates, you can configure a hostname rewrite policy. Such policy accepts certain characters and replaces others in host names specified in IPv4 DHCP requests. When you create a hostname rewrite policy, you enter a regular expression matching invalid characters that the application replaces in the host name. You also specify a character that the application uses to replace invalid characters.

When you enable a hostname rewrite policy, the application replaces host names with the newly translated host name when it issues DHCP leases and sends DDNS updates for IPv4 DHCP clients. Before you enable a hostname rewrite policy, consider the following:

  • You must enable DDNS updates before the hostname rewrite policy can take effect.

  • The policy supports only IPv4 DHCP clients.

  • If DHCP option 81 support is enabled and updating DDNS is in the request, the application sends updates for A records directly to the DNS server and DHCP only updates the PTR record. When this happens, there can be a mismatch in the host name between the A and PTR records.

  • Changes made to a hostname rewrite policy apply only to subsequent DDNS updates.

When an IPv4 DHCP client requests an IP address, it includes its host name in DHCP option 12. If you enable a hostname rewrite policy, the application uses the newly translated host name when it issues a lease to the client.

The client can also include a FQDN in option 81, in which it instructs the server whether to perform DDNS updates. If the client sends a FQDN in option 81, the application replaces the entire FQDN based on the policy. For example, if the FQDN in option 81 is dev.bldg12.corpxyz.com, the application replaces invalid characters in the entire FQDN even though the host name can be dev or dev.bldg12. For example, if your hostname rewrite policy specifies valid characters as a-z and the replacement character is -, the newly translated FQDN is dev.bldg--.corpxyz.com. For information about client FQDN in option 81, see 54136047.

Note that when multiple IPv4 DHCP clients specify host names that map to the same translated host name, the application allocates leases to all clients, but it only sends DDNS updates to the first client request. When it tries to update DNS for subsequent clients, the updates fail. You can override this policy at the DNS server level.


  • No labels

This page has no comments.