Primary, secondary, and alias 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 file that contains the DNS database records for all 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 deploy 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 to ensure the best possible experience for your users.

• Primary zone. When you create a primary zone, you give ​Akamai​ your DNS records to store and manage. You can make changes to these records using either the ​Control Center​ user interface or the Edge DNS Zone Management API. ​Akamai​ pushes zone data to Edge DNS name servers and provides a list of name servers that you can register with your domain registrar.

• Secondary zone. When you create a secondary zone, you maintain an authoritative version of your DNS records on your master name servers. Zone transfer agents (ZTAs) push the zone data to the Edge DNS name servers.

Additionally, alias zones are supported. With alias zones, ​Akamai​ automatically mirrors the configuration of another Edge DNS zone, serving the same DNS records on both the alias zone and the target zone. For example, you may have registered a misspelled domain such as examlpe.com, and you want it to have the same DNS records as example.com.

Zone transfer agents (ZTAs)

ZTAs push zone data from your master name servers to Edge DNS name servers. ZTAs are used to transfer data for secondary zones only.

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), Microsoft Windows Server, and Microsoft DNS operating systems.

Refresh and retry intervals in the start of authority (SOA) record determine the interval between zone transfers. In addition, you can configure the system to accept NOTIFY requests from your secondary zones to allow near-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 a zone transfer from your master name server, but only one ZTA (usually the first one that receives an update using one transfer) will send the 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.

Outbound zone transfers

Outbound zone transfers allow you to transfer zone data from Edge DNS servers to your external name servers. This is useful if your organization uses multiple service providers for DNS and you need to maintain a master zone file with zone data. Authoritative zone transfers (AXFR) are used to transfer zone data to your external name servers.

You can enable outbound zone transfers when you create or modify a primary or secondary zone. As part of this configuration, you provide this information:

• Notification targets: IP addresses of name servers that are contacted when zone data is available to transfer. When there’s a new version of a zone file, ​Akamai​ sends a NOTIFY request to each target or name server that you configure. The NOTIFY request is a notification alert that indicates new data is available. This request will usually initiate the zone transfer.
• An access control list: List of IP addresses or CIDR blocks that are used to perform the zone transfer. These addresses are the only ones allowed to transfer data from Edge DNS servers to your external name server. Notification targets are automatically included in the access control list (ACL). However, you can omit them from the list.
• Transfer signature (TSIG) key. This key is used for securing DNS messaging for zone transfers. You can select an existing key or create a new key.

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 an PRODUCT_NICKNAME representative)
• 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.

📘

Client READ-ONLY access to the Edge Hostnames API is required to configure AKAMAICDN records.

• AKAMAITLC. A self-service. ​Akamai​ private resource record for top-level CNAME. Can only be configured by technical support.
• 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.