Introduction
This document provides information on Authoritative DNS capacity and performance guidelines to help with system sizing for 64-bit Cisco Prime Network Registrar 8.3.5.4 and later.
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This appendix contains the following sections:
This document provides information on Authoritative DNS capacity and performance guidelines to help with system sizing for 64-bit Cisco Prime Network Registrar 8.3.5.4 and later.
Note |
DNSSEC enabled zones (CPNR 9.1 and later versions) will include auto-generated RRs that significantly increase the number of RRs in the zone. |
Maximum of 25 million RRs per Authoritative DNS server (primary, HA pair or secondary server), ideally not to exceed 2 million RRs per zone. Multiple DNS primary servers can be used for deployments requiring more RRs.
Maximum of 10000 zones per Authoritative DNS server (primary, HA pair or secondary server). Multiple DNS primary servers can be used for deployments requiring more zones.
Maximum of 4 secondary servers per primary or HA pair.
Maximum of 2 tiers of secondary servers (first tier secondaries and second tier secondaries).
Maximum of 2 second tier secondary servers per first tier secondary server.
The Authoritative DNS Servers utilize a combination of in-memory cache and on-disk databases to store and maintain authoritative RR data. For sizing purpose, assume an each RR requires 300 bytes of memory for the RR cache and 300 bytes of disk space for the RR DB. The CSET DB has a higher disk space requirement for each RR since it records changes to the RR set, but those changes are capped to the number of history changes kept per zone.
Database that stores all RRs (protected and unprotected) for the zones configured on a DNS server.
On primary DNS servers, RR data edits are written to the RR DB either through administrative actions (i.e. RR adds) or DNS updates and zone scavenging. On secondaries, the RR DB is written through zone transfers.
The RR DB is required for all ADNS servers (primary/secondary).
Increases query performance by storing a subset of the RR DB data (stores entire name sets).
Most active RR data is stored to RR cache dynamically as part of RR DB lookups generated by DNS query processing.
The memory foot print of the RR Cache is capped by a configurable DNS server setting (mem-cache-size). When the maximum cache size has been reached, the DNS server will remove older entries from the cache to make room for newer entries. Each RR requires approximately 300 bytes of memory.
DNS server reloads/restarts causes the RR cache to be deleted. When the server starts up again, it is rebuilt based on query traffic.The RR cache is required for all ADNS servers (primary/secondary).
The RR cache is required for all ADNS servers (primary/secondary).
Database that stores RR changes (adds, deletes, protection changes, refreshes) needed to respond to the incremental zone transfer requests (IXFRs).
RR changes are first stored in the RR DB and then persisted to the CSET DB.
For DNS servers that do not need to service incremental zone transfers (i.e. secondaries that do not send outbound IXFRs), server performance can be increased by disabling persisted change sets (csetdb-persist-csets). By default, changes are automatically persisted to the CSET DB.
DNS maintains only a limited configurable number of changes (csetdb-htrim-max-cset-kept) and automatically trims entries when the maximum has been reached. Trimming helps limit the database size. For deployments with DNS updates, it is recommended that the number of changes kept is increased to avoid full zone transfers.
If the CSET DB is deleted, the DNS server will create an empty database and respond with full zone transfers (AXFRs) until new zone history data is populated into the database.
Database that stores state information about the DNS HA pair as well as data about RR changes during a communications interrupted or partner down event.
Only applicable on primary HA DNS servers (main and backup).
If the HA DB is deleted, HA synchronization causes all zone data to be pushed from the HA main to the HA backup.
A CNR DNS deployment can be categorized as small, medium or large depending on the number of RRs/zones, DNS update activity and recovery time during an outage or update. The number of zones can have an impact on the size of the deployment, primarily the number of RRs is the deciding factor. Also, if the DNS deployment requires a large number of RRs/zones, it is recommend that multiple DNS deployments be used - ideally segregating the data appropriately so that related zones/RRs are configured together.
Note |
To ensure a properly functioning ADNS system, it is important to monitor system disk space and memory. If the ADNS server runs out of memory, it will crash. If it runs out of disk space, it will no longer be able to service requests and the databases may become corrupt and unusable. |
Regional Management of DNS Deployments:
The Regional Server provides license management of all CPNR local clusters, and allows for central management and replication of Cisco Network Registrar DNS deployments. Follow the below recommendations for system sizing and configuration adjustments to be made when using Regional DNS cluster management.
A minimum of 4 CPUs.
A minimum of 8 GB of RAM.
Disk space should be at minimum an aggregate of the disk size of all the managed DNS (main) primary clusters.
On large DNS deployments, replication of unprotected RRs should be disabled (poll-replica-rrs).
Small Deployment:
1-1000 RRs, 1-100 zones.
Mainly static data; zone edits are primarily done by administrators.
Typically consists of one primary and a secondary server.
DNS Caching server is not required or can be handled by hybrid mode.
DNS can be recovered from a shadow backup within a matter of minutes with little to no impact on production.
A minimum of 2 CPUs.
A minimum of 4 GB of RAM.
A minimum of 10 GB of disk space.
Medium Deployment:
1000-100,000 RRs, 100-1000 zones.
A pretty even mix of static and dynamic data; 100 updates per second or less.
Typically consists of one primary and two to four secondaries.
Typically consists of two to four DNS Caching Servers. DNS Caching Servers must be deployed on separate machines or VMs.
DNS can be recovered from a shadow backup within an hour with minimal impact to production.
A minimum of 4 CPUs.
A minimum of 8 GB of RAM.
A minimum of 25 GB of disk space. On the primaries, the number of change sets kept (csetdb-htrim-max-cset-kept) should be increased. The value will depend on how many DNS updates are handled by the system, but should be between 1000 and 5000.
Large Deployment:
100,000-25,000,000 RRs, 1000-10,000 zones.
Dynamic data makes up a larger percentage of the data; thousands of updates per second.
Typically consists of two primaries (DNS HA pair) and four secondaries.
Typically consists of four or more DNS Caching Servers.
DNS recovery is complex and must be done during a maintenance window; DNS servers can take an hour or more to recover from a shadow backup.
A minimum of 8 CPUs.
A minimum of 16 GB of RAM. The DNS RR cache memory size (mem-cache-size) should be increased (approximately 300 bytes per RR but not to exceed 2,000,000 KB).
A minimum of 100 GB of disk space. On the primaries, the number of change sets kept (csetdb-htrim-max-cset-kept) should be increased. The value will depend on how many DNS updates are handled by the system, but should be between 5000 and 10,000.