This section explains the AWS multi availablity zone support for custom DNS.

Infoblox DNS Profile supports adding multiple records for virtual services defined across AWS AZs and also requires State-Based Registration to maintain HA. This can be achieved by:

  • Custom DNS - Multi-VIP and Multi-FQDN support

  • Control Script – Operational state-based DNS registration

Custom IPAM/ DNS Profile

NSX Advanced Load Balancer can utilize Custom IPAM/ DNS scripts through the Custom IPAM/ DNS profile feature to integrate with any API-driven third-party IPAM/ DNS providers. Custom IPAM/ DNS offers increased flexibility by being entirely driven by user-customizable scripts.

The creation of a new virtual service will use the Custom IPAM/ DNS profile and script to automatically create IPAM/ DNS records with the IPAM/ DNS provider.

For more information, see Custom DNS Profile on NSX Advanced Load Balancer.

Custom DNS Script

Custom DNS script for Infoblox DNS provider supports the following functionality:

  1. Multi-VIP functionality

  2. Multi-FQDN functionality

  3. All virtual service types, such as V4, V6, and V4_V6 types

Note:

Custom DNS profile scripts written before this version, are still supported. However, you must use the latest version of the script to leverage the newly added features.

The script must have all the required functions and exception classes defined; else, the system will display the following error message during DNS profile creation:

“Custom DNS profile script is missing required functions/exception classes {function_or_exception_names}.”

The custom DNS script for Multi-VIP and Multi FQDN Support is as follows:

/opt/avi/sdk/python/avi/sdk/samples/custom_dns_script_infoblox.py

The following are the required functions for the newer version of the script:

  • CreateOrUpdateDnsRecords

  • DeleteDnsRecords

The following are the required exception classes for the newer version of the script:

  1. CustomDnsAuthenticationErrorException

  2. CustomDnsRecordNotFoundException

  3. CustomDnsRecordAlreadyExistsException

  4. CustomDnsGeneralException

It is recommended to use logger_name (of auth_params) for script logging. Tenant-specific debug log files are created to save the log statements from the script.

  • For admin tenant — /var/lib/avi/log/custom_dns_script.log

  • For non admin tenant — /var/lib/avi/log/custom_dns_script_<tenant_name>.log

NSX Advanced Load Balancer logs for the Custom DNS profile can be found in this location: /opt/avi/log/portal-webapp.log.

Custom DNS Workflow

The following is the custom DNS workflow:

  1. Create a script object.

    1. Navigate to Templates > Custom IPAM/DNS, click Create and upload a python script which provides functions for CRUD to the DNS provider.



    2. Add the required Script Params. For instance, username, password, API version, provider server address.

  2. Create DNS profile.

    1. Navigate to Templates > IPAM/DNS Profiles, click Create.



    2. Create a DNS profile of type Custom DNS.

    3. Attach the script object created in the Step 1.

    4. Add usable_domain.

  3. Attach DNS profile to the cloud.



Control Script for State-based DNS Registration

Control scripts are initiated by Alert Actions, which are triggered by Events within the system.

A python script that defines functions to register or de-register DNS records based on the VIP operation status.

Note:

Update get_auth_params() function with valid provider-specific authentication parameters.

The control script for state-based DNS registration is as follows:

/opt/avi/sdk/python/avi/sdk/samples/operstate_controlscript_infoblox.py



The control script for Infoblox defines the following functions:

register_dns_records:

Registers DNS records for the VIP when the VIP_UP alert is triggered.

deregister_dns_records:

De-registers DNS records for the VIP when the VIP_DOWN alert is triggered.

Cloud Level Isolation for Control Script:

The default behavior of the control script is that it gets called for all virtual services defined across all the clouds.

To use a control script for a specific cloud, where the Custom DNS profile is attached, as a workaround, you can set the variable cloud_uuid defined in the control script with the specific cloud UUID as shown below:

cloud_uuid = <cloud_uuid>

For instance,

cloud_uuid = "cloud-5581b2a1-222f-4b0e-b657-2d9668091f29"

By default, cloud_uuid is None.

You can get cloud UUID through the following ways:

  1. CLI - show_cloud

  2. REST API - /api/cloud

Note:

There is a known delay of 90 second plus the processing time between an event generation and an alert trigger.

Control Script Workflow

The following is the workflow for the Control Script:

  1. Upload control script

    1. Navigate to Templates > Scripts > ControlScripts and click Create to upload the script.



  2. Set Alert Options

    1. Navigate to Operation > Alert Actions and click Create.

    2. Under the Control Script field, choose the script object created in Step 1.



  3. Set Alert Config.

    1. Navigate to Operations > Alert Config and click Create.

    2. Provide the following details:

      1. Provide the Name of the alert configuration, for instance, operstate_customdns_ib_vip_down.

      2. Set Throttle Alert (default is 600 seconds) to 0. The value zero indicates that there is no time-based throttling. The alert may only be triggered once within the specified time frame.

      3. Set Event Occurs to VIP DOWN

      4. Select alert action created in Step 2, under Alert Action.



    3. Repeat this step for the VIP UP event.

Note:

Expect a delay of 90 second before the alert action takes place after the event is generated.

Script Path

To access these files, you can use SSH or SCP to pull them from the Controller.

Script

Workflow

Location

Control script for Multi-VIP and Multi FQDN Support

Custom DNS Workflow

/opt/avi/python/lib/custom_dns/custom_dns_script_infoblox.py

Control Script for State-based DNS registration

Control Script Workflow

/opt/avi/python/lib/custom_dns/operstate_controlscript_infoblox.py
For more information on SSH connections to the Controller, see FAQ accessing NSX Advanced Load Balancer CLI.