Yandex Cloud DNS setup: where name resolution breaks
Name resolution failure rarely looks like a complete outage: a service cannot find a neighboring service, certificate issuance hangs on domain validation, an application switches to a standby node, and ten minutes later everything works on its own.
Application logs are clean — the name resolved, but not to where it was expected, and this is usually reached only after a night of investigation.
Most often the cause is one of four points. Stale and duplicate records remain from manual edits in the panel: an address pointing to a decommissioned node, two records for one name with different values, a forgotten validation record that blocks certificate issuance.
The second point is an incorrect zone: a domain is accidentally described in a public zone instead of a private one, or a private zone overlaps external names inside the network, and internal services start going to the wrong place.
The third point is response cache. While TTL is cranked up, clients, internal resolvers, and applications themselves hold old addresses, and a change “does not apply” for hours.
The fourth is the lack of change history: a record was edited manually, there is nothing to roll back to, and the next deployment silently overwrites it.
We break down how DNS configuration in the cloud is handled with a declarative description: zones and records in Yandex Cloud DNS live in a repository, go through review, are applied according to a plan with a deliberate TTL, and state is reconciled with the description. Then name resolution failures are localized in minutes, not over a night of testing hypotheses.
What a managed name service provides: speed and predictability
A managed zone is a provider resource, not a file on one machine: records are replicated, and resolution comes from the point of presence closest to the client.
Taking a name server out of service does not require changes on our side, so planned maintenance does not turn into an outage window. We move zones to Yandex Cloud and immediately fix the parameters on which failure behavior depends.
Name response speed is determined by resolver proximity and the chosen TTL.
With a reasonable value, most queries are served from cache, and the client does not wait for a full recursive traversal — the effect is visible in the share of cached responses and in connection establishment time.
Resolution fault tolerance relies on multiple name servers across availability zones. Losing one point does not cause a failure: queries go to the remaining ones, and the share of failed resolutions remains at baseline. We measure it before and after migration and compare, rather than relying on impressions.
Record change history addresses the most impactful class of errors — a manual edit with no trace.
Every change preserves the author and time, rollback to the previous state takes minutes, and the records themselves live in a declarative description (Terraform) with review before application. It also handles domain validation for certificates that require a record in the same zone.
Public and private zones: comparing organization options
The split into public and private zones solves not the question of “where to store records” but the question of visibility: which names resolve from the internet and which only inside the cloud network.
These are two independent entities with separate lifecycles, and they cannot be combined in one zone: private records must not be visible externally, while public ones must be.
In practice, teams choose between four schemes. Below are the applicability conditions and what each one limits.
| Scheme | When it fits | Limitations |
|---|---|---|
| Single public zone | Website, API, and storefront are accessible from the internet; no internal names | Internal names go into public resolution; no boundary between external and internal traffic |
| Private zone inside the network | Internal services, databases, queues, access by name | Not resolvable from outside; records are visible only from attached networks; each network has its own zone |
| Hybrid zone scheme | Public external perimeter plus a closed core — a typical product case | Identical names live in two zones: configuration desynchronization causes rare and difficult failures |
| Your own name servers | Full control over the zone is needed, nonstandard records, existing own name infrastructure | Availability and fault tolerance are on you; delegation, zone transfer, and resolution depend on your site |
Hybrid is what almost all product environments arrive at: a minimum of records is exposed externally, internal names live in a private zone attached to specific networks.
The option determines not convenience but failure boundaries: the more public the zone, the higher the impact of a record error.
Implementation procedure: from zone inventory to handover
Implementation is split into stages so that every change can be verified and rolled back without waiting for TTL expiry.
First we capture the current state and record owners, then migrate zones, and only then switch traffic — at each step there is a rollback point and a criterion that shows it is safe to proceed.
-
Record inventory. We export all records from existing zones — A, AAAA, CNAME, MX, TXT, SRV, CAA — and compare them with actual traffic and active services. For each record, we find an owner: without someone responsible for its purpose, the record does not go into migration.
-
Zone scheme. We mark what stays in the public zone and what goes to the private one — internal services, databases, service names. We attach private zones to specific networks so internal names do not answer externally.
-
Configuration as code. We describe zones and records declaratively, store state remotely, and changes go through review. We import existing records so the description matches reality rather than diverging from it.
-
TTL reduction and window preparation. On records that will change, we reduce TTL in advance — the rollback window shrinks from hours to minutes. This is done before switching; otherwise the return speed is dictated by the old resolver cache.
-
Controlled switchover. First we migrate a test domain and make sure responses match the reference, then we change delegation for the production zone. The old zone remains operational — both sets of servers answer identically.
-
Post-switch verification. We query records from external resolvers and from each network, compare against the inventory export, and check mail records and certificate issuance: domain validation and CAA must pass without manual changes.
-
Rollback and handover. Until the end of the observation window, we keep the old zone up to date; rollback means returning delegation. For operations we hand over accesses, the procedure for changes via code, response monitoring, and control over certificate renewal deadlines.
What we hand over: configurations, diagrams, procedures
We hand over not an archive of files but a working configuration that can be deployed from scratch and then maintained without us.
All artifacts are stored in the repository and are checked before application, so the state of zones in Yandex Cloud DNS does not diverge from what is described in code.
- Declarative description of zones and records — files with public and private zones, records, TTL values, and environment bindings. Any change goes through review and plan validation; manual changes in the control panel are excluded.
- Network and relationship diagram — how zones relate to networks, subnets, and services, where name resolution goes external and where it remains inside the environment. Points where conflicts most often arise are marked separately.
- Access rules for zone management — roles for engineers, separate service accounts for automation, and separation of rights between production and test environments.
- Environment separation — parameters and states for production and staging are separated, so experiments do not enter production zones and do not break name resolution for users.
- Documentation — the procedure for adding a record, issuing and renewing certificates, and checking that the description matches the actual state.
- Incident response procedure — monitoring checkpoints, the procedure for rolling back to the previous configuration, escalation criteria, and the area of responsibility on the customer's side.
- Handover procedure — the set of accesses, the sequence for starting from scratch, and a verification scenario by which your team confirms that the infrastructure works without us.
Case study: zone migration without downtime and growth in successful responses
The customer is a product service with several dozen subdomains and internal infrastructure in two networks. Public zones lived with the old registrar, private ones in hand-written configurations on two servers, and certificates were renewed manually. Editing one record took half a day and required manual reconciliation between environments.
Baseline before migration: the share of successful responses stayed at 96–97%, after each zone change name resolution dropped to 40 seconds, and some services could not find internal names at all.
Support received about thirty tickets per month saying “the service won't open,” and they were handled manually — there could be three causes: cache, an outdated record, or an expired certificate.
What we changed
We moved zones and records to Yandex Cloud DNS and described them in Terraform: public ones declaratively, private ones by attachment to networks so internal names resolve only inside the environment.
One day before the switchover, we reduced TTL to one minute, let old caches expire, and only then changed the name servers at the registrar. Domain validation for certificates was moved to DNS records, and renewal became automatic.
Baseline after: the share of successful responses is 99.9% and above, and name resolution takes tens of milliseconds. The switchover went without downtime — the window took 40 minutes, and throughout that time the service responded correctly through both sets of name servers.
Tickets saying “it won't open” dropped to isolated cases per month, and almost all were from external networks where the provider's cache lives its own life.
How a private DNS zone differs from a public one
A public zone answers queries from the internet: its records are served by authoritative name servers, and the parent zone delegates the domain to them. A private zone lives inside the cloud network — only queries from there see it, and it has no external delegation.
Therefore a domain with the same name can exist in two zones at once and they do not conflict with each other.
Record visibility scope is the main difference. In a public zone, any external resolver will get the address, and hiding some records will not work: subdomains sooner or later end up in public lists.
In a private one, the name does not exist for the internet — from outside the query returns a failure, while from inside it returns the needed address.
Internal service names are built on the private zone. A name like db.prod.internal is created alongside the network and does not depend on the addresses of specific instances: when replacing or scaling, only the record changes, while application configurations remain the same. The same name is used in access rules between services.
When external and internal resolution are separated, one name can answer with different addresses — externally to the entry point, internally directly to the service.
This way service traffic does not go through the external perimeter, and the environment choice is set by the zone rather than by a code change.
In Yandex Cloud DNS, both zones are described declaratively together with network attachment, so the state is reproducible.
Certificates for internal names are issued by a private certificate authority, for public ones by domain ownership validation; both expire on a schedule, so we set renewal as a regular task rather than a manual operation.
Frequently asked questions: record TTL, migration, certificates
Zone configuration is only the beginning: what matters more is how it lives in operations. Below are answers to four questions most often asked before taking a site into operation.
We describe zones, records, certificates, and permissions as code and store them in a repository — the zone state can always be compared with the description and rolled back. This also removes the main pain of handover: a new engineer sees why a record looks the way it does.
What record TTL should I choose?
Before a planned switchover, TTL is reduced in advance so old addresses stop settling in resolver caches, and after stabilization it is returned to a calm value. Keeping it low constantly is not worth it: the number of queries to the zone grows. For static records, hours are used; for records behind a load balancer, minutes.
How do I migrate to a new site without downtime?
First we import current records into the description, reconcile discrepancies, and only then switch name servers, checking resolution from several networks. We keep the old environment until the longest record TTL expires, and only then decommission it. Rollback means restoring the previous zone description.
How do I avoid missing domain and certificate renewals?
We set certificate issuance and renewal to automation with validation checks in the test environment, not on the expiration day. For domains and zones, we set up notifications several weeks before the deadline so renewal does not turn into emergency work on weekends.
What is included in operations handover?
Zone diagram, description in the repository, procedures for certificate issuance and record changes, access separation, and rollback instructions. We conduct a walkthrough with your team and stay in touch for the period until on-call duty is transferred to you.
Let's discuss your zone scheme and come back with a work plan
So that the work estimate is not a guess, we need only the current picture of zones: which domains are served, where zones are public, and where they are private inside Yandex Cloud.
If the configuration is already described as code, send the repository or an export; if records are maintained manually, a list and relationship diagram will suffice.
On the call we will go over:
- which zones are public, which are private, and whether they duplicate each other;
- how certificates are issued and where their expiration dates fall;
- where manual changes remain and what prevents moving them into the infrastructure description;
- how delegation is configured and where NS records point;
- which services depend on DNS and what will happen if the zone becomes unavailable;
- whether protection against response spoofing and integrity control are needed;
- how access rights to zones are separated within the team.
What to send in advance:
- a list of domains and subdomains with their purpose;
- a network diagram: where services live and who needs internal names;
- current configurations or a zone export;
- a list of certificates and where they are used.
After that, we will come back with an estimate and implementation plan: the order of zone migration, the method of configuration description, verification points, and rollback procedure. Describe the task in two paragraphs — that will be enough to state the timelines and scope of work.