Primary and secondary zones

A DNS zone is a distinct portion or administrative space in the DNS domain namespace that is hosted by a DNS server. DNS zones allow the DNS namespace to be divided up for administration and redundancy. The DNS server can be authoritative for multiple DNS zones.

All of the information for a zone is stored in a DNS zone file, which contains the DNS database records for all of the names within that zone. These records contain the mapping between an IP address and a DNS name. DNS zone files must always start with a Start of Authority (SOA) record, which contains important administrative information about that zone and about other DNS records.

You can implement Edge DNS as your primary or secondary DNS, either replacing or augmenting your existing DNS infrastructure as desired.

Whether primary or secondary, Edge DNS can provide your organization with a scalable and secure DNS network that helps ensure the best possible experience for your users. The available zone modes are:

• Primary mode. In primary mode, customers manage zones using either ​Akamai Control Center​ or the Edge DNS Zone Management API. The Edge DNS zone transfer agent pushes out your zone data to the Edge DNS name servers and provides you a list of name servers that you can register with your domain registrar.
• Secondary mode. In secondary mode, customers enable DNS zone transfers from their primary name servers to ​Akamai​. Edge DNS name servers use authoritative transfer (AXFR) as the DNS zone transfer method for secondary zones. However, if you configured your own master names servers to support incremental zone transfers (IXFR), the Edge DNS zone transfer agents (ZTAs) will automatically do incremental zone transfer for secondary zones.

In secondary mode, you maintain zone information on your primary (master) name server, and Edge DNS zone ZTAs perform zone transfers from the primary name servers and upload these zones to ​Akamai​ name servers. ZTAs conform to the standard protocols described in RFCs 1034 and 1035 and work with most common primary name servers in use, including Internet Systems Consortium's BIND (version 9 and later), and also Microsoft Windows Server and Microsoft DNS operating systems.

Refresh and retry intervals in the start of authority (SOA) determine the interval between zone transfers. In addition, you can configure the system to accept NOTIFY requests from your primaries to allow almost immediate updates.

ZTAs are deployed in a redundant configuration across multiple physical and network locations throughout the ​Akamai​ network. All ZTAs will attempt to perform zone transfers from your master name servers, but only one (usually the first one that receives an update using one transfer) will send any given zone update to the name servers. This process uses a proprietary fault-tolerant data transfer infrastructure, thus providing a fault-tolerant system at every level.

Cross-account subzone delegation

Cross-account subzone delegation provides a mechanism for a parent zone owner to securely grant another Edge DNS account the capability to delegate subzones on the owner's existing zones. The zone owner participating in subzone grant requests needs to have their Edge DNS contract authorized for subzone grants. Contact your service representative for authorization.

After a service representative adds a zone owner's contract to the allow list, the zone owner can enable subzone delegation on a specified zone. Enabling subzone creation permits any ​Akamai​ customer to submit a subzone request on this zone.

Without an approved subzone grant request, every subzone starts in a PENDING_APPROVAL state. The subzone owner can begin building up records and uploading zone files while they wait for approval of their request from the zone owner. The zone owner is notified of any pending subzone requests and either approves or rejects them during the review process.

Zone apex mapping

Zone apex mapping uses the mapping data available on the ​Akamai​ platform to reduce DNS lookup times for your websites.

With zone apex mapping, name servers resolve DNS lookup requests with the IP address of an optimal edge server. Resolving lookups in this way helps you:

• Eliminate the CNAME chains inherent with CDN solutions
• Reduce DNS lookup times for any website on the ​Akamai​ platform
• Deploy ​Akamai​ acceleration solutions for records at the zone apex for which a CNAME cannot otherwise be used

You use the AKAMAICDN private resource record type to configure zone apex mapping.

DNSSEC for Edge DNS

The DNS security extensions (DNSSEC), described in RFCs 4033, 4034, and 4035, allow zone administrators to digitally sign zone data using public key cryptography, proving their authenticity. The primary idea behind DNSSEC is to prevent DNS cache poisoning and DNS hijacking. These record types are used for DNSSEC:

• DNSKEY (DNS public key). Stores the public key used for resource record set signatures.
• RRSIG (resource record signature). Stores the signature for a resource record set (RRset).
• DS (delegation signer). Parent zone pointer to a child zone's DNSKEY.
• NSEC3 (next secure v3). Used for authenticated NXDOMAIN.

The Security Option contract item of Edge DNS supports these features:

• DNSSEC "sign and serve". ​Akamai​ manages signing the zone, key rotation, and serving the zone.
• DNSSEC "serve". You manage signing the zone and key rotation, while ​Akamai​ serves the zone.

DNSSEC sign and serve

The DNSSEC sign and serve feature provides the ability to offload the DNSSEC support entirely to ​Akamai​'s existing key management infrastructure (KMI) for the zone signing key (ZSK) and key signing key (KSK) rotation.

The ZSK is rotated weekly and the KSK is rotated annually. For zone key rotation, ​Akamai​ uses RFC 4641's prepublish key rollover method, modified for constant rotation. That is, two ZSKs are present in the zone apex DNSKEY record. One key actively signs the rest of the zone, while the other key is present so it has time to propagate before becoming active. This method:

• Introduces a new, as of yet unused, DNSKEY record into the apex DNSKEY RRset.
• Waits for the data to propagate (propagation time plus keyset TTL).
• Switches to signing the zone's RRSIGs with the new key, but leaving the previous key available in the apex DNSKEY RRset.
• Waits for propagation time plus maximum TTL in the zone.
• Removes the old key from the apex DNSKEY RRset, which will then restart the key rotation process.

Signature duration is three days. To be sure signatures don't reach expiration, even if records are not being modified, the zone is re-signed at least once per day.

An added benefit of DNSSEC sign and serve is the ability to support top-level redirection. The current recommended algorithm is ECDSA-P256-SHA256, or RSA SHA-256 if you want to avoid the use of ECDSA.

DNSSEC can be used with both ZAM and top-level redirection.

DNSSEC serve

The DNSSEC serve feature provides the ability to support DNSSEC for secondary zones, but the zone administrator is responsible for implementing their own key management infrastructure (KMI) solution and properly rotating their zone signing key (ZSK) and key signing key (KSK).

DNSSEC requires transaction signature (TSIG). For zone access control, you need to enable TSIG with the supported algorithms. In addition to your responsibility for all of the key signing, you must ensure that all the necessary new records are in the zone transfer to ​Akamai​.

📘

Subset RRsets of self-signed zones not served

If you have a self-signed zone, Edge DNS won't serve subset RRsets. It will serve the full RRset as defined in your zone. If the RRset is too large for the standard DNS packet size, your end users' caching name servers will need to negotiate a larger packet size with extension mechanisms for DNS (EDNS0), or else use TCP. If you're concerned about end users' name servers not having this functionality, configure smaller RRsets in your zone.

Alias zones

An alias zone is a zone type that does not have its own zone file. Instead, it bases itself on another Edge DNS (base) zone's (either primary or secondary) resource records. In other words, the zone data is a copy of another Edge DNS zone. You can modify data in alias zones by changing the "parent" or "alias-of" zone.

An organization may have several hundred vanity or brand domains that need to be registered and for which DNS services are required, but for which DNS is configured identically to a base zone. In these cases you can configure one base zone, point many aliases to the base zone, and easily manage any DNS changes by updating only the base zone file.

📘

Default limit for contracts is 2,000

By default, Edge DNS contracts are limited to 2,000 configured zones, including aliases. Contact technical support if you need to exceed this limit.

Logging

Alias zones generate their own log lines independent of their base zone. To receive logs with alias zone traffic, you need to enable log delivery for each alias zone individually.

Compatibility

Alias zones are compatible with:

• Zone apex mapping
• Top-level CNAME (Can only be configured by technical support.)
• Vanity name servers (These name server records should not be from a base zone with aliases.)

When using these features, pay attention before adding alias zones. Check the property receiving the traffic in ​Akamai​ Property Manager, ensuring that the appropriate hostnames are configured and that the correct redirects are set up. If HTTPS support is required, make sure that the certificates are configured correctly. With a certificate that supports subject alternative names (SAN), this typically means adding the domain apex to the certificate.

Alias zones are not compatible with DNSSEC. Each DNSSEC zone requires its own resource record signatures. Base zones with DNSSEC enabled can't have any aliases.

Alias zone example

This example is displayed in standard BIND zone format.

The example-base-zone.com base zone has the following resource records:

The example-alias-zone.com zone is configured as an alias of www.example-base-zone.com. Any time a DNS request asks for resolution of a resource record in the alias zone, Edge DNS will answer with the resource records specified in the base zone, as if the alias zone had the same resource records as the base zone.

Any time a change is made to the base zone's resource records, all the aliases of that zone will reflect the same change.

Billing

When configured on Edge DNS, alias zones receive traffic like any other zone and are counted as regular zones from a billing standpoint.

For example, if a Edge DNS contract allows for 50 zones, and 20 regular zones and 30 alias zones are configured, then these 50 zones will be within the contract entitlement. If 5 additional alias zones are configured, then the total of 55 zones will incur a 5 zone overage based on the per-zone overage rate.

Supported resource record types

Edge DNS supports the Internet (IN) class and the following record types.

• A. IPv4 address.
• AAAA. IPv6 address.
• AFSDB. AFS database.
• AKAMAICDN. ​Akamai​ private resource record for zone apex mapping.
• AKAMAITLC. ​Akamai​ private resource record for top-level CNAME. Can only be configured by technical support. ​Akamai​ recommends using AKAMAICDN instead.
• CAA. Certification authority authorization.
• CERT. Certificate record that stores public key certificates.
• CDNSKEY. Child copy of the DNSKEY record, for transfer to parent. To add record sets of this type, use the Edge DNS Zone Management API.
• CDS. Child copy of the DS record, for transfer to parent. To add record sets of this type, use the Edge DNS Zone Management API.
• CNAME. Canonical name.
• DNSKEY. DNS key. Stores the public key used for RRset signatures. Required for DNS security extensions (DNSSEC).
• DS. Delegation signer. Parent zone pointer to a child zone's DNSKEY. Required for DNSSEC.
• HINFO. System information.
• HTTPS. Hypertext Transfer Protocol Secure.
• LOC. Location.
• MX. Mail exchange.
• NAPTR. Naming authority pointer.
• NS. Name server.
• NSEC. Next secure. Available for self-signed secondary zones only. NSEC3 is a better choice.
• NSEC3. Next secure, version 3. Used for authenticated NXDOMAIN. Required for DNSSEC.
• NSEC3PARAM. NSEC3 parameters.
• PTR. Pointer.
• RP. Responsible person.
• RRSIG. Resource record set (RRset) signature. Stores the digital signature used to authenticate data that is in the signed RRset. Required for DNSSEC.
• SSHFP. Secure shell fingerprint record. Identifies SSH keys that are associated with a host name.
• SOA. Start of authority record. Stores administrative information about a zone, including data to control zone transfers. To add record sets of this type, use the Edge DNS Zone Management API.
• SPF. Sender policy framework.
• SRV. Service locator.
• SVCB. Service bind.
• TLSA. Transport Layer Security Authentication certificate association. Used to associate a TLS server certificate or public key with the domain name where the record is found.
• TXT. Text.
• ZONEMD. Message digests for DNS zones. To add record sets of this type, use the Edge DNS Zone Management API.