This document provides key terminology that applies to Cloud DNS.Review these terms to better understand how Cloud DNS works andthe concepts on which it is built.

The Cloud DNS API is built aroundprojects,managed zones,record sets,and changes to record sets.

project

A Google Cloud console project is a container for resources, a domain foraccess control, and the place wherebilling is configuredand aggregated. For more details, seeCreating and managing projects.

managed zone

The managed zone holds Domain Name System (DNS) records for the same DNSname suffix (such asexample.com). A project can have multiple managedzones, but they must each have a unique name. In Cloud DNS, themanaged zone is the resource that models aDNS zone.

All records in a managed zone are hosted on the same Google-operated nameservers. These name servers respond to DNS queries against your managed zoneaccording to how you configure the zone. A project can contain multiplemanaged zones.Charges accrue for each zone for each day that the managedzone exists. Managed zones supportlabelsthat you can use to help organize your billing.

public zone

A public zone is visible to the internet. Cloud DNS has publicauthoritative name servers that respond to queries about public zonesregardless of where the queries originate. You can create DNS records in apublic zone to publish your service on the internet. For example, you mightcreate the following record in a public zoneexample.com for your publicwebsitewww.example.com.

DNS name	Type	TTL (seconds)	Data
www.example.com	A	300	198.51.100.0

Cloud DNS assigns a set of name servers when a public zone iscreated. For the DNS records in a public zone to be resolvable over theinternet, you mustupdate the name serversetting of your domain registration at yourregistrar.

Note: Cloud DNS public zones are authoritative, and NS (name server)and SOA resource records are at the zone apex. You cannot delete thesetypes of records. For details, seeRFC 1034.

For more information about how to register and set up your domain, seeSetting up a domain usingCloud DNS.

private zone

Private zones enable you to manage custom domain names for your virtualmachine (VM) instances, load balancers, and other Google Cloud resources withoutexposing the underlying DNS data to the public internet. A private zone is acontainer of DNS records that can only be queried by one or moreVirtual Private Cloud (VPC) networks that you authorize.

You must specify the list of authorized VPC networks that canquery your private zone when you create or update it. Only authorized networksare allowed to query your private zone; if you do not specify anyauthorized networks, you cannot query the private zone at all.

You can use private zones withShared VPC. Forimportant information about using private zones with Shared VPC, seeShared VPC considerations.

Private zones do not support DNS security extensions (DNSSEC) or customresource record sets of type NS. Requests for DNS records in private zonesmust be submitted through the metadata server169.254.169.254, which is thedefault internal name server for VMs created fromGoogle-supplied images.

You can submit queries to this name server from any VM that uses an authorizedVPC network. For example, you can create a private zone fordev.gcp.example.com to hostinternal DNS records for experimental applications. The following table showsexample records in that zone. Database clients can connect to the databaseserverdb-01.dev.gcp.example.com by using its internal DNS name instead ofits IP address. Database clients resolve this internal DNS name by using thehost resolver on the VM, which submits the DNS query to the metadata server169.254.169.254. The metadata server acts as a recursive resolver to queryyour private zone.

DNS name	Type	TTL (seconds)	Data
db-01.dev.gcp.example.com	A	5	10.128.1.35
instance-01.dev.gcp.example.com	A	50	10.128.1.10

Private zones enable you to createsplit horizon DNSconfigurations. This is becauseyou can create a private zone with a different set of records, which overridesthe entire set of records in a public zone. You can thencontrol which VPC networks query the records in the privatezone. For example, seeoverlapping zones.

Service Directory

Service Directory is a managed service registry forGoogle Cloud that enables you to register and discover services by usingHTTP or gRPC (using its Lookup API) in addition to using traditional DNS.You can use Service Directory to register bothGoogle Cloud and non-Google Cloud services.

Cloud DNS enables you to createService Directory-backed zones, which are a type of privatezone containing information about your services and endpoints. You don't addrecord sets to the zone; rather, they're inferred automatically based on theconfiguration of the Service Directory namespace associatedwith the zone. For more information about Service Directory,see theService Directory overview.

When youcreate a Service Directory-backedzone, you cannot addrecords to the zone directly; the data comes from the Service Directoryservice registry.

Cloud DNS and reverse lookup for non-RFC 1918 addresses

By default, Cloud DNS forwards requests for PTR records of non-RFC1918 addresses through the public internet. However, Cloud DNS alsosupports reverse lookup of non-RFC 1918 addresses by using private zones.

After you configure a VPC network to use non-RFC 1918addresses, you mustconfigure a Cloud DNS private zone as amanaged reverse lookup zone. Thisconfiguration enables Cloud DNS to resolve non-RFC 1918 addresseslocally instead of sending them over the internet.

When you create a managed reverse lookup DNS zone, you cannot addrecords to the zone directly; the data comes from the Compute EngineIP address data.

Cloud DNS also supports outbound forwarding to non-RFC 1918addresses by privately routing those addresses within Google Cloud.To enable this type of outbound forwarding, you must configurea forwarding zone with specific forwarding path arguments. For details,seeForwarding targets and routing methods.

forwarding zone

A forwarding zone is a type of Cloud DNS managed private zone thatforwards requests for that zone to the IP addresses of its forwarding targets.For more information, seeDNS forwarding methods.

When youcreate a forwarding zone,you cannot add records to the forwarding zone directly; the datacomes from one or more configured target name servers or resolvers.

peering zone

A peering zone is a type of Cloud DNS managed private zone thatfollows the name resolution order ofanother VPC network. You can use it to resolve the names thatare defined in the other VPC network.

When youcreate a DNS peering zone, youcannot add records to the zone directly; the data comes from theproducer VPC network according to itsNameresolution order.

response policy

A response policy is a Cloud DNS private zone concept that containsrules instead of records. These rules can be used to achieve effects similarto the DNSresponse policy zone(RPZ) draft concept(IETF).The response policy feature lets you introduce customized rules in DNSservers 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, seeManaging response policies and rules.

A response policy is different from an RPZ, which is an otherwise normal DNSzone with specially formatted data that causes compatible resolvers to dospecial things. Response policies are not DNS zones and are managedseparately in the API.

zone operations

Any changes that you make to managed zones in Cloud DNS arerecorded in theoperations collection, whichlists managed zone updates (modifying descriptions or DNSSEC state orconfiguration). Changes to record sets inside a zone are stored separatelyin resource record sets, described later in this document.

Internationalized Domain Name (IDN)

AnInternationalized Domain Name (IDN)is an internet domain name that allows people all over the world to use alanguage-specific script or alphabet, such as Arabic, Chinese, Cyrillic,Devanagari, Hebrew, or the Latin alphabet-based special characters indomain names. This conversion is implemented by usingPunycode,which is a representation of Unicode characters that use ASCII. Forexample, an IDN representation of.ελ is.xn--qxam. Some browsers,email clients, and applications might recognize it and render it as.ελon your behalf. TheInternationalizing Domain Names in Applications (IDNA)standard only allows for Unicode strings that are short enough to berepresented as a valid DNS label. For information about how you can use IDNwith Cloud DNS, seeCreating zones with Internationalized Domain Names.

registrar

Adomain name registraris an organization that manages the reservation of internet domain names.A registrar must be accredited by a generic top-level domain (gTLD) registryor a country code top-level domain (ccTLD) registry.

internal DNS

Google Cloud creates internal DNS names for VMs automatically, even ifyou do not use Cloud DNS. For more information about internal DNS,see theinternal DNS documentation.

delegated subzone

DNS lets the owner of a zone delegate a subdomain to a different nameserver by using NS (name server) records. Resolvers follow these records andsend queries for the subdomain to the target name server specified in the delegation.

Note: Private zones do not support delegation of subdomains to differentname servers by using NS records.

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 thecurrent state of the DNS records that make up a managed zone. You can reada resource record set, but you do not modify it directly. Rather, you editthe resource record set in a managed zone by creating aChange requestin thechanges collection. You can alsoedit 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 thetime that they take effect at your authoritative DNS servers. Forinformation about how to manage records, seeAdd, modify, and delete records.

Note: Consistent with DNS industry practices, Cloud DNSname servers now randomize the order of the resource record sets whenmultiple records exist in a set. This is normal DNS behavior and applies toboth publicand private Cloud DNS zones. Caching resolvers in the path might stillreturn record sets as originally cached, and not re-randomize the order onsubsequent responses.

resource record set change

To make a change to a resource record set, submit aChange or aResourceRecordSetsrequest containing additions or deletions. Additions anddeletions can be done in bulk or in a single atomic transaction, and takeeffect 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.2ADD  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.

SOA serial number format

The serial numbers of SOA records created in Cloud DNSmanaged zones monotonically increase with each transactional change to azone's record sets made by using thegcloud dns record-sets transactioncommand. However, you are free to manually change the serial number of anSOA record to an arbitrary number, including an ISO 8601-formatted date asrecommended in RFC 1912.

For example, in the following SOA record, you canchange the serial number directly from the Google Cloud console byentering the desired value into the third space-delimited field of therecord:

ns-gcp-private.googledomains.com. cloud-dns-hostmaster.google.com.[serial number] 21600 3600 259200 300`

DNS server policy

A DNS server policy lets you access name resolution servicesprovided by Google Cloud in a VPC network with inboundforwarding, or supersede the VPCname resolutionorder with an outbound serverpolicy. For more information, seeDNS server policies.

domain, subdomain, and delegation

Most subdomains are only records in the managed zone for the parent domain.Subdomains that aredelegated by creating NS (name server) records intheir parent domain's zone need to have their own zones as well.

Create managed public zones for parent domains in Cloud DNSbefore creating any public zones for their delegated subdomains.Do this even if you are hosting the parent domain on another DNS service.If you have several subdomain zones but don't create the parent zone,it can be complicated to create the parent zone later if you decide to moveit to Cloud DNS. For moreinformation, seeName server limits.DNSSEC

TheDomain Name System Security Extensions (DNSSEC)is a suite of Internet Engineering Task Force (IETF) extensions to DNS whichauthenticate responses to domain name lookups. DNSSEC does not provide privacyprotections for those lookups, but prevents attackers from manipulating orpoisoning the responses to DNS requests.

DNSKEYs collection

The DNSKEYs collection holds the current state of the DNSKEY records used tosign a DNSSEC-enabled managed zone. You can only read this collection; allchanges to the DNSKEYs are made by Cloud DNS. The DNSKEYscollection has all the information that domain registrars require toactivate DNSSEC.