Start with the big picture: what Cloud DNS does, and what it does not do.

DNS, short for Domain Name System, is the internet’s phone book. It stores the link between a human-friendly domain name, such as a company’s website name, and the technical details that computers need, such as an IP address. An IP address is the numeric label that identifies a machine on a network, much like a phone number identifies a phone.

Cloud DNS is a managed, authoritative DNS service. The word authoritative is important. It means that Cloud DNS holds the official, final answers for the names you place in it. When another DNS server in the world wants to know where your website lives, it ends up asking a Cloud DNS server, and Cloud DNS replies with the answer that you configured.

Three jobs in one product

Cloud DNS does three related jobs. First, it hosts your public zones, so the whole internet can find your websites and services. Second, it hosts private zones, so only your own virtual networks inside Google Cloud can resolve your internal names, such as the name of a database used by your applications. Third, it offers forwarding and peering features, so you can connect Google Cloud with your office or data-centre DNS and share names across many projects.

What Cloud DNS is not

Cloud DNS does not sell or register domain names. A registrar is the company that registers a domain name for you and records you as its owner. Google offers a separate product for that, called Cloud Domains, and many other companies are registrars too. Cloud DNS also does not route your web traffic or balance load. It only answers the question “which address should I use for this name?” The actual traffic then flows to that address, perhaps a load balancer, a web server or a storage bucket.

To understand any tool, first feel the pain it was built to remove.

In the early days of the internet, the phone book was a single text file. Every computer kept a copy, and the file listed every machine name and its address. When a new machine joined, someone updated the master file and everybody downloaded it. This worked when there were a few hundred machines. It collapsed completely once there were millions. DNS was invented to replace the single file with a worldwide, shared, hierarchical system, where responsibility is divided among many organisations.

Running your own part of this system, however, has always been harder than it looks. A company that runs its own DNS servers must buy hardware, install software, keep it patched, place servers in at least two locations, and protect them from attackers. A DNS server that fails or slows down makes every website, app and email service behind it unreachable, even though those services are perfectly healthy. Many famous outages have been caused by DNS trouble rather than by the services themselves.

The four big headaches

Cloud DNS attacks these problems directly. Your zones are served from many locations at once, using a technique called anycast, so each user is answered by a nearby server. Google absorbs query floods with its huge capacity. Changes made through the console or interface spread to the serving servers without you managing any machine. Private zones and forwarding give cloud and office networks a shared naming system.

A handful of words explain almost everything in DNS. Learn them well and the rest becomes easy.

Domain, subdomain and the hierarchy

A domain name is read from right to left. The last part, such as com or org, is the top-level domain. To its left is the name a company registers, such as its brand. To the left of that you can add subdomains of your own, such as www or shop or api. The whole structure forms a tree, with the unseen root at the top. Each level is managed by a different organisation, and each knows only how to point to the next level down.

Zone

A zone is a portion of the DNS tree that one organisation manages as a single unit, together with all the records inside it. In Cloud DNS, a managed zone is the container in which you store the records for one domain, such as everything under your brand name. Each managed zone has a set of Google-run name servers assigned to it.

Resource record and record set

A resource record is a single entry in the zone, saying something like “the name www points to this address”. Records of the same name and type are grouped into a record set. For example, if your website has three server addresses, the three entries for the same name form one record set. The word type tells what kind of information the record holds, as the records chapter explains.

TTL

TTL stands for time to live. It is a number of seconds that tells other DNS servers how long they may remember an answer before asking again. A long TTL, such as a day, reduces load and speeds up lookups, but changes take a long time to be noticed everywhere. A short TTL, such as one minute, makes changes spread fast but increases the number of questions. Choosing TTLs wisely is one of the most practical skills in DNS.

Name server, resolver and the two kinds of DNS server

The delegation link

For the world to find your Cloud DNS zone, you must tell the parent level, through your registrar, that your zone is served by the name servers Google gave you. This link is called delegation. It is done by setting NS records at the registrar. If you create a perfect zone in Cloud DNS but never update the registrar, nobody on the internet will ever ask Cloud DNS about it. This is the single most common beginner stumble.

Cloud DNS offers several kinds of zones. Picking the right kind for each need is the first real design decision.

The names and options of zone types evolve as Google adds features, so confirm the current list in the official documentation. The following types are the core ones that every beginner should know.

flowchart TD
  Q1{"Must the whole internet resolve this name?"}
  Q1 -- "Yes" --> PUB["Public zone, then delegate at the registrar"]
  Q1 -- "No" --> Q2{"Are the answers hosted in Cloud DNS?"}
  Q2 -- "Yes" --> Q3{"Is another project owning the private zone?"}
  Q3 -- "Yes" --> PEER["Peering zone to the owner's network"]
  Q3 -- "No" --> PRIV["Private zone attached to your networks"]
  Q2 -- "No" --> Q4{"Do on-premises DNS servers hold the answers?"}
  Q4 -- "Yes" --> FWD["Forwarding zone to those servers"]
  Q4 -- "No" --> SD["Service Directory zone or other source"]
    

Split-horizon: one name, two answers

Sometimes you want the same name to give different answers depending on who asks. Visitors on the internet should reach a public web address, while your own staff inside the cloud network should reach a private internal address for the same name. You do this by creating a public zone and a private zone for the same domain. Machines inside the chosen networks see the private answers first, while the rest of the world sees the public ones. This arrangement is called split-horizon DNS.

Let us look at the main pieces that sit between a user’s question and your answer.

Cloud DNS has a control side, where you create zones and records, and a serving side, where Google’s servers answer questions. They are separate on purpose, so that busy question traffic never stops you from managing your data, and managing your data never slows down the questions. The diagram shows the typical public lookup path.

flowchart LR
  U["User Device"] --> RR["Recursive Resolver"]
  RR --> ROOT["Root and TLD Servers"]
  ROOT --> NS["Cloud DNS Anycast Name Servers"]
  NS --> ZS[("Zone Data Store")]
  ADM["Admin using Console, API or Terraform"] --> CP["Cloud DNS Control Plane"]
  CP --> ZS
  CP --> LOG["Cloud Logging and Audit Logs"]
  NS --> MON["Cloud Monitoring Metrics"]
    

Walking through the diagram

A user’s device asks a recursive resolver for a name. The resolver consults the root and top-level domain servers, which point it to the name servers listed for your domain at your registrar. Those listed servers are the Cloud DNS anycast name servers. With anycast, the same address is advertised from many places in the world, and the network automatically delivers each question to the nearest one. The nearest server reads the zone data and replies.

On the control side, an administrator uses the console, the command line, the programming interface or an infrastructure tool such as Terraform. Requests go to the control plane, which checks permissions, validates the change, stores it and distributes it to the serving servers. Every change is recorded in audit logs, and query activity can be measured through metrics and logs.

Key components in plain words

An important design idea hides in this picture: the data you manage is small and rarely changes, but the questions are huge in number and must be answered in milliseconds. Cloud DNS therefore copies your zone data to every serving location, so that each answer is a quick local lookup instead of a long trip.

Follow one single lookup from a browser to an answer and back.

Let us trace what happens when a visitor opens a web page whose name lives in a Cloud DNS public zone. The goal is to see where the time is spent, where answers are remembered and where things can go wrong.

sequenceDiagram
  participant B as Browser and Stub Resolver
  participant R as Recursive Resolver
  participant Root as Root Server
  participant TLD as TLD Server
  participant C as Cloud DNS Name Server
  B->>R: Where is www.example.com
  R->>R: Check cache, no fresh answer
  R->>Root: Who handles com
  Root-->>R: Ask the com servers
  R->>TLD: Who handles example.com
  TLD-->>R: Ask the Cloud DNS name servers
  R->>C: What is the address of www.example.com
  C-->>R: Address and TTL
  R-->>B: Address
  R->>R: Store answer for the TTL
    

Step by step

Why caching is everything

If every lookup went all the way to the authoritative server, the internet would melt. Caching is what makes DNS scale. A busy internet provider’s resolver might serve a popular name to a million customers while asking Cloud DNS only once every few minutes. This means that the number of queries Cloud DNS receives depends strongly on your TTL values and on how many different resolvers are asking.

Negative answers are cached too

When a name does not exist, the authoritative server says so, and resolvers remember that “no such name” answer for a period too, controlled by a value in the zone’s start-of-authority record. This is why a record that you create right after someone looked for it may not appear immediately for them. The earlier “not found” answer is still being remembered.

A few protocol details worth knowing

DNS questions usually travel over a lightweight transport called UDP, which sends a single small message and expects a single small reply, with no long conversation. When an answer is too large to fit, for example when DNSSEC signatures make it bigger, the resolver repeats the question over TCP, a transport that handles bigger, more careful exchanges. This is why firewalls must allow DNS on both transports, and why blocking TCP for DNS can cause strange failures that appear only for large answers.

Another detail is the response code, a short status in every answer. A normal success is called NOERROR. A name that does not exist is NXDOMAIN. A server that could not complete the job returns SERVFAIL, and a server that refuses to answer returns REFUSED. Learning these four codes helps you read monitoring graphs and tool output quickly, because they tell you whether the problem is a missing record or a broken path.

A name can point to many kinds of things. Each kind has its own record type.

A record’s type tells resolvers what kind of data to expect. Here are the types that nearly every team uses, explained in simple words. Cloud DNS supports these and more, so check the current list when you need something unusual.

A and AAAA records

These are the workhorses. An A record links a name to an IPv4 address, the older and most common address style. An AAAA record does the same for IPv6, the newer style with a vastly larger number of addresses. Many sites publish both, so devices on either kind of network can connect. A record set may hold several addresses, and resolvers return them in a rotating order, spreading visitors a little across the servers.

CNAME records and their rules

A CNAME is an alias. It says “this name is another name for that name”. When a resolver finds a CNAME, it simply repeats the question for the target name. CNAMEs are handy, for example to point a friendly name at a service provider’s long technical name that the provider may change. But they have strict rules. A name that has a CNAME cannot hold any other record types. And the very top of a zone, called the apex or root of the domain, cannot be a CNAME, because it must hold other required records such as NS and SOA.

MX and TXT for email

Email depends heavily on DNS. MX records list the mail servers that accept email for your domain, each with a priority number, where the lowest number is tried first. TXT records carry the text rules that fight spam and forgery, which are written in standard formats such as SPF, DKIM and DMARC. Getting these records right protects your domain from being used by scammers and helps your genuine emails reach the inbox.

NS and delegating a subdomain

Inside a zone, NS records can hand a subdomain over to another set of name servers. A large company might keep its main zone in one team’s hands and delegate the subdomain used by another team to a separate zone, so that each team manages its own records. This is called subdomain delegation. It keeps responsibilities clear and limits the damage of mistakes.

CAA, SRV and PTR

DNS can do more than give one fixed answer. It can choose the answer based on weight, location or health.

Normally a record set always returns the same data. With routing policies, Cloud DNS can pick different answers for different situations. The names and exact options are updated over time, so confirm the current list in the documentation. The three ideas below are the foundation.

flowchart TD
  Q["Question for shop.example.com"] --> P{"Routing policy type"}
  P -- "Weighted" --> W["Pick answer by weight: 90 percent primary, 10 percent canary"]
  P -- "Geolocation" --> G["Pick answer closest to the asking location"]
  P -- "Failover" --> H{"Is the primary healthy?"}
  H -- "Yes" --> PR["Return primary address"]
  H -- "No" --> BK["Return backup address"]
  W --> ANS["Answer with a short TTL"]
  G --> ANS
  PR --> ANS
  BK --> ANS
    

Health checks and failover

Failover policies rely on health checks, which are regular tests that ask a service “are you working?”. When the tests show a failure, Cloud DNS stops returning the unhealthy answer and returns the backup instead. Support for health checks depends on the kind of target, such as certain internal load balancers, so read the current documentation to learn which targets can be monitored this way. Keep in mind that failover through DNS is never instant, because resolvers keep old answers until their TTLs run out.

Choosing a TTL for steering

Routing policies work best with short TTLs, perhaps thirty to a few hundred seconds, so that changes of answer reach users within minutes. The price is a larger number of queries, and a slightly higher bill and load. For failover, a TTL of around one minute is a common balance. For stable names that never change, long TTLs are better.

The honest limits of DNS steering

• Resolvers are not users. Geolocation sees the location of the resolver, or sometimes a hint about the user’s network. A user who uses a distant public resolver may be treated as if they were far away.
• Caches delay changes. A few resolvers and applications ignore short TTLs or keep answers longer than they should, so some users linger on old answers.
• Weights are averages. A weight of ten percent is reached across many lookups, not each user’s next request. With few users, the split will look uneven.
• Not a load balancer. DNS picks an address once, and the user’s connection stays there. For fine-grained, instant balancing, use a real load balancer behind the DNS answer.

How a virtual machine decides where to ask, and in which order it consults your rules.

Inside Google Cloud, your virtual machines live in a VPC network, which is your private virtual network. Each machine is automatically set up to send its DNS questions to a built-in resolver, reached through a special internal address called the metadata server. You do not install anything. This built-in resolver reads your private zones, forwarding rules, peering settings and policies, and decides how to answer.

The order of resolution

The resolver follows a sensible order. The exact details may change, so read the current documentation, but the general idea is shown below.

flowchart TD
  VM["VM asks the metadata server resolver"] --> RP{"Matching response policy rule?"}
  RP -- "Yes" --> RPA["Return the override answer"]
  RP -- "No" --> ZN{"Matching private, forwarding or peering zone?"}
  ZN -- "Private zone" --> PZ["Answer from the private zone"]
  ZN -- "Forwarding zone" --> FZ["Forward to the listed name servers"]
  ZN -- "Peering zone" --> PE["Ask the peer network's DNS view"]
  ZN -- "None" --> INT{"Is it a Compute Engine internal name?"}
  INT -- "Yes" --> IN["Answer with the internal DNS"]
  INT -- "No" --> PUB["Resolve on the public internet"]
    

The pieces in the order

DNS policies

A DNS policy is a set of network-wide settings that changes how the resolver behaves. There are several kinds, and each is attached to chosen networks.

Compute Engine internal DNS

Every virtual machine automatically gets an internal DNS name. These names work only inside your VPC and are convenient for quick, small setups. They come in a zonal form, which includes the machine’s zone and project, and optionally in a global form. They are not meant to replace carefully designed private zones. For a serious application, create your own private zone with stable, meaningful names such as the name of the database service, and point those names at addresses you control, so that replacing a machine does not break the clients.

Cloud DNS for Kubernetes clusters

Google Kubernetes Engine clusters need their own DNS to let containers find each other by service name. Besides the classic in-cluster DNS software, Cloud DNS can provide this function as a managed service, either for one cluster or shared across a VPC. This can reduce the amount of DNS software your cluster must run and scale, and it makes cluster names resolvable from outside the cluster when you choose the wider scope. Check the current documentation to choose between the options.

Many companies live in two worlds at once. DNS is the glue that lets both worlds find each other.

Most large organisations still have servers in their own offices or data centres, called on premises, and they also run workloads in Google Cloud. A payroll application in the cloud may need to call a database in the office, and an office tool may need to reach a cloud service. Both sides must be able to resolve the other’s private names. This arrangement is called hybrid DNS.

flowchart LR
  subgraph ONP["On-Premises Network"]
    OD["On-premises DNS servers"]
    OH["Office server: db.corp.example"]
  end
  subgraph GC["Google Cloud VPC"]
    VMX["VM asks for db.corp.example"]
    FZN["Forwarding zone for corp.example"]
    IEP["Inbound forwarding entry point"]
    PZN["Private zone for cloud.example"]
  end
  VMX --> FZN
  FZN -->|"Over VPN or Interconnect"| OD
  OD --> OH
  OD -->|"Asks for names under cloud.example"| IEP
  IEP --> PZN
    

The two directions

What you need before it works

Sharing DNS across many projects: hub and spoke

Large companies have many projects and networks. Copying the same forwarding rules into every network is tedious and error-prone. A cleaner design is hub and spoke. One central network, the hub, owns the forwarding zones, the inbound policy and the shared private zones. Other networks, the spokes, use DNS peering to ask the hub for those names. Changes are then made in one place. Note that DNS peering is generally not transitive, which means a spoke can ask the hub, but cannot chain through the hub to reach another peer, so plan the shape of your design with that rule in mind.

A tiny typo in a DNS record can take a whole company offline. Safe habits matter more here than almost anywhere else.

DNS has a fierce character: a single wrong character in an address or a deleted record can make a website, an app and an email service vanish at the same time, and the damage spreads as caches refresh. Because the effects are broad and the cache delays make recovery slow, a careful change process is a core skill.

Changes are transactions

Cloud DNS applies edits as a single group, often called a change or a transaction. You can add and remove several records together, and either all of them take effect or none do. This is very useful, for example when you swap an old address for a new one in one atomic step, so there is never a moment when the name has no record.

A safe change routine

Infrastructure as code

Treating DNS as code is one of the best habits a team can adopt. Tools such as Terraform describe zones and records in text files kept in version control. Every change is reviewed, recorded and repeatable. If someone deletes a record by accident, the file shows what should exist, and the tool can restore it. Code also makes it easy to build the same setup in test and production, and to rebuild an entire zone after a disaster.

Import and export

Cloud DNS can import records from a standard zone file format and export them again. This is helpful when moving from another provider, taking a backup of your records or comparing environments. Keep a recent export of important zones stored safely outside the zone itself, so that even a deleted zone can be rebuilt quickly.

Naming and housekeeping

Plain DNS answers can be forged. DNSSEC adds a digital signature so that forgeries can be detected.

The original DNS was built on trust. A resolver accepted an answer if it looked right. Attackers learned to forge answers, a trick sometimes called cache poisoning, and send users to fake websites. DNSSEC, short for DNS Security Extensions, adds digital signatures to DNS data. A digital signature is a mathematical proof that the data came from the zone owner and was not altered on the way.

How the chain of trust works

The risk: a broken chain looks like an outage

DNSSEC protects users, but it also adds a way for you to cause a sudden outage. If the fingerprint at the registrar does not match the keys in Cloud DNS, validating resolvers will reject all your answers and your domain will appear to be down for many users, while non-validating resolvers still work and make the problem confusing to diagnose. Mismatches happen when keys are changed without updating the registrar, when a zone is moved to another provider with DNSSEC still enabled at the registrar, or when DNSSEC is turned off in the zone while the fingerprint is still published.

Should you enable it?

DNSSEC does not encrypt your queries and does not hide what names people look up. It only proves that answers are genuine. Think of it as an integrity feature, not a privacy feature.

Google secures the servers. You decide who may change your names and how you guard against name hijacking.

Cloud security follows a shared responsibility model. Google protects the DNS servers, the network and the service itself. You are responsible for who can edit your zones, how you protect your registrar account, and what names and data you publish. DNS is a favourite target because control of a name means control of where users, and often their email, are sent.

Identity and Access Management

Identity and Access Management, called IAM, decides which people and programs may do what. A role is a bundle of permissions. Cloud DNS offers roles such as an administrator who can manage zones and records, a reader who can only view them, and a peer role used for DNS peering. Follow the principle of least privilege: give each person only the role they need, at the narrowest level possible, such as one project or one zone. Developers might be allowed to edit records for a test zone, while only a few trusted engineers can change the production zone.

Threats to watch for

Good security habits

• Separate projects. Keep production zones in a tightly controlled project, separate from development.
• Audit logs. Make sure administrative actions are recorded and retained, so you can answer who changed what and when.
• CAA records. Publish records that list which certificate authorities may issue certificates for your domain.
• Change review. Treat DNS changes like code changes, with a second pair of eyes for production.
• Clean-up routine. Regularly remove records that point to retired services.
• Registrar protection. Turn on registrar locks and use a shared mailbox with strong authentication for the account owner.

DNS problems hide well, because everything above DNS blames DNS last. Good signals let you suspect it first.

Cloud DNS sends metrics, which are measured numbers over time, to Cloud Monitoring. It can also write logs to Cloud Logging, which are line-by-line records of events. Metrics show you how many questions arrive and how they are answered. Logs show the actual questions and who asked them. Audit logs record who changed what in your zones.

The signals worth watching

Query logging

For networks inside Google Cloud, you can enable query logging through a DNS policy, so each question made by your machines is recorded. For public zones, logging options exist too, and you should check the current documentation for what is offered. Query logs are very useful for investigating incidents, for finding which application asks for a missing name, and for spotting machines that contact suspicious domains. They can also grow large, so set sensible retention and consider the cost.

Alerts that help

• Query volume far above or below normal. Both directions deserve attention.
• Rising error answers. A sharp increase in SERVFAIL is almost always worth a look.
• Any change to production zones. A notification for each change gives the team visibility and a chance to catch surprises.
• External checks. Use probes from outside your network that look up your important names and compare the answers with what you expect.
• Domain expiry. Keep an alert for the registration expiry date of every domain. An expired domain is the most embarrassing outage of all.

Testing from the outside

Command-line tools such as dig and nslookup let you ask a DNS server a question and read the full answer, including the TTL. A powerful technique is to ask your Cloud DNS name servers directly, which shows what you have published, and then ask a public resolver, which shows what the world currently sees. If the two disagree, either caches have not expired yet, or delegation is wrong.

Cloud DNS itself is very reliable. Most DNS outages come from configuration, not from Google’s servers.

Google runs Cloud DNS across many locations with spare capacity and advertises a very strong availability promise. This means that if your domain is unreachable because of DNS, the cause is far more often a setting, a change or a dependency than a failure of the service. Learning the usual suspects will make you a fast troubleshooter.

A reliable troubleshooting path

Planning for the bad day

DNS is a dependency of everything, so protect it well. Keep zones in code, so they can be rebuilt. Keep exports as backups. Keep the registrar account safe, with more than one trusted administrator. Choose TTLs that allow you to recover in a reasonable time. For critical systems, consider using more than one DNS provider for a zone, a design called multi-provider DNS, which protects against a failure of any single provider, though it needs careful synchronisation of records and cannot use features unique to one provider.

DNS is already fast. Your choices decide how often a user waits for a lookup at all.

Cloud DNS answers quickly because of anycast and because each location holds the full zone data. From your side, the practical performance work is about how many lookups each page needs, and how long answers may be cached. Every unnecessary lookup adds a small delay, and because lookups happen at the start of every connection, small delays add up.

Choosing TTLs

There is no single perfect TTL. A good approach is to set a reasonable default, lower it before planned changes, and raise it afterwards. Remember that a very short TTL on a busy name multiplies query volume and your bill, while a very long TTL turns a small mistake into a long outage.

Ways to cut lookups

Application caching pitfalls

Not every program obeys TTLs. Some programming runtimes cache an address for the life of the process, so after a DNS change the program keeps talking to the old server until it is restarted. When you plan a migration, include the clients in your checklist. Find out how long each important client keeps lookups, and restart or reconfigure the long-lived ones when you cut over.

DNS is one of the cheapest parts of a cloud bill, but a few habits can still make it surprising.

Cloud DNS billing has a small number of parts. Prices change and vary, so always check the official pricing page. The description below explains how the bill is built, without quoting numbers.

What drives the bill up

• Very short TTLs on busy names. They multiply queries, because caches expire constantly.
• Query floods and random-name attacks. Attackers can send huge numbers of lookups for made-up names. Cloud DNS absorbs them, but you may still be billed for the volume, so watch for unusual spikes.
• Chatty applications. A program that looks up the same name for every request, with no caching, creates needless load.
• Forgotten zones. Test and old project zones continue to cost money each month.
• Verbose query logging. Logging every question for a busy network produces large volumes of data.

How to keep it under control

An honest look at what you gain and what you give up.

The big trade-offs in plain words

Simplicity against flexibility. Cloud DNS handles the common cases with very little effort. If you need very special behaviour, such as custom response logic written in code, a self-run DNS server may suit better, but then you own its uptime and security.

Speed of change against safety of caches. Short TTLs let you change quickly and recover quickly, but they cost more and create more load. Long TTLs are cheap and quick for users but make mistakes linger. You choose a balance for each name.

One provider against many. A single managed provider is simple to run. Using two providers protects against the loss of one but adds synchronisation work and limits you to features that both support.

Several products and approaches deal with names. Knowing the neighbours avoids confusion.

Comparing the main options

A common beginner confusion is to expect Cloud DNS to register domains or to load balance traffic. It does neither. The healthy picture is: a registrar owns the name, Cloud DNS answers questions about it, and a load balancer or server receives the traffic that the answer points to. A second confusion is to treat automatic internal names as a naming strategy. They work well for quick connections between a few machines, but real applications deserve deliberate private zones with stable names.

A pattern is a proven recipe for a common problem. These seven work especially well.

Stable names in front of changing things

One of the most valuable habits is to give every important service a stable, meaningful name, and never let clients depend on raw addresses. When a database moves or a server is replaced, only the record changes, and no client needs editing. This idea, called indirection, turns a risky change across many applications into a simple change in one place. It is the quiet reason why well-run systems can move quickly without breaking things.

Blue-green with DNS

In a blue-green release, two identical environments exist: the live one and the new one. DNS lets you move users from blue to green by changing a record, or gradually by weight. If green misbehaves, you move back. Because caches cause delays, pair this pattern with short TTLs, and keep the blue environment running until the old TTL has fully expired.

An anti-pattern is a habit that looks sensible at first and causes pain later.

A checklist to read before your first production launch.

Best practices

Common mistakes

How organisations typically use Cloud DNS in production.

The architectures of particular companies change often and are seldom published in detail, so the examples below describe common industry patterns, not claims about any one named customer. Where a pattern is tied to something Google has said publicly, that is noted.

Moving a live domain’s DNS is one of the few jobs where caution is the whole skill.

Moving a zone from another provider to Cloud DNS can be done without any downtime, because DNS lets two sets of servers hold the same records at the same time. The secret is to prepare the new zone completely, verify it, and only then change the delegation, while keeping the old zone alive until old caches expire.

A calm migration path

Migrating private names into Google Cloud

If your internal names currently live on office DNS servers, you do not have to move them all at once. Start by creating forwarding zones so cloud machines can use the existing names. Then, as services move to the cloud, create private zones for the new names, and gradually reduce what the office servers hold. Keep a clear record of which side owns each name at each stage.

Keeping current

Cloud DNS gains features and changes details over time, such as new routing policy options, logging features, zone types and limits. Make it a habit to read the release notes a few times a year, and to review the current documentation before large projects. Check the quotas for the number of zones and records, since very large setups can approach them.

Quick answers to the questions beginners ask most often.

If you remember only one page of this guide, make it this one.

Cloud DNS is Google Cloud’s managed, authoritative DNS service. It hosts public zones for the internet, private zones for your networks, and forwarding and peering features that connect cloud and office networks. It answers from many locations at once, so lookups are quick and the service stays available. Your own work lies in careful delegation, sensible TTLs, safe change habits, strict access control, protected registrar accounts and good monitoring, because most DNS outages come from configuration and not from the servers.