Зоны 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-зоны) создавать нельзя.
Из соображений безопасности, вложенные публичные зоны могут создавать только пользователи и сервисные аккаунты, у которых есть роль 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 размещены в отдельных зонах.