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
It is possible to enable DNSSEC for delegated subdomains, once you have enabled DNSSEC for your primary domain. This involves creating a DS record, in this case within a Cloud DNS zone.
You can use the Google Cloud Platform Console to create DS records for delegated subdomains (you also need to create one or more NS records). If the delegated zone is also hosted in Cloud DNS, you can get the DS record from the GCP Console by navigating to the managed zone and clicking the "Registrar Setup" link in the upper right corner of the "Zone details" page.
You can also use the
gcloud command-line tool to get this information
EXAMPLE_ZONE with the name of a DNS zone in your project):
$ gcloud dns dns-keys list --zone EXAMPLE_ZONE ID KEY_TAG TYPE IS_ACTIVE DESCRIPTION 0 1234 KEY_SIGNING True 1 12345 ZONE_SIGNING True
You need the ID of the KEY_SIGNING Key (KSK), which is usually zero (0),
to get a complete DS record and all details of the key you may need to create it
EXAMPLE_ZONE with the name of a DNS zone in your project, and
KSK_ID with the ID number, usually 0, as noted above):
$ gcloud dns dns-keys describe --zone EXAMPLE_ZONE KSK_ID \ --format "value(ds_record())" 1234 7 1 2FD4E1C67A2D28FCED849EE1BB76E7391B93EB12
You can also use
gcloud to create the DS records for a secure sub-delegation
EXAMPLE_ZONE with the name of a DNS zone in your project, and
SUBDOMAIN.EXAMPLE.COM with a subdomain of the DNS name of the zone):
$ gcloud dns record-sets transaction start -z EXAMPLE_ZONE Transaction started [transaction.yaml]. $ gcloud dns record-sets transaction add -z EXAMPLE_ZONE \ --ttl 3600 --type DS --name SUBDOMAIN.EXAMPLE.COM \ '36283 5 1 0173d13977ffdf12716E3A1225B1B0B639B8CB46' Record addition appended to transaction at [transaction.yaml]. $ gcloud dns record-sets transaction add -z EXAMPLE_ZONE \ --ttl 3600 --type NS --name SUBDOMAIN.EXAMPLE.COM \ ns-cloud-e1.googledomains.com. Record addition appended to transaction at [transaction.yaml]. $ gcloud dns record-sets transaction add -z EXAMPLE_ZONE \ --ttl 3600 --type NS --name SUBDOMAIN.EXAMPLE.COM \ ns-cloud-e2.googledomains.com. Record addition appended to transaction at [transaction.yaml]. $ gcloud dns record-sets transaction add -z EXAMPLE_ZONE \ --ttl 3600 --type NS --name SUBDOMAIN.EXAMPLE.COM \ ns-cloud-e3.googledomains.com. Record addition appended to transaction at [transaction.yaml]. $ gcloud dns record-sets transaction add -z EXAMPLE_ZONE \ --ttl 3600 --type NS --name SUBDOMAIN.EXAMPLE.COM \ ns-cloud-e4.googledomains.com. Record addition appended to transaction at [transaction.yaml]. $ gcloud dns record-sets transaction execute -z EXAMPLE_ZONE Executed transaction [transaction.yaml] for managed-zone [dns-example]. Created [https://www.googleapis.com/dns/v1/projects/EXAMPLE/managedZones/EXAMPLE_ZONE/changes/42]. 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. Changing the DNSSEC settings is only effective for a managed zone if DNSSEC is not already enabled. If you need to change the settings for a managed zone where it has been enabled, turn DNSSEC off and then re-enable it from the command line with your desired settings.
This command enables DNSSEC with 256-bit ECDSA and NSEC for the smallest
DNSSEC-signed response packets possible using Cloud DNS
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
Fingerprint types are
- SHA-1 (deprecated, only for compatibility)
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 and DANE
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.
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.)
XMPP (Jabber chat) TLS certificate verification
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
email@example.com 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 Keybase.io,
you don't need to host the key on your own server and can simply use a URL like
KEYBASE_USERNAME with your Keybase.io username).
If you have uploaded your OpenPGP key to a keyserver,
you can also use an hkp: URI for that keyserver,
although users behind firewalls blocking port 11371 may not be able to reach it
(some keyservers provide port 80 HTTP URLs.
TXT (SPF, DKIM, and DMARC)
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 LetsEncrypt.org) 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.
In addition to placing IPSECKEY records in the usual forward zones,
RFC 4025 section 1.2
requires security gateways to look for IPSECKEY records in the reverse zones
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.