DNS zones

A DNS zone is a logical space that combines the domain names of your resources and stores the necessary resource records. There are public and private zones. Regardless of the type, they have a hierarchy: a zone may have one or more subzones.

You can manage the hierarchy of cloud resources and route DNS requests. For example, you can create subzones for the production and test environments and, within them, subzones for applications, DB clusters, caching servers, and more.

The Yandex.Cloud resource model is used to control access to zones, subzones, and resource records.
If a public zone is registered in Yandex.Cloud:

• To create a subzone, you need the rights to manage the parent zone.
• To manage a subzone and its records, no rights to the parent zone are required.

This prevents the creation of subzones for the zones registered in Yandex.Cloud that users don't have access to.

You can create zones and subzones in different folders. To do this, assign a user or service account the editor role for the folder where the parent zone is located. For more information, see Access management.

For instance, the example.com. parent zone is located in a folder named my-folder. If you have the rights to manage this zone, you can create the subzones test.example.com. and production.example.com. in the my-test-folder and my-production-folder folders, respectively.

Public zones

Domain names in public zones are available from the internet. If you have a registered domain, you can delegate it. To do this, specify the addresses of Yandex.Cloud name servers in the NS records of your registrar:

• ns1.yandexcloud.net.
• ns2.yandexcloud.net.

You can't create public top-level domain (TLD) zones.

For security reasons, nested public zones can only be created by users and service accounts with the dns.editor, dns.admin, editor, or admin role in the folder where the parent public zone is located. Remember this when organizing the structure of your domain names. For more complex scenarios, contact support.

The service does not require confirmation of domain ownership. You can use a domain zone even if it's not registered to you. However, if its owner confirms their rights to the domain zone, you'll lose access to it. If you are the owner of the domain and the zone is already used by someone, contact support.

To request external domain names, we recommend using caching resolvers, such as systemd-resolved, dnsmasq, or unbound. They can reduce the number of queries and service usage costs.

Internal zones

Domain names from internal zones can only be used in Virtual Private Cloud (VPC) networks specified when creating a zone. Within internal zones, you can use the entire namespace in the subnets of the selected network, including internal. and ..

Service zones

Service zones can be created in VPC networks automatically. A list of these zones depends on the address range of the subnets used. For example:

These zones contain records with internal FQDNs of VMs and MDB database names, VM user names, and reverse records. You can't edit records that are created automatically, but you can manage records that are added manually.

To increase fault tolerance, some traffic can be routed to third-party recursive resolvers. To avoid this, contact support.