DNS records overview

This page provides an overview of records and lists DNS record types that Cloud DNS supports.

A record is a mapping between a DNS resource and a domain name. Each individual DNS record has a type (name and number), an expiration time (time to live), and type-specific data.

Supported DNS record types

Cloud DNS supports the following types of records.

Record type Description
A

Address record, which maps host names to their IPv4 address.

AAAA

IPv6 address record, which maps host names to their IPv6 address.

ALIAS

Alias record (Preview), which maps an alias domain name to a canonical name at the zone apex. An alias record is also called an ANAME record or CNAME flattening.

You can configure alias records by using the gcloud CLI or the Cloud DNS API. You cannot configure alias records by using the Google Cloud console.

CAA

Certificate Authority (CA) Authorization, which specifies which CAs are allowed to create certificates for a domain.

CNAME

Canonical name record, which specifies alias names.

If you encounter issues while creating a CNAME record, see CNAME record defined in a private zone not working.
DNSKEY

The DNSSEC key from another operator for secure transfer. This record set type can only be added to a DNSSEC-enabled zone in Transfer state.

DS

The DNSSEC key fingerprint for a secure delegated zone. This record set type does not activate DNSSEC for a delegated zone unless you enable (and activate) DNSSEC for this zone.

HTTPS

HTTPS Service Binding record, which allows an origin to indicate multiple alternative endpoints, each with associated parameters. This record also redirects HTTP to HTTPS. This record type is based on the more general SVCB record type and uses the same value format.

IPSECKEY

IPsec tunnel gateway data and public keys for IPsec-capable clients to enable opportunistic encryption.

MX

Mail exchange record, which routes requests to mail servers.

NAPTR

Naming authority pointer record, defined by RFC 3403.

NS

Name server record, which delegates a DNS zone to an authoritative server.

PTR

Pointer record, which is often used for reverse DNS lookups.

SOA

Start of authority record, which specifies authoritative information about a DNS zone. An SOA resource record is created for you when you create your managed zone. You can modify the record as needed (for example, you can change the serial number to an arbitrary number to support date-based versioning).

SPF

Sender Policy Framework record, a deprecated record type formerly used in email validation systems (use a TXT record instead).

SRV

Service locator record, which is used by some voice over IP (VoIP), instant messaging protocols, and other applications.

SSHFP

SSH fingerprint for SSH clients to validate the public keys of SSH servers.

SVCB

Service Binding record, which allows a logical service to indicate multiple alternative endpoints, each with associated parameters. For HTTPS origins, see the HTTPS record type.

TLSA

TLS authentication record for TLS clients to validate X.509 server certificates.

TXT

Text record, which can contain arbitrary text and can also be used to define machine-readable data, such as security or abuse prevention information.

A TXT record can contain one or more text strings; the maximum length of each individual string is 255 characters. Mail agents and other software agents concatenate multiple strings. Enclose each string in quotation marks.

To add, delete, or update records, see Managing records.

Wildcard DNS records

Cloud DNS supports wildcard records for all record types, except for NS records.

Alias records

An ALIAS record is a Cloud DNS custom record type that behaves like a CNAME record but can only be used at the zone apex and only responds to address record (A or AAAA) queries. Specifically, the ALIAS record type maps an alias domain name to a canonical name and uses the canonical name to look up the answer. This record type is useful when you need CNAME behavior at the apex. You cannot place a CNAME record at the apex because it cannot exist alongside any other record type, including the SOA record that is required at the zone apex.

ALIAS records are specific to Cloud DNS and are never exposed to an external client querying Cloud DNS zones. For a client, an ALIAS record appears as a standard A or AAAA record in the DNS response. ALIAS records are not compatible with DNSSEC, so you cannot enable DNSSEC on a zone with ALIAS records.

You can manage alias records like all other records. To learn how to manage records, see Manage records.

Query resolution process

Alias records are only available for Cloud DNS public zones.

For CNAME records, the resolver is responsible for resolving the canonical name. For ALIAS records, the Cloud DNS name server resolves the canonical name and produces synthesized A or AAAA records to return to the resolver. The synthesized A or AAAA records have the ALIAS record's name with the IP addresses found from resolving the ALIAS record's target. The Cloud DNS name servers use Google's available recursive resolvers to resolve alias records.

If the alias target resolves to a resource record set (RRSet) with multiple addresses, Cloud DNS returns all of the records but randomizes their order before returning the synthesized address record. This process is similar to how Cloud DNS treats answers from its nameservers.

Only address records are synthesized during ALIAS record target resolution. Queries for ALIAS records don't return any intermediary CNAME records that are found while resolving the alias record's target. CNAME records that are found through CNAME chasing before reaching the ALIAS record are returned unmodified. If the ALIAS target resolution fails, that is, returns a response code other than NOERROR, the Cloud DNS name server returns a SERVFAIL response to its client. If the resolution results in a NODATA response, which is a NOERROR response with no address records, the Cloud DNS name server returns a NODATA response.

When resolving ALIAS record targets, Cloud DNS doesn't use client provided EDNS Client Subnet.

Time to live (TTL) parameter and caching

The TTL value returned with a synthesized address record is the smallest of the ALIAS record's configured TTL value and the TTL values that are encountered while resolving the ALIAS target. Using this method, the returned TTL could be less than the ALIAS record's configured TTL, but it's never greater than the configured TTL.

The following example demonstrates how TTL is determined for the synthesized address records.

Suppose that the following records are configured in a Cloud DNS managed zone:

example.com.    3600    SOA      ns.com.  admin.example.com. (...)
                86400   NS       ns.com.
                6000    ALIAS    test-cname.example.com.
test-cname      3000    CNAME    address.example.com.
address         5000    A        1.2.3.4

A query to this zone for the A record at example.com returns a response similar to the following:

QUESTION SECTION
example.com.                  A

ANSWER SECTION
example.com.        3000      A      1.2.3.4

The TTLs encountered during resolution are 6000 (for the ALIAS record), 3000 (for the CNAME record), and 5000 (for the A record). Of these TTLs, 3000 is the smallest, so it's returned in the synthesized address record.

This example shows all records in the same zone for simplicity, but the TTL logic is identical for resolutions that jump through different zones.

Authoritative answer bit

The authoritative bit in the DNS response is based on the first name in the chain (the original qname), regardless of whether the data associated with that name is found on the server or was retrieved through an ALIAS record resolution.

Error Handling

It is possible that the Cloud DNS server is unable to resolve the canonical name associated with an ALIAS record. For example, the canonical name might not exist or its nameservers could be experiencing temporary failure.

If the ALIAS target resolution results in a NODATA response, which is an empty response with an OK RCODE, it returns a NODATA response to its client. ALIAS records respond to both A and AAAA queries, but it is possible that the ALIAS target only holds one of these types, which can lead to NODATA responses for the other type. This expected use case must not be treated as an error. On any other error, such as nonexistent or refused, the ALIAS record returns a SERVFAIL RCODE to the client.

Because returning SERVFAIL for all errors is opaque, to assist with debugging, an additional field is available in the DNS Cloud Logging to record the RCODE returned during ALIAS resolution. For a detailed description, Use logging and monitoring.

Import and export records

You can import and export records to and from a BIND zone file or a YAML file.

ALIAS records are not supported in BIND files because the ALIAS record type is not a standard DNS record type. While Cloud DNS recognizes these entries, other BIND-compatible DNS software might not.

ALIAS records are exported to YAML files, specific to Cloud DNS, in the following format:

kind: dns#resourceRecordSet
name: DNS Name
rrdatas: RR Data
ttl: TTL
type: ALIAS

Cloud DNS can import ALIAS records from a YAML file in the preceding format.

Security and privacy

Cloud DNS public name servers resolve the ALIAS target on your behalf, but you must ensure that you have configured the ALIAS target correctly; an incorrect ALIAS target could lead to your public records not working as needed or returning undesired IP addresses.

Monitor managed zones

Cloud DNS offers logging for all queries to managed zones through Logging. An optional field alias_query_response_code is available in the DNS query log to record information about the status of the ALIAS name resolution, since this information is not available from the DNS response.

For details, see Viewing logs.

The alias_query_response_code is only set if the query is resolved using an ALIAS record. A value of NoError means that the ALIAS record was resolved successfully, while any other value represents the error. A SERVFAIL value can represent any of the following issues:

  • Unreachable target nameserver
  • Target resolution timed out before finding a response
  • DNSSEC validation failed

The qtype field in the log entries does not have an ALIAS option. If an A or AAAA query is answered using an ALIAS record, the qtype field remains as A or AAAA.

What's next