Advanced DNSSEC

There are several advanced DNSSEC configuration options you can use if you enable DNSSEC for your managed zones. These range from different signing algorithms and denial of existence to the ability to use record types that require or recommend DNSSEC for their use; they are all described below.

Delegating DNSSEC-signed subdomains

You can enable DNSSEC for delegated subdomains once you have enabled DNSSEC for your primary domain. To enable DNSSEC for delegated subdomains, first create a DS record within a Cloud DNS zone. You also must create one or more NS records. For instructions on how to create NS records, see Adding or removing a record.


To create DS records for delegated subdomains, you must obtain the DS record for the zone. If the delegated zone is also hosted in Cloud DNS, you can get the DS record from the Cloud Console.

  1. Navigate to the managed zone.
  2. To see the DS record for the zone, click the Registrar Setup link in the upper right corner of the Zone details page.
  3. After noting the DS record information, continue the procedure in step 2 of the gcloud commands tab.

Registrar Setup pop-up


  1. To get the DS record information for delegated subdomains, use the following command:

    $ gcloud dns dns-keys list --zone example_zone

    Replace the following command option:

    • example_zone: The name of a DNS zone in your project

    The output looks like the following:

    0   1234     KEY_SIGNING   True
    1   12345    ZONE_SIGNING  True

  2. To get a complete DS record and all details of the key, you require the ID of the KEY_SIGNING Key (KSK), which is usually zero (0). Use the following command:

    $ gcloud dns dns-keys describe --zone example_zone ksk_id \
     --format "value(ds_record())"

    Replace the following command options:

    • example_zone: The name of a DNS zone in your project
    • ksk_id: The ID number, usually 0
  3. Copy the output from the previous command to use it in a subsequent step.

    The output looks similar to the following:

    44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
  4. To create the DS records for a secure sub-delegation, start the transaction using the following command:

    $ gcloud dns record-sets transaction start -z example_zone

    Replace the following command options:

    • example_zone: The name of a DNS zone in your project
    • A subdomain of the DNS name of the zone

    The output looks like the following:

    Transaction started [transaction.yaml].

  5. Next, add a record-set using the following command:

    $ gcloud dns record-sets transaction add -z example_zone \
     --ttl 3600 --type DS --name \
     DS_record-and_key"44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb"

    Replace the following command options:

    • example_zone: The name of a DNS zone in your project
    • A subdomain of the DNS name of the zone
    • DS_record-and_key: The DS record and key that your got in step 2

    The output looks like the following:

    44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
    Record addition appended to transaction at [transaction.yaml].

  6. To add NS records, use the following command:

    $ gcloud dns record-sets transaction add -z example_zone \
     --ttl 3600 --type NS --name \

    Replace the following command options:

    • example_zone: The name of a DNS zone in your project
    • A subdomain of the DNS name of the zone
  7. Enter the following RData: \ \ \

    The output looks like the following:

    Record addition appended to transaction at [transaction.yaml].

  8. To execute the transaction, use the following command:

    $ gcloud dns record-sets transaction execute -z example_zone

    Replace the following command option:

    • example_zone: The name of a DNS zone in your project

    The output looks like the following:

    Executed transaction [transaction.yaml] for managed-zone [dns-example].
    Created     [].
    ID  START_TIME                STATUS
    42  2019-08-08T23:12:49.100Z  PENDING

Advanced signing options

When enabling DNSSEC for a managed zone, or creating a managed zone with DNSSEC, you can select the DNSSEC signing algorithms and the denial-of-existence type.

You can change DNSSEC settings (for example, to the algorithm used to crytopgraphically sign records),for a managed zone before enabling DNSSEC. If DNSSEC is already enabled for a managed zone, to make changes, first disable DNSSEC, make the required changes, and then re-enable DNSSEC using this command (replace example_zone with the name of a DNS zone in your project):

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

For details, see Enabling DNSSEC for managed zones.

The following command enables DNSSEC with 256-bit ECDSA and NSEC for the smallest DNSSEC-signed response packets possible using Cloud DNS. Replace example_zone with the name of a DNS zone in your project:

gcloud dns managed-zones update example_zone \
  --dnssec-state on \
  --ksk-algorithm ECDSAP256SHA256 --ksk-key-length 256 \
  --zsk-algorithm ECDSAP256SHA256 --zsk-key-length 256 \
  --denial-of-existence NSEC

If you provide any KSK or ZSK algorithms or key lengths, you must provide all of them (--ksk-algorithm --zsk-algorithm --ksk-key-length --zsk-key-length) and their arguments in the command. You can specify denial-of-existence as NSEC or NSEC3 independent of algorithms.

The supported algorithm options and arguments are listed in the following table showing defaults as well as weak values only available on request:

Algorithm KSK lengths ZSK lengths Comments
RSASHA1 1024, 2048 1024, 2048 SHA-1 considered weak
RSASHA256 1024, 2048 1024, 2048
RSASHA512 1024, 2048 1024, 2048 Not widely supported
ECDSAP256SHA256 256 256 May not be supported
ECDSAP384SHA384 384 384 Not widely supported

Do not use RSASHA1 unless you need it for compatibility reasons; there is no security advantage to using it with larger key lengths.

The security and performance differences between RSASHA256 and RSASHA512 are minimal and signed response sizes are identical. Key lengths do matter: longer keys are slower and responses are larger (see analyses of response size for the root zone and TLDs, and an analysis of server-side performance on Windows).

Client support for ECDSA is limited to fairly recent systems; older clients that cannot validate ECDSA-signed zones consider them unsigned, which may be insecure if you use new record types that rely on DNSSEC. Registrar and registry support for 256-bit ECDSA is common but not universal; 384-bit ECDSA is only supported by a few registries and even fewer registrars. Using ECDSA can be effective if you do not need to support older clients; the signatures are much smaller and faster to compute.

Avoid using different algorithms for the KSK and ZSK in your managed zones; it reduces compatibility and may compromise security. Some DNSSEC-validating resolvers may fail validation for zones with DNSKEY algorithms that are not used to sign all records in the zone, even though RFC 6840 says "they MUST NOT insist that all algorithms ... in the DNSKEY RRset work." If this is not a concern (most validating resolvers follow RFC 6840) you can use RSASHA256 for the KSK and ECDSA for the ZSK if your domain registrar or TLD registry do not support ECDSA and you need reduced response sizes.

NSEC3 is the default denial-of-existence type; it offers limited protection against zone walkers trying to discover all the records in your zone. The NSEC3PARAM settings are fixed: NSEC3 "opt-out" is disabled for security, and there is 1 additional hash iteration (for a total of 2) with a 64-bit salt.

NSEC has slightly smaller responses, but no protection against zone walking. Using NSEC can also reduce queries for nonexistent domains; Google Public DNS and several other DNSSEC-validating resolvers can synthesize negative responses from cached NSEC records without querying your Cloud DNS zone.

Using new DNS record types with DNSSEC-secured zones

After your domain has been fully DNSSEC-secured you can start using several new DNS record types that leverage the authenticity and integrity guarantees of DNSSEC-signed zones to enhance the security of other services.


SSHFP records contain a fingerprint of an SSH server's public key, and can be used by SSH client applications to validate the SSH servers. SSH clients usually require user interaction to confirm the server's public key on the first connection and generate warnings if the key is changed. An SSH client configured to use SSHFP always uses the key in a server's SSHFP record for that server; only keys for servers without an SSHFP record are saved for reuse.

The SSHFP record format is: algorithm number, fingerprint type number, and server key fingerprint. The algorithm numbers for SSH are

  1. RSA
  2. DSA
  3. ECDSA
  4. ED25519

Fingerprint types are

  1. SHA-1 (deprecated, only for compatibility)
  2. SHA-256

StackExchange has suggestions for creating SSHFP and there are tools for to generate them by scanning servers, using existing known host files, or configuration management. These notes have even more examples and links.


TLSA records contain information that can be used to validate X.509 certificates (such as those used by HTTPS) without depending on their being signed by one of a pre-configured set of certificate authorities (CAs). This allows you to set up your own CAs and generate certificates for HTTPS, as well as permitting validation of certificates for protocols like SMTP where there is typically no application support for pre-configured trusted CAs.

DANE (Domain Authentication of Named Entities) as specified in RFC 6698 and related RFCs, uses TLSA records in specific ways to secure many protocols and applications. The IETF Journal and Internet Society have a useful introductory article and DANE overview.


DANE allows you to securely configure HTTPS servers using certificates generated with your own Certificate Authority infrastructure based on OpenSSL or CloudFlare's CFSSL.

SIDNLabs' DANE validator for HTTPS servers is helpful for testing a DANE deployment for HTTPS.

SMTP (E-mail) TLS certificate verification

The SMTP e-mail protocol is particularly vulnerable to downgrade attacks that disable encryption, and DANE provides a way to prevent these. The Internet Society has a two part tutorial on using DANE for SMTP with the free and automated certificates available from Let's Encrypt. (Be sure to heed the advice to avoid using certain TLSA record formats with Let's Encrypt certificates.)

There is also excellent advice (and a DANE domain validator for HTTPS and SMTP) at The "Test your email" validator also checks DANE.

XMPP (Jabber chat) TLS certificate verification

XMPP (and other services that use SRV records) can also take advantage of DANE. An XMPP example uses DANE-SRV configuration as specified in RFC 7673.

TXT (OpenPGP / GnuPG) public key association

TXT records can be used without DNSSEC, but DNSSEC-signed TXT records provide greater confidence in their authenticity. This is important for DNS-based publication of OpenPGP (GnuPG) public keys, which are not signed by well-known parties like X.509 certificate authorities. If Alice publishes (in the DNSSEC-signed an.example zone) a TXT record like:

alice._pka 86400 IN TXT "v=pka1;fpr=083382bac0059be3d6544c8b0dcf16f482a6;uri=https://an.example/a.asc"

and hosts a copy of the ASCII-armored public key at the given URI, Bob can look up an OpenPGP key for alice@an.example with reasonable security (this is not a replacement for web-of-trust validation, but makes OpenPGP encryption possible with previously unknown parties).

You can use these instructions to generate these "PKA Version 1" TXT records (as they are called in this overview of keys in DNS). Another how-to also explains how to create OpenPGP CERT records (but neither CERT nor OPENPGPKEY records are supported by Cloud DNS).

If you have registered your OpenPGP key at, you don't need to host the key on your own server and can simply use a URL like (replacing KEYBASE_USERNAME with your username). If you have uploaded your OpenPGP key to a keyserver, you can also use an hkp: URI for that keyserver, such as hkp:// or hkp://, although users behind firewalls blocking port 11371 may not be able to reach it (some keyservers provide port 80 HTTP URLs.


There are three other kinds ot TXT records that can be used to secure your e-mail services and prevent spammers and scammers from sending e-mail that appears to come from your domain (even though it doesn't).

Specifies the SMTP servers (by domain name or IP address) that may send e-mail for a domain.
Publishes a set of public keys used to verify e-mail is sent from a domain, and protect messages from being modified in transit.
Specifies domain policies and reporting for SPF and DKIM validation and error reporting.

You can use the "Test your email" validator to verify that your domain is properly configured to use all three of these record types. At the Common Mistakes FAQ you can find useful advice on configuring SPF records.

Other record set types enhanced by DNSSEC

Besides TXT, there are a few other record set types that benefit from DNSSEC, even though they do not require it.


Certification Authority Authorization (CAA) record sets allow you to control which public certificate authorities (CAs) can generate TLS or other certificates for your domain. This is most useful (and effective) if you want to make sure that a public CA issuing domain-validated (DV) certificates (like does not issue certificates for your domain.

A typical CAA record has a simple format like this: 0 issue "best-ca.example"; that example allows the best-ca.example CA (and no other CA) to issue certificates for names in the domain where the CAA record set is located. If you want to allow multiple CAs to issue certificates, simply create multiple CAA records.

RFC 6844 provides further details on the use of the CAA record set type, and strongly recommends the use of DNSSEC.


You can also enable opportunistic encryption via IPSEC tunnels by publishing IPSECKEY records; the StrongSwan IPSEC VPN implementation has a plugin that uses IPSECKEY records.

In addition to placing IPSECKEY records in the usual forward zones, such as, RFC 4025 section 1.2 requires security gateways to look for IPSECKEY records in the reverse zones and

DNSSEC support for reverse zones is less common than for forward zones, and requires an Internet Service Provider that implements DNSSEC themselves, but there are some that can support DNSSEC for reverse zone delegations.

Note that reverse zones for Google Compute Engine VM external IPs do not yet support delegation. See the Google Compute Engine feature request.

Next steps