Зоны DNS
Зона DNS — это логическое пространство, которое объединяет доменные имена ваших ресурсов и содержит нужные ресурсные записи. Зоны бывают публичные и внутренние. Вне зависимости от типа, они образуют иерархию: у зоны может быть одна или несколько подзон. Отдельную иерархию образуют обратные зоны.
Вы можете управлять иерархией облачных ресурсов и маршрутизировать DNS-запросы. Например, создать подзоны для основной и тестовой сред, а внутри них подзоны для приложений, кластеров БД, кеширующих серверов и т. д.
Для управления доступом к зонам, подзонам и ресурсным записям используется ресурсная модель Yandex Cloud.
Если публичная зона зарегистрирована в Yandex Cloud:
- для создания подзоны требуются права на управление родительской зоной;
- для управления подзоной и записями в ней права на родительскую зону не требуются.
Это предотвращает создание подзон для зарегистрированных в Yandex Cloud зон, к которым у пользователей нет доступа.
Можно создавать зоны и подзоны в разных каталогах. Для этого назначьте пользователю или сервисному аккаунту роль editor на каталог, в котором находится родительская зона. Подробнее см. в разделе Управление доступом в Cloud DNS.
Например, родительская зона example.com. находится в каталоге my-folder. Тогда, при наличии прав на управление этой зоной, подзоны test.example.com. и production.example.com. могут быть созданы в каталогах my-test-folder и my-production-folder соответственно.
Публичные зоны
Доменные имена в публичных зонах доступны из интернета. Если у вас есть зарегистрированный домен, вы можете делегировать его. Для этого укажите адреса серверов имен Yandex Cloud в NS-записях вашего регистратора:
ns1.yandexcloud.net.ns2.yandexcloud.net.
Если у вас до этого уже было настроено делегирование домена, то удалите прочие NS-записи.
Примечание
Не забудьте перенести ресурсные записи (A, CNAME, TXT и прочие, за исключением NS) с предыдущих серверов в новую публичную зону.
Публичные зоны верхнего уровня (TLD-зоны), такие как ru., com., org. и т.п., создавать нельзя.
Из соображений безопасности, вложенные публичные зоны могут создавать только пользователи и сервисные аккаунты, у которых есть роль dns.editor, dns.admin, editor или admin в каталоге с родительской публичной зоной. Учитывайте это при организации структуры ваших доменных имен. Для организации более сложных сценариев обратитесь в техническую поддержку.
Сервис не требует подтверждения владения доменом. Вы можете использовать доменную зону, даже если она не зарегистрирована на вас. Если вы делегировали свой домен в Cloud DNS, но не создали соответствующей публичной DNS-зоны в Cloud DNS — такую зону может занять кто-то другой. Поэтому рекомендуем сначала создать публичную DNS-зону в Cloud DNS, а уже затем выполнять делегирование.
Примечание
Если вашу публичную DNS-зону заняли, обратитесь в техническую поддержку, чтобы подтвердить свои права на зону.
Запросы к публичным DNS-зонам и запросы внешних DNS-имен с ваших виртуальных машин являются публичными DNS-запросами. Сервис Cloud DNS используется для публичных DNS-запросов, даже в том случае, если в вашем облаке нет никаких DNS-зон, кроме сервисных.
Рекомендуем использовать кеширующие резолверы, например: systemd-resolved, dnsmasq, unbound. С их помощью можно снизить количество публичных DNS-запросов и, таким образом, уменьшить расходы.
Внутренние зоны
Доменные имена из внутренних зон доступны для использования только в сетях Virtual Private Cloud (VPC), указанных при создании зоны. Во внутренних зонах вы можете использовать все пространство имен в подсетях выбранной сети, в том числе internal. и ..
Важно
Созданная внутренняя зона перекрывает публичные зоны. Если вы создадите внутреннюю зону example.com, то в этой сети VPC станут недоступны все поддомены example.com., доступные из интернета.
Сервисные зоны
В сетях VPC могут автоматически создаваться сервисные зоны. Список таких зон определяется диапазоном адресов используемых подсетей, например:
Сервисные зоны Yandex Cloud
.internal.10.in-addr.arpa.168.192.in-addr.arpa.16.172.in-addr.arpa.17.172.in-addr.arpa.18.172.in-addr.arpa.19.172.in-addr.arpa.20.172.in-addr.arpa.21.172.in-addr.arpa.22.172.in-addr.arpa.23.172.in-addr.arpa.24.172.in-addr.arpa.25.172.in-addr.arpa.26.172.in-addr.arpa.27.172.in-addr.arpa.28.172.in-addr.arpa.29.172.in-addr.arpa.30.172.in-addr.arpa.31.172.in-addr.arpa.
В этих зонах содержатся записи с внутренними FQDN виртуальных машин и именами баз данных MDB, пользовательскими именами ВМ и обратными записями. Автоматически созданные записи нельзя редактировать, но вы можете управлять записями, добавленными вручную.
Из соображений безопасности, создание пользовательских записей вида *.yandexcloud.net и *.cloud.yandex.net запрещено. Для настройки удобных доменных имен ресурсов рекомендуется заводить CNAME или ANAME записи в ваших внутренних DNS-зонах.
Для повышения отказоустойчивости часть трафика может передаваться в сторонние рекурсивные резолверы. Если вам необходимо избежать этого — обратитесь в техническую поддержку.
Обратные зоны
В обычных записях DNS имя домена сопоставляется с IP-адресом. Например, домену ya.ru соответствует IP-адрес 77.88.55.242. Обратная служба DNS преобразует IP-адрес обратно в имя домена. Например, IP-адресу 77.88.55.242 будет соответствовать домен ya.ru.
Записи обратной службы DNS размещены в специальных зонах DNS, называемых зонами ARPA. Блоки адресов IPv4 и IPv6 размещены в отдельных зонах.
Можно делегировать управление обратной зоной.