What's New in v9.6.0 - BlueCat Integrity - 9.6.0

Scheduled deployments

The v9.6.0 RESTful v2 API introduces support for the configuration of scheduled deployments. Deployment schedules can be created by sending POST requests to the /api/v2/configurations/{collectionId}/schedules endpoint. After creation, deployment schedules can be read and updated by sending GET/PUT requests to /api/v2/schedules/{collectionId}. To add/remove servers and server groups to/from deployment schedules, users can send POST/DELETE requests to /api/v2/schedules/{collectionId}/servers, /api/v2/schedules/{collectionId}/serverGroups, /api/v2/servers/{collectionId}/schedules, and /api/v2/serverGroups/{collectionId}/schedules.

Address Manager service configuration

Database backups

The v9.6.0 RESTful v2 API introduces the /api/v2/databases/{collectionId}/backups endpoint to support manual and scheduled backups of the Address Manager database.

CSV resource imports

The v9.6.0 RESTful v2 API introduces support for the import of IPv4/IPv6 blocks, IPv4/IPv6 networks, IPv4/IPv6 addresses, zones, and resource records in CSV format using the /api/v2/blocks/{collectionId}/imports (block and network imports), /api/v2/networks/{collectionId}/imports (address imports), /api/v2/views/{collectionId}/imports (zone imports), and /api/v2/zones/{collectionId}/imports (resource record imports) endpoints.

DNS/DHCP Server file retrieval

New in the v9.6.0 RESTful v2 API, users can retrieve files located in the /home/bluecat/preserved_scripts folder on DNS/DHCP Servers by sending GET requests to the /api/v2/servers/{collectionId}/files endpoint.

Address Manager v9.6.0 feature support

HTTPS, SVCB, and URI resource records

Resource record endpoints now support HTTPSRecord, SVCBRecord, and URIRecord resources for configuration of HTTPS, SVCB, and URI resource records.

Dynamic update of DHCP reserved IPv4 addresses

The dynamicUpdateEnabled field has been added to IPv4Network resources to support configuration of the dynamic update of DHCP reserved IPv4 addresses feature.

EDNS Client Subnet Options

EDNS Client Subnet (ECS) DNS deployment options are now supported for deployment options endpoints. ECS option definitions can be retrieved from the /api/v2/deploymentOptionDefinitions endpoint. For full details on ECS options that have been added in Address Manager v9.6.0, refer to Reference: DNS deployment options in the Address Manager Administration Guide.

Multi-primary zones

The multiPrimary field has been added to ServerGroup resources to denote a multi-primary server group that supports the configuration of multi-primary DNS zones.

Additionally, the MULTI_PRIMARY and HIDDEN_MULTI_PRIMARY roles have been added as new roleTypes values of DeploymentRoles, and can be applied to a multi-primary server group.

Server patch management

The v9.6.0 RESTful v2 API introduces the /api/v2/patches endpoint for uploading, retrieving, and deleting DNS/DHCP Server patches and hotfixes.

Notification groups

New in the v9.6.0 RESTful v2 API, users can configure and manage notification groups for Address Manager events using the /api/v2/notificationGroups endpoint.

Linked resources

New in the v9.6.0 RESTful v2 API, the /api/v2/userDefinedLinkDefinitions/{collectionId}/linkedResources endpoint can be used to retrieve a collection of all linked resources within a user-defined link definition.

System, database, and server Logs

The v9.6.0 RESTful v2 API introduces support for retrieving Address Manager system logs using the /api/v2/logs endpoint, as well as database logs (/api/v2/databases/{collectionId}/logs) and DNS/DHCP Server logs (/api/v2/server/{collectionId}/logs).

Administrative access rights

The AdministrativeAccessRight resource has been added to the /api/v2/accessRights endpoint to support the configuration of administrative access rights for users and groups.

X.509 authentication

The X509Authenticator resource has been added to the /api/v2/authenticators endpoint to support the configuration of X.509 authentication for Address Manager.

DHCP Alerts

The DHCPAlertSettings resource has been added to the /api/v2/settings endpoint to support the configuration of Address Manager DHCP alerts.

Secure access

The WebAccessSettings resource has been added to the /api/v2/settings endpoint to support the configuration of Address Manager HTTP and HTTPS access.

Alias records

The dependentRecords field is now supported for HostRecord POST request bodies, allowing users to provide a list of alias records when creating host records.

Workflow requests

New in v9.6.0, RESTful v2 API endpoints that support workflow change requests will return WorkflowRequest resources and HTTP Status 202 to the user creating the workflow request, rather than partial resource representations of the pending object as implemented in 9.5.x. To better align with transaction Operation resources, the fieldUpdates field has been added to WorkflowRequest resources to indicate fields affected by the workflow request. In addition, the /api/v2/workflowRequests/{collectionId}/resourceRecords and /api/v2/workflowRequests/{collectionId}/zones endpoints have been added to support the creation and retrieval of nested resource record and sub zone requests (requests for resource records and zones within pending zones).

Extended v1 API Coverage

To cover the functionality of GET /v1/getAllUsedLocations, the following query can now be used on the locations endpoint: GET /locations?filter=count(_embedded.annotatedResources):gt(0).

The POST /Services/REST/v1/addBulkHostRecord method is now covered by the /api/v2/networks/{collectionId}/imports endpoint.

Server profiles

The following EOL server profiles have been replaced with a new catch-all profile type for legacy appliances named LEGACY: ADONIS_800, ADONIS_1200, ADONIS_1900, ADONIS_1950, ADONIS_XMB2.

To support the new cloud DNS backend provider for the BlueCat Cloud DNS service (formerly known as "BlueCat External DNS Hosted Services"), the AFILIAS_DNS_SERVER server profile has been replaced with the CLOUD_DNS_SERVER profile.

New HTTP headers

New filterable and orderable fields

Operation resources: id, resourceType and operationType are now supported as filterable fields.

MACAddress resources: macPool.id and macPool.name are now supported as filterable fields.

UserDefinedLink resources: name and linkDefinition are now supported as filterable fields.

WorkflowRequest resources: id, state, requestType, creationDateTime, comment, modificationDateTime, creator.id, creator.name, modifier.id, and modifier.name are now supported as filterable fields.

Deployment resources: method, state, status, and message are now supported as filterable fields.

Resource record resources: name, absoluteName, and linkedRecord.id are now supported as filterable fields.

MACPool resources: instantDeplyomentEnabled is now supported as an orderable field.

UserDefinedFieldDefinition resources: name, displayName, resourceType, dataType, defaultValue, and required are now supported as orderable fields.

OpenAPI/Swagger documentation restructuring

Many endpoint paths have been re-structured in the v9.6.0 RESTful v2 API OAS3 document and Swagger documentation for ease of use. The majority of v9.5 endpoints where a collection type is specified in the path are now represented with distinct type-specific endpoints for each available collection type option. For example, the /api/v2/{collection}/{collectionId}/addresses endpoint used to retrieve addresses associated with clientIdentifiers, devices, macAddresses, networks, and resourceRecords has been replaced with distinct endpoints for each type, i.e. /api/v2/clientIdentifiers/{collectionId}/addresses, /api/v2/devices/{collectionId}/addresses, etc.

Redacted fields

The RESTful v2 API redacts certain fields such as passphrases and secrets in resource representations for API security. New in the v9.6.0 RESTful v2 API, resources with fields that have been redacted will contain a _redactedFields field listing the redacted fields. The privateKey fields for KeySigningKey, ZoneSigningKey, and WebAccessSettings resources, and the key field in the LicenseService resource can be unredacted by using the new x-bcn-redact-fields HTTP header with a value of false. Other redacted fields containing passphrases and secrets cannot be unredacted using this header.

Authentication hardening

Starting in v9.6.0, the RESTful v2 API will no longer allow the Legacy v1 API BAMAuthToken to be used for RESTful v2 API authentication. Similarly, the Legacy v1 API will no longer allow the apiToken and basicAuthenticationCredentials values returned from the /api/v2/sessions endpoint to be used for Legacy v1 API authentication. In addition, the RESTful v2 API will no longer allow authentication using the apiToken value alone i.e. Authorization: Basic {apiToken}. The value provided for RESTful v2 API authentication must be the base64 encoding of the requester's username and API token, delimited by a colon (this encoded value is returned from the /api/v2/sessions endpoint as basicAuthenticationCredentials). The following is a valid Authorization header for the v9.6.0 RESTful v2 API: Authorization: Basic {basicAuthenticationCredentials}. For more information, refer to Basic authentication.

Pagination query parameter maximum value

New in the v9.6.0 RESTful v2 API, the maximum value for the limit query parameter can be increased to return more than 100,000 resources. To increase the maximum value for limit, please contact BlueCat Customer Care for assistance.

Address Manager v9.6.0 changes in behaviour

Support for splitting /31 networks

The introduction of DHCP support for /31 networks in Address Manager v9.5.0 removed the ability to perform merge, resize, and split operations involving /31 networks. The 9.5.1 Patch for Address Manager restored this functionality, allowing users to merge /31 networks, resize networks to and from /31, and split larger networks into a set of /31 networks. Address Manager v9.6.0 additionally restores the ability to split /31 networks into /32 networks.

Change in Behaviour for IPv4 Block Merge Operations

Starting in Address Manager v9.6.0, merging a child IPv4 block into a parent block will delete all deployment options and roles explicitly assigned to the child block. Deployment options and roles configured on the child block will not be transferred to the parent IPv4 block.

Change in Behaviour for Host Record IP Address Updates

{
  "name": "example",
  "type": "HostRecord",
  "reverseRecord": true,
  "addresses": [
    {
      "address": "10.0.0.5",
      "type": "IPv4Address"
    }
  ]
}