← Cloudflare DNS / dns / manage-dns-records / reference

Затенённые записи

Когда вы добавляете NS запись в свою зону, вы создаёте делегирование поддомена: вы делегируете полномочия для этого поддомена (и всего, что находится ниже него) другому набору серверов имён. Любая запись, которую вы сохраняете на уровне этой точки делегирования или ниже, является перекрыта. Она остаётся в вашей зоне, но делегирование передаёт полномочия на этот домен делегированным серверам имён, поэтому эта запись не входит в авторитетные данные, которые должна обслуживать ваша зона.

Теневые метаданные показывают, какие записи затенены, а также NS записи выполняют затенение и сколько записей затеняет каждое делегирование. Эта информация передаётся в виде полей в ответах API и предупреждений в панели управления Cloudflare, и не возвращается, если вы явно её не запросите.

Поскольку делегирование передаёт полномочия на поддомен в другое место, любая запись, размещённая на этом уровне или ниже, не является авторитетной, хотя она по-прежнему отображается в вашей зоне. Рассмотрим пример:

sub.example.com      NS  ns1.example.org.
www.sub.example.com  A   192.0.2.1

NS делегирование в sub.example.com делегирует полномочия на всё, что находится на этом уровне и ниже, включая www.sub.example.com, на внешние серверы имён. Именно эти серверы имён, а не ваша зона, отвечают за этот домен, поэтому A запись, которую вы здесь добавили, не является авторитативной записью для www.sub.example.com.

Проблема работает в обе стороны. Добавление NS делегирование может теневым образом перекрывать записи, от которых вы уже зависите, а добавление записей под уже существующим делегированием создаёт записи, для которых ваша зона больше не является авторитетной. В обоих случаях ошибка не возвращается, поэтому именно теневые метаданные помогают заметить проблему.

Затенённые записи возникают ровно в двух случаях:

• Вы добавили делегирование поверх записей, которые уже существовали на этом имени или ниже него, например, когда поддомен указывает на внешнего провайдера, но исходные записи остались на месте.
• Вы добавили записи на имени, которое уже было делегировано, или ниже него, например, рассчитывая, что они будут разрешаться из родительской зоны.

Связующая запись (glue record) представляет собой A или AAAA запись, которая нужна некоторым делегированиям для работы. Glue-запись требуется только тогда, когда имя хоста сервера имён делегирования находится внутри самой делегированной зоны. Большинство делегирований указывают на серверы имён в другой зоне (например, ns1.example.org для делегирования sub.example.com) и не нуждаются в glue-записях, так как резолвер может найти эти серверы имён самостоятельно. Без glue-записи во внутризонном случае резолвер, спрашивающий "где находится ns1.sub.example.com?» будет следовать делегированию для sub.example.com до которого он не может достучаться, пока уже не узнает ns1.sub.example.com. Это циклическая зависимость.

Рассмотрим следующий пример:

sub.example.com      NS  ns1.sub.example.com.
ns1.sub.example.com  A   192.0.2.1

A запись для ns1.sub.example.com является glue-записью. Она теневая (sub.example.com делегирование вступает в силу первым), но она всё равно обслуживается. Родительская зона включает её в дополнительный раздел ответа-переадресации, наряду с NS делегирование, чтобы резолверы могли выполнить первоначальный поиск субдомена, не застревая в циклической зависимости.

Glue-записи имеют смысл только для A и AAAA записи. A CNAME запись с тем же именем, что и NS цель не считается glue-записью.

Связующая запись становится недостижимой, когда более высокоуровневое делегирование берёт на себя полномочия для имени, которое эта запись должна поддерживать. Более высокоуровневое делегирование (то есть более близкое к вершине зоны, с меньшим числом меток в имени) забирает полномочия на всё, что находится ниже, поэтому ваша зона не может передать связующую запись даже в дополнительном разделе делегирования. API помечает такие записи как dead_glue: true.

Рассмотрим следующий пример:

sub.example.com        NS  ns1.sub.example.com.
a.sub.example.com      NS  ns1.a.sub.example.com.
ns1.a.sub.example.com  A   192.0.2.1

A запись для ns1.a.sub.example.com выглядит как glue-запись для a.sub делегирование. Однако менее глубокое sub.example.com делегирование забирает полномочия на всё, что находится ниже sub.example.com, включая a.sub.example.com. Полномочия вашей зоны заканчиваются на этом менее глубоком делегировании, поэтому glue-запись для ns1.a.sub.example.com находится за её пределами и никогда не обслуживается.

Недостижимые glue-записи не приводят к сбоям разрешения имён. Это либо остаток, который можно безопасно удалить, либо признак того, что менее глубокое делегирование было создано по ошибке.

Поля теневых метаданных возвращаются в составе meta объект, если это применимо. Они вычисляются по запросу в момент чтения и никогда не сохраняются.

Тип: массив строк (идентификаторы записей)

Присутствует на любой записи, скрытой одной или несколькими NS делегирований. Массив содержит ID NS записи, чьи делегирования затеняют эту запись. Несколько идентификаторов появляется, когда несколько NS записи имеют одно и то же имя делегирования, или когда делегирования существуют более чем на одном родительском уровне над записью.

shadowed_by всегда присутствует в glue-записях, так как glue-записи по определению теневые.

Записи apex (записи, чье имя совпадает с именем зоны) никогда не перекрываются и никогда не содержат это поле.

Одна NS запись с тем же именем, что и делегирование, не считается перекрытой (shadowed) этим делегированием, она и есть делегирование. Она может содержать shadowed_by только если делегирование существует на более высоком родительском уровне.

Тип: boolean

Присутствует и установлено на true на A или AAAA записи, чьё имя совпадает с целью одной из NS записи, которая их затеняет. Эти записи являются необходимой клеевой информацией для делегирования. Несмотря на то что они затенены, они по-прежнему обслуживаются: родительская зона включает их в дополнительный раздел ответов перенаправления, чтобы резолверы могли обращаться к делегированным серверам имен.

Это поле отсутствует, если запись не является glue-записью.

Тип: boolean

Присутствует и установлено на true на glue-записях, которые фактически никогда не обслуживаются, поскольку делегирование на более высоком уровне перехватывает полномочия раньше, чем зона успевает ответить за это имя. Запись с dead_glue: true также содержит is_glue: true.

Это поле отсутствует, если запись является активной glue-записью или вообще не является glue-записью.

Тип: integer

Присутствует на не apex NS записи, формирующие делегирование. Показывает, сколько записей в зоне затенено этим делегированием (записи на имени делегирования или ниже, за исключением собственных NS записи и скрытые записи).

Счётчик ограничен значением 10,000. Значение 10,000 означает «не менее 10,000». Если счётчик равен нулю, поле не выводится.

В следующей таблице показано, какие поля теневых метаданных применяются к каждому типу записей:

Добавить include_shadow_metadata=true к любому запросу API DNS-записей:

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records?include_shadow_metadata=true" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

Теневые метаданные доступны во всех ответах API для записей: при чтении отдельной записи, в ответах на создание и обновление, в запросах списков и в пакетных запросах. Для запросов списков и пакетных запросов теневые метаданные вычисляются только тогда, когда страница или пакет содержит 1,000 записей или меньше. Запросы, превышающие этот лимит, возвращают записи без теневых метаданных.

Чтобы показать только записи, скрытые определённым делегированием, передайте shadowed_by_name вместе с include_shadow_metadata=true:

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records?include_shadow_metadata=true&shadowed_by_name=sub.example.com" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

Значение должно быть поддоменом зоны (не apex зоны). Фильтр возвращает все записи на этом имени и ниже. NS записи непосредственно на имени делегирования исключаются (они формируют само делегирование, а не затеняемый набор). NS записи на именах ниже делегирования: например, дальнейшее делегирование на a.sub.example.com при фильтрации по sub.example.com сами оказываются перекрыты и включаются.

Чтобы найти NS делегирований, которые теневым образом перекрывают конкретную запись, передайте shadowing_name:

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records?shadowing_name=www.sub.example.com" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

Фильтр возвращает NS записи на указанном имени и на каждом из его родительских имен в пределах зоны, за исключением вершины зоны. В этом примере API выполняет поиск NS записи в www.sub.example.com и sub.example.com. Значение должно быть поддоменом зоны (не корневым доменом зоны).

В отличие от shadowed_by_name, этот фильтр не требует include_shadow_metadata=true.

Ниже приведён фрагмент, показывающий поля теневых метаданных для трёх записей в зоне, содержащей:

sub.example.com       NS    ns1.sub.example.com.
ns1.sub.example.com   A     192.0.2.1
www.sub.example.com   A     192.0.2.2

[
  {
    "type": "NS",
    "name": "sub.example.com",
    "content": "ns1.sub.example.com.",
    "meta": {
      "shadowed_records_count": 2
    }
  },
  {
    "type": "A",
    "name": "ns1.sub.example.com",
    "content": "192.0.2.1",
    "meta": {
      "shadowed_by": ["<NS_RECORD_ID>"],
      "is_glue": true
    }
  },
  {
    "type": "A",
    "name": "www.sub.example.com",
    "content": "192.0.2.2",
    "meta": {
      "shadowed_by": ["<NS_RECORD_ID>"]
    }
  }
]

NS запись содержит shadowed_records_count: 2 (две записи оказываются перекрыты ею). Записи glue A запись содержит одновременно shadowed_by и is_glue: true. Не относящиеся к glue A запись содержит только shadowed_by.