DNSSEC

DNSSEC (Domain Name System Security Extensions) provides cryptographic authentication for DNS lookup responses.

DNS wasn't originally designed to encrypt or authenticate DNS traffic, so the DNS protocol doesn't provide protection against malicious or forged responses. DNSSEC adds security extensions to DNS to protect customers from such attacks. DNSSEC uses cryptographic verification to ensure that the resolver can verify each DNS response for both integrity (the message didn't change during transit) and authenticity (the data came from the expected source). DNSSEC doesn't encrypt the response to DNS queries. See the DNSSEC RFC reference for general information.

You can set up and manage OCI DNSSEC on each individual public zone. DNSSEC requires a validating resolver to validate signatures, and every DNS provider/registrar in the zone hierarchy must support DNSSEC. OCI DNSSEC uses signing algorithm RSASHA256 with a key length of 256 bytes and delegation algorithm SHA256.

The specific record types associated with DNSSEC are DNSKEY, DS, NSEC3, and RRSIG. NSEC3 and RRSIG records don't appear in the Console or API, but are included in query responses. You create and update DS records as part of the setup and rollover process. The DNS service automatically creates and manages DNSKEY records, but you can change the record TTL.

OCI DNSSEC uses dynamic (inline) signing. With dynamic signing, RRSIG and NSEC3 records are generated by the nameserver responding to queries.

Key Considerations

Before you set up DNSSEC on DNS zones, consider the following important information:

DNSSEC isn't supported on private zones.
To use DNSSEC with secondary zones, you must enable DNSSEC with the primary DNS provider.
To migrate an existing DNSSEC signed zone to OCI, first disable DNSSEC on the zone. Then, copy the records to the OCI zone. Finally, enable DNSSEC on the OCI zone.
Having both DNSSEC and secondary egress on a zone isn't supported. You can use secondary ingress from an external provider that uses DNSSEC to an OCI zone, but the external provider is responsible for signing the zone.
You can use DNSSEC together with advanced features such as ALIAS, CNAME, and Traffic Management on a zone.
DNS uses TCP port 53 as a fallback mechanism when it can't use UDP to send data. Traditional DNS relies on TCP 53 for operations such as zone transfer. The use of DNSSEC, or DNS with IPv6 records such as AAAA, increases the chance that DNS data is transmitted on TCP.

DNSSEC Concepts

DNSSEC state: A property of a zone indicating whether DNSSEC is enabled or disabled on the zone.
DNSSEC configuration: A property of a zone that contains information about the DNSSEC key versions.
DNSSEC key version: The relevant information for either a zone signing key (ZSK) or a key signing key (KSK).
ZSK (zone signing key): The key used to sign all the non DNSKEY RRsets in the zone.
KSK (key signing key): The key used to sign the DNSKEY RRset in the zone. Establishes a chain of trust with the parent zone.

Chain of trust: A continuous chain of signed zones starting at the root zone. The chain of trust is formed by DNSKEY records on the child zone and DS records on the parent. The chain of trust goes from a DNSSEC signed zone, up the zone hierarchy, to the root zone. The chain is verified with signatures through asymmetric cryptography.
Rollover: A carefully orchestrated sequence of steps to replace an old DNSSEC key version with a new DNSSEC key version without disruption. See Rollover.
Stage: A step in the rollover process. Introduce a new DNSSEC key version so that it can replace an existing DNSSEC key version.
Promote: A step in the rollover process. Inform OCI that you have added the required information about the new KSK to the parent zone DS record.
Time published: A property of a DNSSEC key version. Indicates that a DNSKEY record exists on a zone beginning at the specified time.
Time activated: A property of a DNSSEC key version. Indicates that the key is signing the zone beginning at the specified time.
Time inactivated: A property of a DNSSEC key version. Indicates that the key is no longer signing the zone beginning at the specified time.
Time unpublished: A property of a DNSSEC key version. Indicates that a DNSKEY record no longer exists on a zone beginning at the specified time.
Time expired: A property of a DNSSEC key version. The time that a DNSSEC key version is scheduled for removal.

Getting Started

For DNSSEC to work, a valid chain of trust is required from the root down to the zone. Before you begin, ensure that the registrar and all DNS providers for parent and child zones support DNSSEC and DS records.

We recommend that you monitor the resolution of domains with and without DNSSEC, before and throughout the process. Useful tools you can use to verify their DNSSEC configuration are BIND's Dig and Delv tools, DNSViz, or DNS Analyzer.

Be sure to familiarize yourself with the entire DNSSEC setup process before you begin.

Setting Up DNSSEC

Create a zone and enable DNSSEC during creation. Or, update an existing zone to enable DNSSEC. Wait for the work request to complete successfully before proceeding.
Create a DS record on the parent zone at the point of delegation that contains the KSK digest information. The parent zone can be a zone in OCI or another DNS provider.
After the DS record has been created, promote the KSK. This step informs OCI that you have completed step 2 and the automation can proceed.
Create an alarm to alert you when a new KSK version is generated so you can complete the required rollover actions.

Rollover

Rollover is the process of introducing a new DNSSEC key version and removing the old DNSSEC key version without disruption. The rollover process for both ZSKs and KSKs aligns with security best practices regarding public key cryptography. Replacement keys are generated a week before expiration.

You can use the stage DNSSEC key operation at any time to create a replacement key version ahead of schedule. You can have up to 10 key versions on a zone at one time. We recommend having a single key rollover happening at a time of either key type.

Note

Default rollover patterns are subject to change by OCI. To request a one-time key rollover outside of the default pattern, Open a Support Request.

ZSK Rollover

ZSKs are automatically rolled over every 30 days by default. First, a replacement ZSK key version is created. Then, the old ZSK key version is removed. If you decide to stage a replacement ZSK ahead of schedule, wait until that ZSK rollover has successfully completed before staging another ZSK to begin a second rollover. This avoids any service disruptions because of timing differences on the ZSK or record TTL (time to live) caches.

KSK Rollover

KSK rollover begins annually when a replacement DNSSEC key version is created. The alarm that you create during setup step 4 and a notification in the Console let you know that a new KSK requires promotion. To avoid service disruptions, after the new DNSKEY record is created you must wait until the DNSKEY record's TTL expires before removing the old DS record. You can proceed in one of two ways:

After the new DNSKEY record is created, wait until the DNSKEY record's TTL expires. Then, add the new DS record and remove the old DS record at the same time.
After the new DNSKEY record is created, add the new DS record immediately. Then, remove the old DS record as a separate step after waiting out the DNSKEY record's TTL.

Absence of a DS record on the parent side of a cut doesn't typically disrupt traffic, but it fails to establish a chain of trust requiring the child zone to be signed. So if you remove the old DS record too soon, or before adding the new DS record, then the zone stops using DNSSEC for that period of time.

See Rolling Over a Key-Signing Key (KSK).

Timing

The maximum allowed TTL on DNSSEC signed zones is one day. This limit ensures no disruption of service during a rollover, because the rollover process sometimes requires waiting until TTLs expire before proceeding.

We recommend using a TTL of one hour for DNSKEY records on parent zones. Rollover for a KSK involves waiting out the TTL of the DNSKEY at certain steps in the process. If a TTL is too large, it isn't possible to complete the rollover within the rollover period, causing a disruption.

We recommend using a TTL of one hour when creating DS records on parent zones. If a registrar or DNS provider doesn't support a TTL of one hour, then follow their recommendations. For more information about how to decide on a TTL for a DS record, see DS Signature Validity Period in the DNSSEC RFC reference.

Record changes take some amount of time to provision before they're available in query responses. Take record provisioning time into consideration when estimating wait time for record changes.

DNSSEC Tasks

Setup and manage DNSSEC with the following tasks:

Oracle Cloud Infrastructure Documentation