diff --git a/.yfm b/.yfm index 43114b70604..5faf3afda77 100644 --- a/.yfm +++ b/.yfm @@ -1,7 +1,7 @@ allowHTML: true connector: type: github - gitHub: + github: endpoint: https://api.github.com owner: yandex-cloud repo: docs \ No newline at end of file diff --git a/en/datalens/security/index.md b/en/datalens/security/index.md index f5753c7a7d1..dc0248093c3 100644 --- a/en/datalens/security/index.md +++ b/en/datalens/security/index.md @@ -19,8 +19,8 @@ Users can also request permission on their own via the request form. For more in Let you define user permissions in a {{ datalens-short-name }} instance: -- `{{ roles-datalens-instances-user }}`: A {{ datalens-short-name }} user with the permissions to create, read, and update objects based on [object permissions](#permissions). -- `{{ roles-datalens-instances-admin }}`: A {{ datalens-short-name }} instance administrator. The role is automatically assigned to the instance creator. The administrator has the `{{ roles-datalens-instances-user }}` rights and can also change the service plan and pay for the paid content in {{ marketplace-name }}. +- `{{ roles-datalens-instances-user }}` — A {{ datalens-short-name }} user with the permissions to create, read, and update objects based on [object permissions](#permissions). +- `{{ roles-datalens-instances-admin }}` — The {{ datalens-short-name }} instance administrator. The role is automatically assigned to the instance creator. The administrator has the `{{ roles-datalens-instances-user }}` rights and can also change the service plan and pay for the paid content in {{ marketplace-name }}. User roles are assigned in the {{ yandex-cloud }} console. @@ -76,21 +76,41 @@ For more information about assigning roles in {{ yandex-cloud }}, see [Roles](.. You can assign the following permissions to objects and folders in {{ datalens-short-name }}: +- [{{ permission-execute }}](#permission-execute) +- [{{ permission-read }}](#permission-read) +- [{{ permission-write }}](#permission-write) +- [{{ permission-admin }}](#permission-admin) + ### {{ permission-execute }} {#permission-execute} -A user with the `{{ permission-execute }}` permission can make requests to available connections and datasets. -It doesn't let the user view connections or datasets. +A user with the `{{ permission-execute }}` permission for a connection can make requests to it, but can't create datasets. Regardless of dataset permissions, the user can't access a list of tables in a dataset or view the SQL subquery that the dataset is based on. + +A user with the `{{ permission-execute }}` permission for a dataset can make requests to it and create charts, but can't view the dataset. {% note warning %} -You can only grant the `{{ permission-execute }}` permission for a connection and dataset. +You can only grant the `{{ permission-execute }}` permission for connections and datasets. {% endnote %} +Granting users the `{{ permission-execute }}` permission lets you: + +- Reduce the number of requests to the source, thereby reducing the load on the connection source. + +- Better control what data can be shown from a dataset. You can hide some source fields so that users can't view all fields. + +- Restrict the creation of subqueries to the source database. A user with the `{{ permission-execute }}` permission can't write subqueries. + ### {{ permission-read }} {#permission-read} A user with the `{{ permission-read }}` permission can view dashboards, widgets, datasets, and directories. +{% note warning %} + +The `{{ permission-read }}` permission doesn't allow copying datasets, because they contain [RLS](row-level-security.md) settings. A user can only copy datasets if granted the `{{ permission-write }}` or `{{ permission-admin }}` permission. + +{% endnote %} + ### {{ permission-write }} {#permission-write} A user with the `{{ permission-write }}` permission can edit dashboards, widgets, connections, datasets, and directories. @@ -147,4 +167,5 @@ To get logs, you can contact [technical support]({{ link-console-support }}). - [{#T}](../operations/permission/grant.md) - [{#T}](../operations/permission/revoke.md) - [{#T}](../operations/permission/request.md) -- [{#T}](../operations/dataset/manage-row-level-security.md) \ No newline at end of file +- [{#T}](../operations/dataset/manage-row-level-security.md) + diff --git a/ru/dns/concepts/compute-integration.md b/ru/dns/concepts/compute-integration.md index 7c790f7eefc..e4cb41f2b9b 100644 --- a/ru/dns/concepts/compute-integration.md +++ b/ru/dns/concepts/compute-integration.md @@ -4,10 +4,10 @@ Чтобы при создании ВМ добавить ее в зону, выберите нужную зону и задайте доменное имя в блоке **Сетевые настройки**. Вы можете подключить интерфейсы ВМ к разным подсетям и получить доменные имена в разных зонах. Если вы не укажете зону, ВМ получит доменное имя в стандартной зоне подсети, к которой будет подключена ВМ. Инструкции по созданию ВМ см. в разделе [{#T}](../../compute/operations/vm-create/create-linux-vm.md). -Сейчас невозможно сразу добавить запись с публичным IP-адресом в доменную зону во время создания ВМ. Добавить запись можно [вручную](../operations/resource-record-create.md) после создания ВМ. +Для ВМ с публичным IP-адресом добавить запись можно [вручную](../operations/resource-record-create.md) после создания ВМ. ## Работа {{ dns-name }} с группами ВМ При назначения FQDN ВМ из групп, имя, указанное в [шаблоне ВМ](../../compute/concepts/instance-groups/instance-template.md), будет использоваться для всех ВМ из группы — будет создан набор записей с одинаковыми именами, но разными IP-адресами в значениях. -Вы можете использовать [переменные](../../compute/concepts/instance-groups/variables-in-the-template.md) из шаблонов ВМ при создании записей. Например, если указать имя записи `web_server_{instance.index}` можно создать записи с уникальными именами ВМ из группы, а с помощью имени `web_server_{instance.zone_id}` — записи, объединяющие все ВМ в одной зоне доступности. +Вы можете использовать [переменные](../../compute/concepts/instance-groups/variables-in-the-template.md) из шаблонов ВМ при создании записей. Например, если указать имя записи `web_server_{instance.index}`, можно создать записи с уникальными именами ВМ из группы, а с помощью имени `web_server_{instance.zone_id}` — записи, объединяющие все ВМ в одной зоне доступности. diff --git a/ru/dns/concepts/dns-zone.md b/ru/dns/concepts/dns-zone.md index e2fe7271daf..eb9255d3a98 100644 --- a/ru/dns/concepts/dns-zone.md +++ b/ru/dns/concepts/dns-zone.md @@ -1,25 +1,38 @@ # Зоны DNS -Зона DNS — это логическое пространство, объединяющее доменные имена ваших ресурсов. С помощью зон вы можете управлять иерархией ваших облачных ресурсов и маршрутизировать DNS-запросы. Например, вы можете объединить ваши тестовые ВМ в рамках зоны `testing.`, а основные ВМ — в зоне `production.`. Зоны содержат [ресурсные записи](resource-record.md). +Зона DNS — это логическое пространство, которое объединяет доменные имена ваших ресурсов и содержит нужные [ресурсные записи](resource-record.md). Зоны бывают [публичные](#public-zones) и [внутренние](#private-zones). Вне зависимости от типа, они образуют иерархию: у зоны может быть одна или несколько подзон. + +Вы можете управлять иерархией облачных ресурсов и маршрутизировать DNS-запросы. Например, создать подзоны для основной и тестовой сред, а внутри них подзоны для приложений, кластеров БД, кеширующих серверов и т. д. + +Для управления доступом к зонам, подзонам и ресурсным записям используется ресурсная модель {{ yandex-cloud }}. +Если публичная зона зарегистрирована в {{ yandex-cloud }}: + +* для создания подзоны требуются права на управление родительской зоной; +* для управления подзоной и записями в ней права на родительскую зону не требуются. + +Это предотвращает создание подзон для зарегистрированных в {{ yandex-cloud }} зон, к которым у пользователей нет доступа. +Можно создавать зоны и подзоны в разных каталогах. Для этого назначьте пользователю или [сервисному аккаунту](../../iam/concepts/users/service-accounts.md) роль `editor` на каталог, в котором находится родительская зона. Подробнее см. в разделе [{#T}](../security/index.md). + +Например, родительская зона `example.com.` находится в каталоге `my-folder`. Тогда, при наличии прав на управление этой зоной, подзоны `test.example.com.` и `production.example.com.` могут быть созданы в каталогах `my-test-folder` и `my-production-folder` соответственно. -Зоны бывают двух типов: публичные и внутренние. ## Публичные зоны {#public-zones} -Доменные имена в публичных зонах доступны из интернета. Если у вас есть зарегистрированный домен, вы можете делегировать его. Для этого укажите у вашего регистратора адреса серверов имен {{ yandex-cloud }} из `NS`-записи: +Доменные имена в публичных зонах доступны из интернета. Если у вас есть зарегистрированный домен, вы можете делегировать его. Для этого укажите адреса серверов имен {{ yandex-cloud }} в `NS`-записях вашего регистратора: * `ns1.yandexcloud.net.` * `ns2.yandexcloud.net.` -Публичные зоны верхнего уровня (TLD-зоны) создавать нельзя. +Публичные зоны верхнего уровня (TLD-зоны) создавать нельзя. + +Из соображений безопасности, вложенные публичные зоны могут размещаться только в одном каталоге. Учитывайте это при организации структуры ваших доменных имен. Для организации более сложных сценариев обратитесь в [техническую поддержку](../../support/overview.md). -Из соображений безопасности, вложенные публичные зоны могут сосуществовать только в одном каталоге. Планируйте это при организации структуры ваших доменных имен. Для организации более сложных сценариев обратитесь в поддержку. +Сервис не требует подтверждения владения доменом. Вы можете занять доменную зону, даже если она не зарегистрирована на вас. Однако, если владелец подтвердит свои права на доменную зону, вы потеряете к ней доступ. Если вы — владелец домена, а зона уже кем-то занята, обратитесь в [техническую поддержку](../../support/overview.md). -Сейчас нет проверки владения доменом. Вы можете занять доменную зону, но если она не зарегистрирована на вас, вы можете потерять к ней доступ. Если вы заметите, что ваше доменное имя занято, обратитесь в техническую поддержку, чтобы подтвердить владение доменом. ## Внутренние зоны {#private-zones} -Доменные имена из внутренних зон доступны для использования только в сетях [{{ vpc-name }}](../../vpc), указанных при создании зоны. Во внутренних зонах вы можете использовать все пространство имен в подсетях выбранной сети, в том числе `internal.` и `.`. +Доменные имена из внутренних зон доступны для использования только в сетях [{{ vpc-name }}](../../vpc) (VPC), указанных при создании зоны. Во внутренних зонах вы можете использовать все пространство имен в подсетях выбранной сети, в том числе `internal.` и `.`. {% note warning %} @@ -27,19 +40,33 @@ {% endnote %} -В сетях {{ vpc-short-name }} автоматически создаются несколько внутренних зон: +В сетях {{ vpc-short-name }} могут автоматически создаваться внутренние зоны. Список таких зон определяется диапазоном адресов используемых подсетей, например: + +{% cut "Внутренние зоны {{ yandex-cloud }}" %} * `.` * `internal.` * `10.in-addr.arpa.` - -В этих зонах содержатся записи со внутренними FQDN виртуальных машин и именами баз данных MDB, пользовательскими именами ВМ и обратными записями. Автоматически созданные зоны нельзя редактировать. - -Для повышения отказоустойчивости часть трафика может передаваться в сторонние рекурсивные резолверы. Если вам необходимо избежать этого — обратитесь в техническую поддержку. - -## Создание подзон в разных каталогах {#subzones-in-different-folders} - -Вы можете создавать подзоны в разных каталогах. Например, зона `example.com.` будет создана в каталоге `my-folder`. При этом подзоны `test.example.com.` и `production.example.com.` могут быть созданы в каталогах `my-test-folder` и `my-production-folder` соответственно. - -Чтобы создавать подзоны в разных каталогах, назначьте пользователю или [сервисному аккаунту](../../iam/concepts/users/service-accounts.md) роль `editor` на каталог, где находится зона, частями которой будут создаваемые подзоны. - +* `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.` + +{% endcut %} + +В этих зонах содержатся записи с внутренними FQDN виртуальных машин и именами баз данных MDB, пользовательскими именами ВМ и обратными записями. Автоматически созданные записи нельзя редактировать, но вы можете управлять записями, добавленными вручную. + +Для повышения отказоустойчивости часть трафика может передаваться в сторонние рекурсивные резолверы. Если вам необходимо избежать этого — обратитесь в [техническую поддержку](../../support/overview.md). diff --git a/ru/dns/concepts/index.md b/ru/dns/concepts/index.md index 4c80a7729c0..25d202512e3 100644 --- a/ru/dns/concepts/index.md +++ b/ru/dns/concepts/index.md @@ -5,4 +5,4 @@ С помощью {{ dns-name }} вы можете: * Создавать [доменные зоны](dns-zone.md) в иерархии DNS. -* Управлять [ресурсными записями](resource-record.md) в созданных зонах. \ No newline at end of file +* Управлять [ресурсными записями](resource-record.md) в созданных зонах. diff --git a/ru/dns/concepts/resource-record.md b/ru/dns/concepts/resource-record.md index 0ceb9224daf..338d36373a7 100644 --- a/ru/dns/concepts/resource-record.md +++ b/ru/dns/concepts/resource-record.md @@ -5,78 +5,213 @@ * Доменное имя. * Тип записи. * Время жизни записи (TTL, Time to live) в секундах до актуализации информации о значении записи. -* Значение записи. +* Значение записи. {{ dns-name }} оперирует наборами записей. Набор может содержать одну запись или объединять ресурсные записи с одинаковым именем и типом, но с разными значениями. Пример набора записей: -Имя | Тип | TTL | Значение ------ | ----- | ----- | ----- -example.com | A | 600 | 10.0.0.1 -example.com | A | 600 | 10.0.0.2 -example.com | A | 600 | 10.0.0.3 +| Имя | Тип | TTL | Значение | +|--------------|-----|-----|-----------| +| example.com. | A | 600 | 192.0.2.1 | +| example.com. | A | 600 | 192.0.2.2 | +| example.com. | A | 600 | 192.0.2.3 | Наборы записей можно изменять, добавляя или удаляя записи. -## Типы ресурсных записей {#rr-types} +Типы ресурсных записей, поддерживаемых {{ dns-name }}, указаны ниже. -{{ dns-name }} поддерживает следующие типы ресурсных записей: -### A {#a} +## A {#a} `A` — сопоставление доменного имени и IPv4-адреса. Например, запрос A-записи `www.example.com` должен вернуть IPv4-адрес вида `xxx.xxx.xxx.xxx`. -Имя | Тип | TTL | Значение ------ | ----- | ----- | ----- -example.com. | A | 600 | 10.0.0.100 +| Имя | Тип | TTL | Значение | +|--------------|-----|-----|-----------| +| example.com. | A | 600 | 192.0.2.1 | -### MX {#mx} +Подробнее об A-записях см. в [RFC-1035](https://www.ietf.org/rfc/rfc1035.html#section-3.4.1). -`MX` — имя сервера, обрабатывающего электронную почту, например `mail.example.com`. MX-записи позволяют задать приоритет серверов для обработки электронной почты. MX-запись должна указывать на A- или AAAA-запись. - -Имя | Тип | TTL | Значение ------ | ----- | ----- | ----- -example.com. | MX | 600 | 10 mail1.example.com. -example.com. | MX | 600 | 50 mail2.example.com. -### CNAME {#cname} +## AAAA {#aaaa} -`CNAME` — псевдоним для FQDN. С помощью CNAME можно обращаться к разным службам, работающим на одном IP-адресе. Например, CNAME-записи `first.example.com` и `second.example.com` могут указывать на одну A-запись `example.com`. +`AAAA` — сопоставление доменного имени и IPv6-адреса. Работает аналогично A-записям. -Имя | Тип | TTL | Значение ------ | ----- | ----- | ----- -first.example.com. | CNAME | 600 | example.com -second.example.com. | CNAME | 600 | example.com -example.com. | A | 600 | 10.0.0.100 +| Имя | Тип | TTL | Значение | +|--------------|------|-----|-------------| +| example.com. | AAAA | 600 | 2001:db8::1 | -### SRV {#srv} +{% note info %} -`SRV` — запись, указывающая имя хоста и порт сервера, на которых работает определенная служба. SRV-запись должна указывать на A- или AAAA-запись. При создании записи указываются приоритет и вес сервера при распределении запросов — так можно распределять нагрузку не только между группами серверов, но и внутри групп из нескольких серверов. Клиент обращается к серверу с наименьшим числом приоритета и если приоритеты одинаковые у нескольких серверов, распределяет запросы согласно весам. - -Имя | Тип | TTL | Значение ------ | ----- | ----- | ----- -_sip._tcp.example.com. | SRV | 600 | 10 70 8080 farm1.example.com. -_sip._tcp.example.com. | SRV | 600 | 10 20 8080 farm2.example.com. -_sip._tcp.example.com. | SRV | 600 | 10 10 8080 farm3.example.com. -_sip._tcp.example.com. | SRV | 600 | 20 0 8080 farm4.example.com. +При сохранении записей типа `AAAA` сервис производит нормализацию адреса, например, запись `2001:db8::` будет приведена к виду `2001:db8:0:0:0:0:0:0`. -### AAAA {#aaaa} +{% endnote %} -`AAAA` — сопоставление доменного имени и IPv6-адреса. Работает аналогично A-записям. +Подробнее об AAAA-записях см. в [RFC-3596](https://tools.ietf.org/html/rfc3596). + + +## CAA {#caa} + +`CAA` — указание авторизованных центров сертификации (Certification Authority Authorization), которым разрешено выпускать сертификаты для зоны и ее подзон. + +Запись состоит из следующих частей: + +* `FLAG` (флаг) — однобайтовое беззнаковое целое, принимающее два значения: + * `0` — запись не является критичной. Центр сертификации может выпустить сертификат по своему усмотрению. + * `128` — запись является критичной. Центр сертификации не должен выдавать сертификат для FQDN, если соответствующая CAA-запись содержит критическое свойство для неизвестного или неподдерживаемого тега. +* `TAG` (тег) — строка, состоящая из символов латинского алфавита и цифр, определяющая предназначение записи: + * `issue` — определяет центр сертификации, которому разрешен выпуск сертификата для зоны или подзоны. + * `issuewild` — определяет центр сертификации, которому разрешен выпуск сертификатов для зоны и всех ее подзон (wildcard, `*.example.com`). + * Контактные данные, которые должен использовать центр сертификации для уведомлений владельца зоны о получении запроса на выпуск сертификата с нарушением правил, определенных в CAA-записях: + * `iodef` — номер телефона, адрес сайта или email в произвольной форме; + * `contactemail` — адрес email; + * `contactphone` — номер телефона. + + Если сервер не может обработать незнакомый ему тег, анализируется значение флага: + + * `0` — тег игнорируется; + * `128` — независимо от значения в поле `VALUE` запись запрещает выпуск сертификатов для указанной зоны. + +* `VALUE` — запись, заключенная в двойные кавычки: `""`. Обработка значения в этом поле определяется значением тега. + +| Имя | Тип | TTL | Значение | Расшифровка | +|--------------|-----|-----|-----------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------| +| example.com. | CAA | 600 | 128 issue "ca.example.net" | Выпуск сертификата для зоны `example.com` разрешен только удостоверяющему центру `ca.example.net` | +| example.com. | CAA | 600 | 0 issuewild "ca.example.net" | Центр сертификации `ca.example.net` может по своему усмотрению выпускать сертификаты для зоны `example.com` и ее подзон | +| example.com. | CAA | 600 | 0 issue ";" | Центрам сертификации запрещено выпускать сертификаты для зоны `example.com` | +| example.com. | CAA | 600 | 0 iodef "mailto:security@example.com" | При нарушении одного из условий, описанных в CAA-записях, следует связаться с владельцем зоны `example.com` по адресу `security@example.com` | +| example.com. | CAA | 600 | 0 iodef "https://security.example.com/" | При нарушении одного из условий, описанных в CAA-записях, следует связаться с владельцем зоны `example.com` через сайт `https://security.example.com` | +| | | | | | + +Подробнее о CAA-записях см. в [RFC-8659](https://tools.ietf.org/html/rfc8659). + + +## CNAME {#cname} + +`CNAME` — псевдоним для FQDN. С помощью CNAME можно обращаться к разным службам, работающим на одном IP-адресе. Например, CNAME-записи `first.example.com` и `second.example.com` могут указывать на одну A-запись `host.example.com`. + +| Имя | Тип | TTL | Значение | +|---------------------|-------|-----|-------------------| +| first.example.com. | CNAME | 600 | host.example.com. | +| second.example.com. | CNAME | 600 | host.example.com. | +| host.example.com. | A | 600 | 192.0.2.100 | + +Подробнее о CNAME-записях см. в [RFC-1035](https://www.ietf.org/rfc/rfc1035.html#section-3.3.1). + + +## MX {#mx} + +`MX` — имя сервера, обрабатывающего электронную почту, например `mx.example.com`. + +Запись состоит из двух частей: + +* `PREFERENCE` — 16-битное целое, задающее приоритет хоста. Чем ниже значение, тем более предпочтительным считается хост. +* `EXCHANGE` — FQDN хоста, обрабатывающего почту в указанной зоне. Значение в этом поле должно указывать на A- или AAAA-запись. + +| Имя | Тип | TTL | Значение | +|--------------|-----|-----|----------------------------| +| example.com. | MX | 600 | 10 mx-primary.example.com. | +| example.com. | MX | 600 | 50 mx-reserve.example.com. | + +Подробнее о MX-записях см. в [RFC-1035](https://www.ietf.org/rfc/rfc1035.html#section-3.3.9). + + +## NS {#ns} + +`NS` — запись, содержащая адрес сервера имен, обслуживающего указанную зону. + +| Имя | Тип | TTL | Значение | +|--------------|-----|-----|------------------| +| example.com. | NS | 600 | ns1.example.com. | +| example.com. | NS | 600 | ns2.example.com. | -### PTR {#ptr} +Подробнее о NS-записях см. в [RFC-1035](https://www.ietf.org/rfc/rfc1035.html#section-3.3.11). -`PTR` — сопоставление IP-адреса и доменного имени. Автоматическое создание PTR-записей доступно только во внутренних зонах. -### TXT {#txt} +## PTR {#ptr} -`TXT` — произвольная запись. +`PTR` — сопоставление IP-адреса и доменного имени. -### SOA {#soa} +| IP-адрес | Тип | TTL | Значение | +|-----------|-----|-----|--------------------| +| 192.0.2.1 | PTR | 600 | host1.example.com. | +| 192.0.2.2 | PTR | 600 | host2.example.com. | + +Подробнее о PTR-записях см. в [RFC-1035](https://www.ietf.org/rfc/rfc1035.html#section-3.3.12). + + +## SOA {#soa} `SOA` — запись, содержащая базовую информацию о зоне. Создается автоматически. -### NS {#ns} +Состоит из следующих частей: + +* `MNAME` — доменное имя сервера, обслуживающего зону. Значение по умолчанию: + * `ns.internal.` — для внутренних зон; + * `ns1.yandexcloud.net.` — для публичных зон. +* `RNAME` — доменное имя почтового сервера, обслуживающего зону. Значение по умолчанию — `md.cloud.yandex.net`. +* `SERIAL` — 32-битное беззнаковое целое, указывающее на номер копии зоны. При синхронизации данных между DNS-серверами проверяется значение в поле `SERIAL`. Чем оно больше, тем более свежими считаются данные. Значение по умолчанию — `1`. + + {% note warning %} + + Сервис {{ dns-name }} не изменяет значение поля `SERIAL` в SOA-записях при редактировании ресурсных записей зоны. Если вы хотите принудительно обновить кеш DNS-серверов, содержащих информацию о ваших ресурсных записях, увеличьте значение в этом поле вручную. + + {% endnote %} + +* `REFRESH` — время в секундах между обновлениями информации о ресурсных записях в зоне. Значение по умолчанию — `10800` (3 часа). +* `RETRY` — время в секундах до очередной попытки обновить сведения о ресурсных записях зоны, если предыдущая была неудачной. Значение по умолчанию — `900` (15 минут). +* `EXPIRE` — время в секундах, по прошествии которого зона перестанет быть авторитетной. Значение по умолчанию — `604800` (7 суток). +* `MINIMUM` — минимальное значение TTL в секундах для любой ресурсной записи, экспортируемой из зоны. Значение по умолчанию — `86400` (24 часа). + +| Имя | Тип | TTL | Значение | +|--------------|-----|------|--------------------------------------------------------------------| +| example.com. | SOA | 3600 | ns1.yandexcloud.net. mx.cloud.yandex.net. 1 10800 900 604800 86400 | +| example.com. | SOA | 3600 | ns.internal. mx.cloud.yandex.net. 1 10800 900 604800 86400 | + +Подробнее о SOA-записях см. в [RFC-1035](https://www.ietf.org/rfc/rfc1035.html#section-3.3.13). + + +## SRV {#srv} + +`SRV` — запись, указывающая имя хоста и порт сервера, на котором работает определенная служба. SRV-запись должна указывать на A- или AAAA-запись. + +Состоит из следующих частей: + +* `Priority` (приоритет) — 16-битное беззнаковое целое число, задающее приоритет хоста. Чем ниже значение, тем более предпочтительным считается хост. +* `Weight` (вес) — 16-битное беззнаковое целое число, задающее вес для хостов с одинаковым приоритетом. Чем ближе значение в этом поле к 0, тем меньше шансов, что хост будет выбран. Если служба работает только на одном хосте, в этом поле укажите значение `0`. +* `Port` (порт) — 16-битное беззнаковое целое число, указывающее порт, используемый службой. +* `Target` — FQDN хоста, на котором размещается служба. + +Клиент обращается к серверу с наименьшим приоритетом. Если приоритеты одинаковые у нескольких серверов, нагрузка распределяется согласно весам. Укажите приоритет и вес записей, чтобы распределить нагрузку не только между группами серверов, но и внутри групп из нескольких серверов. + +| Имя | Тип | TTL | Значение | +|-------------------------------|-----|-----|-----------------------------------| +| _sip._tcp.example.com. | SRV | 600 | 10 70 8080 host.example.com. | +| _postgresql._tcp.example.com. | SRV | 600 | 10 60 6432 pg-master.example.com. | +| _postgresql._tcp.example.com. | SRV | 600 | 10 30 6432 pg-repl1.example.com. | +| _postgresql._tcp.example.com. | SRV | 600 | 10 10 6432 pg-repl2.example.com. | + +{% note warning %} + +Сервис {{ dns-name }} поддерживает только SRV-записи класса `IN`. При создании записей указывать префикс `IN` не нужно. + +{% endnote %} + +Подробнее о SRV-записях см. в [RFC-2782](https://www.ietf.org/rfc/rfc2782.html). + + +## TXT {#txt} + +`TXT` — произвольная запись, в которой обычно размещаются политики [DMARC](https://www.ietf.org/rfc/rfc7489.html) (используются для идентификации электронной почты, что снижает количества спама и фишинговых писем). + +{% note warning %} + +Сервис {{ dns-name }} использует формат [MASTER FILES](https://www.ietf.org/rfc/rfc1035.html#section-5) при разборе TXT-записей. Согласно спецификации этого формата с символа `;` начинается комментарий, т. е. все содержимое после него игнорируется. Если вы хотите использовать символ `;` и пробелы в значении этой записи, заключите ее в двойные кавычки `""`. + +{% endnote %} + +| Имя | Тип | TTL | Значение | +|--------------|-----|-----|-----------------------------------------------------------------------------------| +| example.com. | TXT | 600 | "v=DMARC1; p=none; sp=quarantine; pct=100; rua=mailto: dmarcreports@example.com;" | -`NS` — запись, содержащая адреса серверов имен. Адреса серверов по умолчанию можно указать у вашего регистратора, чтобы делегировать домен. NS-записи используются для делегирования доменов на другой авторитетный сервер. \ No newline at end of file +Подробнее о TXT-записях см. в [RFC-1035](https://www.ietf.org/rfc/rfc1035.html#section-3.3.14) и [RFC-1464](https://tools.ietf.org/html/rfc1464). diff --git a/ru/dns/operations/resource-record-create.md b/ru/dns/operations/resource-record-create.md index 3d35e14ab09..66ac524171e 100644 --- a/ru/dns/operations/resource-record-create.md +++ b/ru/dns/operations/resource-record-create.md @@ -4,7 +4,7 @@ {% list tabs %} -- Консоль управления +* Консоль управления 1. Откройте раздел **{{ dns-name }}** в каталоге, где находится зона DNS, в которой требуется создать запись. 1. Выберите зону из списка. @@ -16,16 +16,21 @@ 1. Значение записи. 1. Нажмите кнопку **Создать**. -- CLI +* CLI + + {% include [include](../../_includes/cli-install.md) %} + + {% include [default-catalogue](../../_includes/default-catalogue.md) %} Выполните команду: - ``` + ```bash yc dns zone add-records --name <имя зоны DNS> \ - --record "<доменное имя> <тип записи> <значение>" + --record "<доменное имя> <тип записи> <значение>" ``` Вы можете добавить несколько записей одновременно. {% endlist %} +При создании ресурсных AAAA-записей сервис автоматически производит нормализацию адресов IPv6, заменяя пропуски между `:` нулями, например: `2001:db8::` → `2001:db8:0:0:0:0:0:0`. diff --git a/ru/ydb/quickstart/yql-api/ydb-cli.md b/ru/ydb/quickstart/yql-api/ydb-cli.md index b305d3dbabb..31a210d17ce 100644 --- a/ru/ydb/quickstart/yql-api/ydb-cli.md +++ b/ru/ydb/quickstart/yql-api/ydb-cli.md @@ -141,11 +141,12 @@ Для проверки корректности аутентификации можно использовать команду запроса информации о пользователе: ```bash -{{ ydb-cli }} discovery whoami \ +{{ ydb-cli }} \ --endpoint <эндпоинт> \ --database <база данных> \ --yc-token-file <путь к файлу с токеном> \ - --groups + discovery whoami \ + --groups \ ``` Где: @@ -413,9 +414,10 @@ User has no groups Чтобы получить список эндпойнтов, выполните команду: ```bash -{{ ydb-cli }} discovery list \ +{{ ydb-cli }} \ --endpoint <эндпоинт> \ - --database <база данных> + --database <база данных> \ + discovery list ``` Где: @@ -436,17 +438,18 @@ grpcs://vm-etn01lrprvnlnhv8v5kj-ru-central1-a-abod.etn01lrprvnlnhv8v5kj.ydb.mdb. Выполните запрос к данным: ```bash -{{ ydb-cli }} table query execute \ - --query "SELECT season_id, episode_id, title FROM episodes WHERE series_id = 1 AND season_id > 1 ORDER BY season_id, episode_id LIMIT 3" \ +{{ ydb-cli }} \ --endpoint <эндпоинт> \ - --database <база данных> + --database <база данных> \ + table query execute \ + --query "SELECT season_id, episode_id, title FROM episodes WHERE series_id = 1 AND season_id > 1 ORDER BY season_id, episode_id LIMIT 3" ``` Где: -* `--query` — текст запроса. * `--endpoint` — эндпоинт БД. * `--database` — полный путь БД. +* `--query` — текст запроса. Результат выполнения: @@ -467,9 +470,10 @@ grpcs://vm-etn01lrprvnlnhv8v5kj-ru-central1-a-abod.etn01lrprvnlnhv8v5kj.ydb.mdb. Листинг объектов производится подкомандой `scheme ls <путь>`. Если путь не указан, то будет производиться листинг корня базы данных: ```bash -{{ ydb-cli }} scheme ls \ +{{ ydb-cli }} \ --endpoint <эндпоинт> \ - --database <база данных> + --database <база данных> \ + scheme ls ``` Где: @@ -486,9 +490,10 @@ episodes seasons series some_directory .sys Чтобы посмотреть подробную информацию, добавьте флаг `-l`: ```bash -{{ ydb-cli } scheme ls \ +{{ ydb-cli }} \ --endpoint <эндпоинт> \ --database <база данных> \ + scheme ls \ -l ``` @@ -511,27 +516,31 @@ episodes seasons series some_directory .sys Создайте дерево из директорий: ```bash -{{ ydb-cli }} scheme mkdir some_directory \ +{{ ydb-cli }} \ --endpoint <эндпоинт> \ - --database <база данных> + --database <база данных> \ + scheme mkdir some_directory ``` ```bash -{{ ydb-cli }} scheme mkdir some_directory/sub-directory1 \ +{{ ydb-cli }} \ --endpoint <эндпоинт> \ - --database <база данных> + --database <база данных> \ + scheme mkdir some_directory/sub-directory1 ``` ```bash -{{ ydb-cli }} scheme mkdir some_directory/sub-directory1/sub-directory1-1 \ +{{ ydb-cli }} \ --endpoint <эндпоинт> \ - --database <база данных> + --database <база данных> \ + scheme mkdir some_directory/sub-directory1/sub-directory1-1 ``` ```bash -{{ ydb-cli }} scheme mkdir some_directory/sub-directory2 \ +{{ ydb-cli }} \ --endpoint <эндпоинт> \ - --database <база данных> + --database <база данных> \ + scheme mkdir some_directory/sub-directory2 ``` Где: @@ -542,9 +551,10 @@ episodes seasons series some_directory .sys Чтобы посмотреть рекурсивный листинг всех поддиректорий и объектов в них по указанному пути, воспользуйтесь опцией `-R` подкоманды `scheme ls`: ```bash -{{ ydb-cli }} scheme ls some_directory \ +{{ ydb-cli }} \ --endpoint <эндпоинт> \ --database <база данных> \ + scheme ls some_directory \ -lR ```