Managing DNSSEC Configuration

Enabling DNSSEC for managed zones

Enabling DNSSEC for an existing managed zone in the Google Cloud Console is easy; just click the DNSSEC setting for the zone and select "On" in the pop-up menu:

Enable DNSSEC zone pop-up

In the confirmation dialog that appears, just click the Enable button.

Enable DNSSEC confirmation dialog

You can also enable DNSSEC for existing managed zones using the gcloud command line tool or the API:

gcloud

gcloud dns managed-zones update EXAMPLE_ZONE --dnssec-state on

Replace EXAMPLE_ZONE in the command line above with the actual zone ID.

python

def enable_dnssec(project_id, name, description=None):
client = dns.Client(project=project_id)
zone = client.zone(name=name)
zone.update(dnssec='on', description=description)

Enabling DNSSEC when creating zones

Enabling DNSSEC when you are creating a zone in the Cloud Console is simple; click on the DNSSEC setting option and select "On" in the pop-up menu:

Create DNSSEC signed zone

You can also enable DNSSEC when you create zones using the gcloud command line tool or the API:

gcloud

gcloud dns managed-zones create EXAMPLE_ZONE \
    --description "Signed Zone" --dns-name myzone.example.com --dnssec-state on

Replace EXAMPLE_ZONE in the command line above with the actual zone ID.

python

def create_signed_zone(project_id, name, dns_name, description):
client = dns.Client(project=project_id)
zone = client.zone(
    name,  # examplezonename
    dns_name=dns_name,  # example.com.
    description=description,
    dnssec='on')
zone.create()
return zone

Verifying DNSSEC deployment

You can use DNSViz, Zonalizer, the Verisign DNSSEC debugger, or Zonemaster to verify correct deployment of your DNSSEC-enabled zone (the latter two can also be used before you update your registrar with your Cloud DNS name servers or DS record to activate DNSSEC). An example of a domain that is properly configured for DNSSEC is example.com; you can see it with DNSViz at http://dnsviz.net/d/www.example.com/dnssec/.

Recommended TTL settings for DNSSEC-signed zones

Unlike TTL expirations, which are relative to the time a name server sends a response to a query, DNSSEC signatures expire at a fixed absolute time. TTLs configured longer than a signature lifetime can lead to many clients requesting records at the same time, when the DNSSEC signature expires. Very short TTLs can also cause problems for DNSSEC-validating resolvers.

See RFC 6781 section 4.4.1 and figure 11 for more advice on TTL selection, but the key point is this:

Having a TTL that is at least a few times smaller than your signature validity period avoids query load peaks.

When reading the RFC, keep in mind that many signature time parameters are fixed by Cloud DNS and you cannot change them. They are currently the following (but are subject to change without notice or update to this document):

  • Inception offset = 1 day
  • Validity period = 21 days
  • Re-sign period = 3 days
  • Refresh period = 18 days
  • Jitter interval = ½ day (or ±6 hours)
  • Minimum signature validity = refresh – jitter = 17.75 days = 1533600

You should never use a TTL longer than the minimum signature validity.

Disabling DNSSEC for managed zones

Once you have removed DS records and waited for them to expire from cache, you can easily turn off DNSSEC using the following gcloud command:

gcloud dns managed-zones update EXAMPLE_ZONE --dnssec-state=off

Replace EXAMPLE_ZONE in the above gcloud command with the actual zone name.

DNSSEC, domain transfers, and zone migration

For DNSSEC-enabled zones where DNSSEC has been activated at the domain registry, you must take extra steps to ensure proper operation of the domain:

  • When it is transferred to another registrar (or ownership is transferred)

  • When migrating the DNS zone between Cloud DNS and another DNS operator

The technical approach that Cloud DNS uses for these migrations is the KSK Double-DS rollover variant described in RFC 6781 section 4.1.2.

ICANN has an informative presentation PDF about this process in general and the potential pitfalls.

Migrating DNSSEC-signed zones to Google Cloud DNS

If you are migrating a DNSSEC-signed zone to Google Cloud DNS, check that Cloud DNS supports the same KSK algorithm already in use. If not, deactivate DNSSEC at your domain registrar before migrating the zone and updating the name server records at the registrar to use the Cloud DNS name servers.

If the existing KSK and ZSK algorithms are supported in Cloud DNS, you can perform the migration with DNSSEC enabled, following these steps:

  1. Create a new DNSSEC-signed zone in DNSSEC 'Transfer' state. Transfer state allows you to manually copy DNSKEYs into the zone.

  2. Export your zone files and import them into the new zone.

  3. Add the DNSKEYs (both KSK and ZSK) from the old zone's zone files.

    • You can also use the dig command to query the other name servers for DNSKEY records.
  4. Add the DS record for the new zone to your registrar.

  5. Update the name server records at the registrar to the Cloud DNS name servers for the new zone.

Leaving DNSSEC transfer state

Before leaving DNSSEC transfer state, wait until the name server references (NS and DS) to Google Cloud DNS have propagated to all authoritative registry name servers, and the TTL has expired for all old name server DNSSEC resource records (not only registry parent zone NS and DS records, but also DNSKEY, NSEC/NSEC3, and RRSIG from the old zone). Make sure to remove the manually-added transfer DNSKEY records.

Then you can change the DNSSEC state of the zone from 'Transfer' to 'On'. Making this change enables automatic ZSK rotation from the zone. Generally your zones can safely leave DNSSEC transfer state after a week, and should not remain in DNSSEC transfer state for more than a month or two.

You should also remove the DS record for the old DNS operator's zone from your registrar.

Migrating DNSSEC-signed zones from Google Cloud DNS

Before you migrate a DNSSEC-signed zone to another DNS operator, check that they support the same KSK algorithm that you are using. If not, deactivate DNSSEC at your domain registrar before migrating the zone and updating the name server records at the registrar to use the new name servers.

If they support the same KSK (and preferably same ZSK) algorithms, and provide a way to copy existing DNSKEYs to the new zone, you can perform the migration keeping DNSSEC enabled by following these steps:

  1. Change the DNSSEC state from 'On' to 'Transfer'. This stops ZSK rotation.

  2. Export your zone file (including DNSKEYs) and import it into the new zone.

  3. If the DNSKEYs (both KSK and ZSK) were not imported, add them manually.

    • Use the dig command to query the Cloud DNS name servers for your zone for DNSKEY records:

      dig DNSKEY myzone.example.com. @ns-cloud-e1.googledomains.com.
      
  4. Enable DNSSEC-signing for the new zone, and add a DS record for the new KSK at the registrar.

    • If your registrar cannot support multiple DS records, do this in step 6.
  5. (Optional) Import the new DNSKEYs for the new zone into Cloud DNS.

    • You can use a dig command similar to the one in step 3 for this, but skip the DNSKEYs that you exported from Cloud DNS.
  6. Update the name server records at the registrar to use the new DNS operator.

    • If you can only replace DS records at your registrar, do this now.

If the other DNS operator has a process for migrating a DNSSEC-signed zone (like Dyn) you should perform their steps in parallel with this, after step 1 here.

Once you have completed all necessary steps on the other side, disable DNSSEC by updating the DNSSEC state to 'Off' (or simply delete the zone in Cloud DNS), and remove the DS record for the Cloud DNS zone from your registrar.

Next steps

Was this page helpful? Let us know how we did:

Send feedback about...

Cloud DNS Documentation