This document provides key terminology that applies to Cloud DNS. Review these terms to better understand how Cloud DNS works and the concepts on which it is built.
The Cloud DNS API is built around projects, managed zones, record sets, and changes to record sets.
- delegated subzone
DNS lets the owner of a zone delegate a subdomain to a different name server by using NS (name server) records. Resolvers follow these records and send queries for the subdomain to the target name server specified in the delegation.
- DNS server policy
A DNS server policy lets you access name resolution services provided by Cloud de Confiance in a VPC network with inbound forwarding, or supersede the VPC name resolution order with an outbound server policy. For more information, see DNS server policies.
- DNSKEYs collection
The DNSKEYs collection holds the current state of the DNSKEY records used to sign a DNSSEC-enabled managed zone. You can only read this collection; all changes to the DNSKEYs are made by Cloud DNS. The DNSKEYs collection has all the information that domain registrars require to activate DNSSEC.
- DNSSEC
The Domain Name System Security Extensions (DNSSEC) is a suite of Internet Engineering Task Force (IETF) extensions to DNS which authenticate responses to domain name lookups. DNSSEC does not provide privacy protections for those lookups, but prevents attackers from manipulating or poisoning the responses to DNS requests.
- domain, subdomain, and delegation
Most subdomains are only records in the managed zone for the parent domain. Subdomains that are delegated by creating NS (name server) records in their parent domain's zone need to have their own zones as well.
- forwarding zone
A forwarding zone is a type of Cloud DNS managed private zone that forwards requests for that zone to the IP addresses of its forwarding targets. For more information, see DNS forwarding methods.
When you create a forwarding zone, you cannot add records to the forwarding zone directly; the data comes from one or more configured target name servers or resolvers.
- internal DNS
Cloud de Confiance creates internal DNS names for VMs automatically, even if you do not use Cloud DNS. For more information about internal DNS, see the internal DNS documentation.
- Internationalized Domain Name (IDN)
An Internationalized Domain Name (IDN) is an internet domain name that allows people all over the world to use a language-specific script or alphabet, such as Arabic, Chinese, Cyrillic, Devanagari, Hebrew, or the Latin alphabet-based special characters in domain names. This conversion is implemented by using Punycode, which is a representation of Unicode characters that use ASCII. For example, an IDN representation of
.ελis.xn--qxam. Some browsers, email clients, and applications might recognize it and render it as.ελon your behalf. The Internationalizing Domain Names in Applications (IDNA) standard only allows for Unicode strings that are short enough to be represented as a valid DNS label. For information about how you can use IDN with Cloud DNS, see Creating zones with Internationalized Domain Names.- managed zone
The managed zone holds Domain Name System (DNS) records for the same DNS name suffix (such as
example.com). A project can have multiple managed zones, but they must each have a unique name. In Cloud DNS, the managed zone is the resource that models a DNS zone.All records in a managed zone are hosted on the same Google-operated name servers. These name servers respond to DNS queries against your managed zone according to how you configure the zone. A project can contain multiple managed zones. Charges accrue for each zone for each day that the managed zone exists. Managed zones support labels that you can use to help organize your billing.
- registrar
- A domain name registrar is an organization that manages the reservation of internet domain names. A registrar must be accredited by a generic top-level domain (gTLD) registry or a country code top-level domain (ccTLD) registry.
- resource record set change
To make a change to a resource record set, submit a
Changeor aResourceRecordSetsrequest containing additions or deletions. Additions and deletions can be done in bulk or in a single atomic transaction, and take effect at the same time in each authoritative DNS server.For example, if you have an A record that looks like this:
www A 203.0.113.1 203.0.113.2
And you run a command that looks like this:
DEL www A 203.0.113.2 ADD www A 203.0.113.3
Your record looks like this after the bulk change:
www A 203.0.113.1 203.0.113.3
The ADD and DEL happen simultaneously.
- resource record sets
A resource record set is a collection of DNS records with the same label, class, and type, but with different data. Resource record sets hold the current state of the DNS records that make up a managed zone. You can read a resource record set, but you do not modify it directly. Rather, you edit the resource record set in a managed zone by creating a
Changerequest in the changes collection. You can also edit the resource record sets by using theResourceRecordSetsAPI. The resource record set reflects all your changes immediately. However, there is a delay between when changes are made in the API and the time that they take effect at your authoritative DNS servers. For information about how to manage records, see Add, update, and delete records.- response policy
A response policy is a Cloud DNS private zone concept that contains rules instead of records. These rules can be used to achieve effects similar to the DNS response policy zone (RPZ) draft concept (IETF). The response policy feature lets you introduce customized rules in DNS servers within your network that the DNS resolver consults during lookups. If a rule in the response policy affects the incoming query, it is processed. Otherwise, the lookup proceeds normally. For more information, see Managing response policies and rules.
A response policy is different from an RPZ, which is an otherwise normal DNS zone with specially formatted data that causes compatible resolvers to do special things. Response policies are not DNS zones and are managed separately in the API.
- Service Directory
Service Directory is a managed service registry for Cloud de Confiance that lets you register and discover services by using HTTP or gRPC (using its Lookup API) in addition to using conventional DNS. You can use Service Directory to register both Cloud de Confiance and non-Cloud de Confiance services.
Cloud DNS lets you create Service Directory-backed zones, which are a type of private zone containing information about your services and endpoints. You don't add record sets to the zone; rather, they're inferred automatically based on the configuration of the Service Directory namespace associated with the zone. For more information about Service Directory, see the Service Directory overview.
When you create a Service Directory-backed zone, you cannot add records to the zone directly; the data comes from the Service Directory service registry.
- SOA serial number format
The serial numbers of SOA records created in Cloud DNS managed zones monotonically increase with each transactional change to a zone's record sets made by using the
gcloud dns record-sets transactioncommand. However, you are free to manually change the serial number of an SOA record to an arbitrary number, including an ISO 8601-formatted date as recommended in RFC 1912.For example, in the following SOA record, you can change the serial number directly from the Cloud de Confiance console by entering the selected value into the third space-delimited field of the record:
ns-gcp-private.googledomains.com. cloud-dns-hostmaster.google.com. [serial number] 21600 3600 259200 300`
- zone operations
Any changes that you make to managed zones in Cloud DNS are recorded in the operations collection, which lists managed zone updates (modifying descriptions or DNSSEC state or configuration). Changes to record sets inside a zone are stored separately in resource record sets, described later in this document.