You can grant roles and admin groups read-only or read/write permission, or deny access to the following DNS resources:

• DNS Views
• DNS Zones
• Response Policy Zones
• All RPZ Rules
• Hosts
• Bulk Hosts
• A records
• AAAA records
• CNAME records
• DNAME records
• MX records
• PTR records
• SRV records
• TXT records
• Hosts
• Bulk Hosts
• Shared Record Groups
• Shared A records
• Shared AAAA records
• Shared CNAME records
• Shared MX records
• Shared SRV records
• Shared TXT records
• DNS64 synthesis groups
• Adding a blank A/AAAA record

The appliance applies permissions for DNS resources hierarchically. Permissions to a DNS view apply to all zones and resource records in that view. Permissions for a zone apply to all its subzones and resource records, and resource record permissions apply to those resource records only. To override permissions set at higher level, you must define permissions at a more specific level. To assign permissions, see Applying Permissions and Managing Overlaps.
You can also define permissions for specific DNS objects and Grid member to restrict admins to perform only the specified DNS tasks on the specified member. For more information, see Defining DNS and DHCP Permissions on Grid Members.
The following sections describe the different types of permissions that you can set for DNS resources:

• 22282417
• 22282417
• 22282417

Administrative Permissions for DNS View s
Limited-access admin groups can access DNS views, including the default view, only if their administrative permissions are defined. Permissions to a DNS view apply to all its zones and resource records. To override view-level permissions, you must define permissions for its zones and resource records. For example, you can grant an admin group read-only permission to a view and read/write permission to all its zones. This allows the admins to display the view properties, but not edit them, and to create, edit and delete zones in the view.
You can grant read-only or read/write permission, or deny access to DNS views, as follows:

• All views—Global permission that applies to all DNS views in the database.
• A specific view—Applies to its properties and its zones, if you do not define zone-level permissions. This overrides the global view permissions.
• All zones in a view—If you do not define permissions for zones, they inherit the permissions of the view they are in.

For information on setting permissions for a view and its zones, see Applying Permissions and Managing Overlaps.
The following table lists the tasks admins can perform and the required permissions for DNS views.

Table 4.13 Permissions for DNS Views

Administrative Permissions for Zone s
By default, zones inherit administrative permissions from the DNS view in which they reside. You can override view-level permissions by setting permissions for specific zones. Permissions set for a zone are inherited by its subzones and resource records. To override zone-level permissions, set permissions for specific subzones and resource records.
For example, you can grant an admin group the following permissions:

• Read-only to a zone and to all its A, AAAA, and PTR records (in reverse and forward-mapping zones)
• Read/Write permission to all MX and SRV records in the zone
• Deny to all the other resource records—CNAME, DNAME, TXT, host, and bulk host You can grant read-only or read/write permission, or deny access to zones as follows:
• All zones —Global permission that applies to all zones in all views.
• All zones in a view—Permissions at this level override the global permissions.
• A specific zone—Applies to the zone properties and resource records, if you do not define permissions for its resource records. This overrides global and view-level permissions. If you delete a zone and reparent its subzone, the subzone inherits the permissions of the new parent zone.
• All Response Policy Zones—Global permission that applies to all the Response Policy Zones.
• All Response Policy Rules—Global permission that applies to all the local Response Policy Zone rules.

Note: Object permissions are not applicable to Response Policy Zone rules.

• Each resource record type in a zone—For example, you can define permissions for all A records and for all PTR records in a zone. if you do not define permissions for resource records, they inherit the permissions of the zone in which they reside.

For information on setting permissions for zones and resource records, see Applying Permissions and Managing Overlaps.
The following table lists the tasks admins can perform and the required permissions for zones.

Table 4.14 DNS Zone Permissions

Administrative Permissions for Resource Records

Resource records inherit the permissions of the zone to which they belong. You can override zone-level permissions by setting permissions for specific resource records.
You can grant read-only or read/write permission, or deny access to resource records as follows:

• Each resource record type in all zones and in all views—Global permission that applies to all resource records of the specified type; for example, all A records in the database.
• Each resource record type in a zone— Permissions at this level override global permissions.
• A specific resource record—Overrides zone-level permissions.

For information on setting permissions for resource records, see Applying Permissions and Managing Overlaps. The following table lists the tasks admins can perform and the required permissions for resource records.

Table 4.15 DNS Resources

The following are additional guidelines:

• Only admins with read/write permission to bulk host records and read/write permission to reverse zones can create bulk host records and automatically add reverse-mapping zones.
• To create host records, admins must have read/write permission to the network and zone of the host.
• Admins must have read-only permission to the host records in a zone to view the Host Name Compliance Report. Admins must have read/write permission to the resource records in a zone to modify host names that do not comply with the host policy.

Administrative Permissions for Adding Blank A or AAAA Records

By default, only superusers can add and edit A, AAAA, shared A, and shared AAAA records with a blank name. Limited-access admin groups can add and edit A, AAAA, shared A, and shared AAAA records with a blank name, only if their administrative permissions are defined. You can grant read/write or deny permission to Adding a blank A/AAAA record for specific admin groups, which applies to all admin roles in the group. You can define global permissions for specific admin groups and roles to allow limited-access users to add and edit blank A, AAAA, shared A, and shared AAAA records, as described in Defining Global Permissions.

Administrative Permissions for Shared Record Group s

By default, only superusers can add, edit, and delete shared record groups. Limited-access admin groups can access shared record groups, only if their administrative permissions are defined.
You can set different permissions for a shared record group and for each type of shared resource record in the group. For example, you can grant a role or an admin group the following permissions:

• Read-only to a shared record group and to all its shared A, AAAA, and CNAME records
• Read/Write permission to all the shared MX and SRV records in the shared record group
• Deny to the TXT records

You can grant read-only or read/write permission, or deny access to shared record groups, as follows:

• All shared record groups—Global permission that applies to all shared record groups in the database.
• A specific shared record group—Overrides global permissions.
• Each shared record type in all shared record groups — The shared resource record types include shared A records, shared AAAA records, shared CNAME records, shared MX records, shared SRV records, and shared TXT resource records.
• Each shared record type in a shared record group— Permissions at this level override global permissions.
• A specific shared record—Overrides zone-level permissions. Note the following guidelines:
• Shared record group permissions override zone permissions.
• Even if a zone is locked, superusers and limited-access users with read/write access can still edit or delete a shared record in the zone.

For information on setting permissions for shared record groups, see Applying Permissions and Managing Overlaps. The following table lists the tasks admins can perform and the required permissions for shared record groups.

Table 4.16 Permissions for Shared Record Groups

Administrative Permissions for DNS64 Synthesis Groups

By default, only superusers can add, edit, and delete DNS64 synthesis groups. Limited-access admin groups can access synthesis groups, only if their administrative permissions are defined.
You can grant read-only or read/write permission, or deny access to synthesis groups, as follows:

• All synthesis groups—Global permission that applies to all shared record groups in the database.
• A specific synthesis group—Overrides global permissions.

For information on setting permissions for synthesis groups, see Applying Permissions and Managing Overlaps. The following table lists the tasks admins can perform and the required permissions for synthesis groups.

Table 4.17 Permissions for DNS64 Synthesis Groups