Subzone grants

Overview

Edge DNS allows the creation and management of zones (e.g. primary, secondary). During zone creation the API prevents conflicts with other EdgeDNS and GTM zones, unauthorized updates, business rules and much more.

This validation prevents the creation of a sub-zone if the customer doesn’t have access to the parent zone.
The initial customer request details the EdgeDNS requirement, which provides a mechanism for a parent zone owner (grantor) to securely allow any other Akamai customer (grantee) the ability to create a sub-zone regardless of current grantee’s permission set.

Terminology

Grantor - The Control Center user/account with AUTHDNS_CONFIG_EDIT scope on the zone that will be subzoned (e.g. cloud.company.com)
Grantee - The Control Center user/account who will utilize the subzone grant request to create a subzone
Alternate Approver - The Control Center user/account that can approve Grants for a specific list of subzones.
Subzone Grant Request - An authorization request from Grantee to Grantor for the expressed purpose of creating a subzone. The request is also used for audit and traceability purposes since requests can be created from other active requests
Subzone Grant - An approved subzone grant request.

Subzone vs Zone

Ideally a subzone should behave exactly like any other Zone on EdgeDNS and aside from a few exceptions:

• Without an approved subzone grant request, every subzone will start in the state “PENDING_APPROVAL”.
  MCL’s incremental and full scans will ignore zones in PENDING_APPROVAL (CR 4570365)
  Edge DNS Portal Ground Truth API should exclude PENDING_APPROVAL zones (RESOLVE-339)
• Customers can not enable Subzoning for their subzones until the grant request has been approved.
• With an approved subzone grant request, the subzone will start in the state of PENDING just like a regular zone, but the API will also create an automatic and approved subzone grant request for audit/traceability.
• At any point a grantor may reject a Subzone Grant request. Since a grant request may be rejected before or after an approval, the impact of a rejected grant varies.
  • Grant/Approved Subzone Grant Request → Revocation:
    Descendants of the subzones will be recursively marked for Deletion to be picked up by MCL using the active deletion workf
  • Pending Grant Request → Rejection:
    The subzone will be deleted from ADNS. Since zones in the Zone activation state of PENDING_APPROVAL can not enable subzoning. There is no potential need for finding descendants.

This distinction allows the grantee to start building up their records, or upload their zone files etc while they wait for the grantor to approve the request.

The grantor will receive an in app notification to approve or reject the subzone grant request. If approved the child zone will be moved into a pending state, if it exists. If rejected, the sub zone will be marked for deletion, again if it exists.

If a subzone is disabled by the Grantor after subzone grant requests are approved, no changes will be made to any subzones but all future requests will be rejected by our subzone validation.

Subzone Grant Requests

A subzone grant request creates an authorization exception allowing a grantee to create a subzone that would otherwise collide with an existing zone the grantee doesn’t have write access to. Every request must be authorized by a grantor or be based on a prior grant. This allows the API to trace each and every zone that was created back to it’s parent request and so on across all accounts. This traceability is a key requirement of the rejection workflow.

Subzone grant requests require active requests or for the Grantor to enable “subzoning”. This enables the grantor to opt-in or out of the Subzone Grant Request workflow and allows the Grantor to approve or reject the proposed subzone.

Given the hierarchical nature of DNS and the grantee initiated flow there is some ambiguity since the parent zone for a subzone named containers.cloud.company.com could be cloud.company.com or company.com.
Since SWANS uses the longest-match approach instead of following delegations the API finds the closest parent and checks for an authorized subzone grant request. In the example above, the grant goes to cloud.company.com.

Request state transitions