Что такое клейкая запись?

Я попросил объединить этот ответ с дублирующим вопросом, поскольку существующие ответы не объясняют роль ADDITIONAL раздел.

Чтобы увидеть, как это работает, введите: dig +trace +additional google.com SOA

Это будет отслеживать полномочия сервера имен, начиная с корневых серверов (+trace). Добавление +additional также покажет вам ADDITIONAL раздел каждого ответа DNS-сервера. Обычно большинство людей думают о DNS с точки зрения QUESTION и ANSWER разделы, но ADDITIONAL также играет важную роль: если сервер имен знает ответы на любые вопросы, связанные с ответом, он может превентивно предоставить эти ответы в ADDITIONAL раздел, не требуя дополнительных запросов от вашего клиента.

Обратите внимание, что авторитетные серверы имен для google.com находятся под доменом, для которого они являются авторитетными. (ns1.google.com, ns2.google.com, так далее.)

Когда вы просите сервер имен предоставить список серверов имен для домена, они часто будут предоставлять список A записи (IP-адреса) в ADDITIONAL раздел, а не только NS ответы типа: они называются склеивающими записями, используемыми для предотвращения циклических зависимостей. В этом случае те A Записи поступают с серверов имен TLD (.com, .org и т. д.) на основе IP-адресов, которые кто-то предоставил регистратору DNS, ответственному за домен. Обычно их можно изменить, войдя в веб-интерфейс администратора, который они вам предоставляют.

(отказ от ответственности: AAAA Записи, содержащие адреса IPV6, также могут быть предоставлены как часть клея, но я упустил это для простоты.)

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

Как я понимаю, никакой волшебной дополнительной информации, отправляемой откуда-то, именно так она и работает.

Допустим, ваш домен - example.com, и вы хотите использовать свои собственные серверы имен ns1.example.com и ns2.example.com, вам нужно как минимум два DNS-сервера.

• ns1.example.com имеет IP 192.0.2.10
• ns2.example.com имеет IP 192.0.2.20

Чтобы это работало сейчас, вам нужно, чтобы владелец домена верхнего уровня поместил следующие записи в свой DNS.

example.com NS ns1.example.com
example.com NS ns2.example.com

ns1.example.com A 192.0.2.10 
ns2.example.com A 192.0.2.20

Эти две записи А являются связующими записями, и они должны находиться в верхнем домене, в данном случае.com, и не все регистраторы могут сделать это за вас.

Если это не так, пожалуйста, поправьте меня. Я просто подумал, что пытаюсь объяснить простым способом для тех, кто не может найти правильный ответ.

В википедии есть точное (и краткое) объяснение.
Цитировать:

Круговые зависимости и клеевые записи

Серверы имен в делегациях идентифицируются по имени, а не по IP-адресу. Это означает, что разрешающий сервер имен должен выполнить другой DNS-запрос, чтобы выяснить IP-адрес сервера, на который он ссылался.
Если имя, данное в делегировании, является поддоменом домена, для которого предоставляется делегирование, существует циклическая зависимость. В этом случае сервер имен, предоставляющий делегирование, должен также предоставить один или несколько IP-адресов для доверенного сервера имен, упомянутого в делегировании. Эта информация называется клеем.

,,,

Например, если официальным сервером имен для example.org является ns1.example.org, компьютер, пытающийся разрешить www.example.org, сначала разрешает ns1.example.org. Поскольку ns1 содержится в example.org, для этого сначала необходимо разрешить example.org, который представляет циклическую зависимость.
Чтобы разорвать зависимость, сервер имен для домена верхнего уровня org включает в себя клей вместе с делегированием для example.org. Клеевые записи - это записи адресов, которые предоставляют IP-адреса для ns1.example.org. Средство распознавания использует один или несколько из этих IP-адресов для запроса одного из доверенных серверов домена, что позволяет ему выполнять DNS-запрос.

Итак, это три вопроса:

1. Что именно (но вкратце) представляет собой связующая запись DNS?
2. Зачем они нужны и
3. как они работают?

Краткий ответ на первый вопрос, вероятно, не будет иметь особого смысла без контекста, учитывая несколько многословный ответ на два последних вопроса. Вот альтернативное объяснение с историческими ссылками на RFC, чтобы дать некоторый контекст терминологии, особенно:
RFC 822 «Стандарт формата текстовых сообщений Интернета ARPA», 1982 г., https://www.rfc-editor.org/rfc/rfc822.html , сейчас устаревший;
RFC 5322 «Формат интернет-сообщений» 2008 г., https://www.rfc-editor.org/rfc/rfc5322 ;
RFC 882 «Доменные имена — концепции и возможности», 1983 г., https://www.rfc-editor.org/rfc/rfc882 , который предшествует и устарел;
RFC 1034 «Доменные имена — концепции и возможности», 1987 г., https://www.rfc-editor.org/rfc/rfc1034 , и;
RFC 1035 «Доменные имена – реализация и спецификация», 1987 г., https://www.rfc-editor.org/rfc/rfc1035 ; промежуточный
RFC 952 «Спецификация таблицы хостов Интернета Министерства обороны США» 1985 г., https://www.rfc-editor.org/rfc/rfc952.html ;
RFC 1123 «Требования к интернет-хостам — применение и поддержка» 1989 г., https://www.rfc-editor.org/rfc/rfc1123.html , особенно;
RFC 2181 «Разъяснения к спецификации DNS», 1997 г., https://www.rfc-editor.org/rfc/rfc2181 , и;
RFC 2535 «Расширения безопасности системы доменных имен», 1999 г., https://www.rfc-editor.org/rfc/rfc2535.

Теперь, вкратце, к первому вопросу: «Связующая запись» DNS — это разговорный термин, не определенный в RFC, для типа записи ресурса IP-адреса DNS, записи «A» или записи «AAAA». Запись IP-адреса также является «связующей записью», когда эта запись IP-адреса дает адрес, который связывает путь к общедоступному вторичному серверу DNS-протокола делегированной «дочерней зоны»/«доменного имени», где, в частности, это публичное имя. «Доменное имя» вторичного сервера DNS-протокола для этой делегированной «дочерней зоны» также находится в этой дочерней зоне и находится непосредственно под ее полномочиями. И здесь - поскольку я не нашел этого явно заявленным в RFC - ожидается, что сетевой администратор просто сделает вывод, что, когда делегированная «дочерняя зона» также находится в этой дочерней зоне и находится непосредственно под ее полномочиями, тогда родительская зона Зона также должна предоставить одну или несколько записей IP-адреса, которые, в конечном итоге, ссылаются на авторитетные серверы DNS-протокола дочерней зоны . «Связывающие записи» — это взаимодействие «авторитетных» и «неавторитетных» серверов, где по замыслу «родительская зона» не является авторитетной для «дочерней зоны».

И затем есть предостережение, поднятое в разделе «В чем разница между записями NS и склеенными записями?», автор Ладададада, на практике существует неопределенность, возможно, не совсем разъясненная в RFC, относительно того, будет или не будет какой-либо конкретный клиент DNS-протокола следовать по пути, а затем проверять , что связанный сервер DNS-протокола дочерней зоны также авторитетный сервер для этой дочерней зоны, эффективно проверяя соответствие IP-адресов . Существует вероятность того, что IP-адрес «связующей записи» может привести к авторитетному серверу с записью ресурса «Сервер имен», ведущей к другому, а значит, противоречивому IP-адресу для одного или нескольких авторитетных серверов протокола DNS для этой дочерней зоны. Возможно, адрес сервера проверен. Возможно, адрес сервера не проверен, а IP-адрес устарел, и, возможно, файл зоны этого сервера также «наполовину» устарел, с правильными записями «Сервер имен», но обслуживает Неактуальные или неправильные ответы для других ресурсов. Конечно, это обстоятельство подразумевает административные ошибки DNS, поэтому это всего лишь предостережение. На практике этого «не должно» происходить.

Ответы в RFC на два последних вопроса усложняются, когда от читателя ожидаются «общие знания» и часто используется «перегруженная» терминология, где на практике в обычном использовании один и тот же термин используется в отношении двух, а иногда и двух более того, разные вещи или разные абстракции. Еще одна вещь, которую следует здесь признать, - это ранняя связь в развитии Интернет-сообщений и системы доменных имен, а затем то, как эта ассоциация повлияла на использование терминологии Интернет-сообщений в RFC системы доменных имен как «общеизвестных» для того времени.

В частности, это приводит к весьма непоследовательному использованию термина «доменное имя» в различных RFC, термина, который в разных контекстах может относиться либо к:

1. «доменное имя хоста» или
2. «Доменное имя подзоны».

Эти термины могут быть исторически выведены из RFC. Как «общеизвестно», «хост» сам по себе является 1) машиной с физическим сетевым интерфейсом и 2) интерфейсом IP-сокета операционной системы, которому назначен IP-адрес. Термин «доменное имя хоста» взят из RFC 1123, в котором этот термин используется явно.

Термин «доменное имя подзоны» можно вывести из нескольких RFC. Мы видим «доменное имя» «дочернего домена», как первоначально в RFC 822, или «дочернюю зону» позже в RFC 2181, или «подзону», «доменное имя подзоны», как подразумевается в других RFC, особенно RFC 1035. и RFC 2535.

Эти «доменные имена» — это две совершенно разные вещи, обе из которых могут использоваться как:

1. значения для «имени владельца» в пакете данных протокола DNS и левого «владельца» записи ресурса «главного файла» или «файла зоны», а также как
2. значение «кононического имени» RDATA в записи ресурса NS, MX или CNAME или как «кононическое имя» MNAME в записи ресурса SOA, в пакете данных и в правой части файла зоны, как в RFC 1034 и RFC 1035.

Особенно в раннем RFC 952 мы видим, что эти две разные концепции «домена» просто «смешаны вместе»:

       GRAMMATICAL HOST TABLE SPECIFICATION

  A. Parsing grammar
  ...
     <domainname> ::= <hname>
     <official hostname> ::= <hname>

Другая вероятная область путаницы — это «Запись ресурсов NS», которая также имеет два совершенно разных значения, в зависимости от контекста. Мы можем прочитать раздел 6.1 RFC 2181 ниже https://www.rfc-editor.org/rfc/rfc2181#section-6 :

6.1. Полномочия зоны.
Достоверные серверы зоны перечисляются в записях NS для происхождения зоны, которые вместе с записью начала полномочий (SOA) являются обязательными записями в каждой зоне. Такой сервер является авторитетным для всех записей ресурсов в зоне, которые не находятся в другой зоне. Записи NS, указывающие на сокращение зоны, являются собственностью созданной дочерней зоны, как и любые другие записи происхождения этой дочерней зоны или любых ее поддоменов. Сервер зоны не должен возвращать авторитетные ответы на запросы, связанные с именами в другой зоне, которая включает записи NS и, возможно, A в разрезе зоны, если только он также не является сервером для другой зоны.

и обратите особое внимание на фразу «Записи NS... являются обязательными записями в каждой зоне», а также обратите внимание:

За исключением случаев DNSSEC, упомянутых ниже, серверы должны игнорировать данные, отличные от записей NS, и необходимые записи A для поиска серверов, перечисленных в записях NS, которые могут быть настроены в зоне при вырезании зоны.

В то же время мы также читаем в предыдущем разделе 6:

... О существовании выреза зоны в родительской зоне свидетельствует наличие записей NS, указывающих происхождение дочерней зоны. Дочерняя зона не содержит явных ссылок на свою родительскую зону.

Таким образом, читателю остается сделать вывод, что в файле зоны существуют два совершенно разных класса записей ресурсов NS:

1. эти обязательные записи имеют ту же «метку», что и сам «исходный» домен зоны, давая «доменные имена хоста» самоописательных авторитетных общедоступных вторичных серверов DNS-протокола. Они относятся к этой зоне и являются авторитетными. И
2. эти необязательные записи имеют метки, не совсем соответствующие исходному домену зоны и тем самым указывающие теперь расширенные исходные домены дочерней зоны и связывающие путь к именам общедоступных вторичных серверов DNS-протокола для дочерней зоны. Они относятся к какой-то другой зоне и не являются авторитетными. Эти записи являются лишь «наилучшим предположением», особенно учитывая, что эта родительская зона не может быть авторитетной для дочерней зоны.

Здесь нам следует воспользоваться моментом и осознать, что этот второй класс записей NS может тогда также потребовать включения соответствующих записей адреса в качестве «связующих записей», когда делегированная «дочерняя зона» также находится и находится непосредственно под властью внутри, эту дочернюю зону, как обсуждалось ранее. Мы также должны понимать, что эти же самые записи NS и связанные с ними «связывающие записи» должны быть включены (можно предположить, что они «включены избыточно») в файл зоны дочерней зоны для «доменного имени подзоны». , как авторитетное выражение общедоступных вторичных DNS-серверов домена подзоны и их IP-адресов. Опять же, помните, что «родительская» зона никогда не является авторитетной для «дочерней» зоны, даже если файл родительской зоны включает и уже предоставил ту же самую информацию – никогда для записей NS дочерней зоны и никогда для каких-либо других типов данных. запись ресурса дочерней зоны.

Итак, теперь ко второму вопросу: « Зачем нужны клеевые пластинки?», следует сначала сказать, что, строго говоря, клеевые пластинки не нужны , вообще, при условии, что:

1. В файле зоны не описывается какое-либо дочернее «доменное имя зоны», включающее NS-записи ранее описанного второго класса, или
2. Файл зоны включает записи NS, описывающие дочернее «доменное имя зоны», однако общедоступные вторичные серверы DNS-протокола для дочерней зоны не находятся в пределах дочерней зоны и не находятся под ее непосредственным контролем .

Если сетевой администратор не настраивает какую-либо крупную организацию, нуждающуюся в делегированных поддоменах, с собственными серверами DNS-протокола с самостоятельным администрированием, нет необходимости в какой-либо «связывающей записи». И даже в этом случае крупная организация вполне может разумно распределить свои серверы DNS-протокола за пределами любого делегированного поддомена, опять же, возможно, избегая необходимости в «связывающих записях», если адреса этих серверов уже будут разрешены где-то еще, возможно, каким-то внешним провайдером.

«Связывающие записи», скорее всего, необходимы для «тщеславного» домена или для небольшой организации, которая хочет администрировать как свои собственные серверы DNS-протокола, так и файл зоны, используемый вышестоящим DNS-провайдером организации, вероятно, их DNS-регистратором. И даже в этом случае, скорее всего, только файл зоны Регистратора будет иметь «связывающие записи», ссылающиеся на собственные серверы DNS-протокола клиента, которые, вероятно, также не используются клиентом для делегирования доменных имен подзоны.

Но, как будет сказано в следующем ответе на третий вопрос, « как они работают» и « почему » немного сложнее. Работа DNS подразумевает прохождение пути через иерархию компонентов домена, как описано в RFC 882, в разделе «Спецификации и терминология пространства имен», что в конечном итоге требует «мостового» IP-адреса от неавторитетного сервера к авторитетному серверу на каждый «разрез зоны». Если не ограничиваться «корневой» зоной, на пути к желаемому целевому «доменному имени» всегда имеются сокращения зон. «Связывающие записи» обеспечивают «перемычку» между разрезами зон.

Здесь следует упомянуть, в историческом контексте, переходный механизм записи NS и записи адреса. Обратите внимание, что запись NS содержит «доменное имя подзоны», «владельца» в левой части записи ресурса и «доменное имя хоста», «каноническое имя» RDATA, в правой части. .IP-адреса здесь пока нет. Почему это? Мы можем вернуться к «общеизвестным» из ныне устаревшего RFC 822 в разделе 6.2.3 https://www.rfc-editor.org/rfc/rfc822.html#section-6.2 , где заметно говорится:

6.2.3. ДОМЕННЫЕ УСЛОВИЯ
Ссылка на домен должна быть официальным именем реестра, сети или хоста. Это символическая ссылка внутри поддомена имени. Иногда необходимо обойти стандартные механизмы разрешения таких ссылок, используя более примитивную информацию, например адрес сетевого узла, а не связанное с ним имя узла.
...
Литералы домена, которые относятся к доменам в Интернете ARPA, определяют 32-битные интернет-адреса в четырех 8-битных полях, отмеченных десятичными числами, как описано в Запросе на комментарии № 820, «Назначенные номера». Например:
[10.0.3.19]

       Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.  It
       is  permitted  only  as  a means of bypassing temporary
       system limitations, such as name tables which  are  not
       complete.

Или, перефразируя, «доменное имя» обычно не является IP-адресом. Таким образом, RDATA записи NS является «доменным именем», а не IP-адресом, а отдельная запись адреса связывает это «доменное имя» NS RDATA с записью ресурса RDATA «специфического для Интернета ARPA», фактическим IP-адресом. И тогда, следовательно, запись адреса в этом контексте также может называться «связывающей записью», а запись NS — нет. Этот второй класс записей NS всегда необходим для обозначения «вырезания зоны» в родительской зоне, но связанная запись адреса может потребоваться, а может и не потребоваться, как обсуждалось.

Здесь есть еще одно примечание по терминологии, касающееся записи ресурса SOA и различия между «основным» сервером DNS-протокола и «публичным вторичным» сервером. В RFC 1035, раздел 3.3.13 «Формат SOA RDATA», по адресу https://www.rfc-editor.org/rfc/rfc1035#section-3.3.13 , есть:

       MNAME           The <domain-name> of the name server that was the
                original or primary source of data for this zone.

SOA records cause no additional section processing.

Обратите внимание на прошедшее время: « был первоисточником или первоисточником». Опять же, нам следует воспользоваться моментом и осознать, что очень часто ни один из общедоступных серверов DNS-протокола не обязательно является также основным сервером зоны, а также, что «основной источник данных для этой зоны» даже не обязательно должен быть общедоступный. Хотя основной сервер обычно общедоступен, это не обязательно. И хотя также возможно, что основной сервер является общедоступным и единственным сервером зоны, предпочтительнее иметь резервные серверы. Чтобы упростить администрирование нескольких серверов, один основной сервер может выполнить «перенос зоны» или «авторитетную передачу», «AXFR», на группу вторичных серверов. Если быть педантичным, то «первичный» сервер указан в записи SOA MNAME, и, следовательно, серверы, указанные в RDATA требуемого первого класса записей ресурсов NS, являются «публичными вторичными» серверами. Тем не менее, возможно, что имя SOA MNAME и имя NS RDATA также относятся к одному и тому же серверу.

Наконец, что касается третьего вопроса: « Как работают склеивающие записи?», полезно подумать о подразумеваемой работе протокола DNS при обмене между клиентом и различными серверами, обсуждаемой в RFC 1034, особенно в разделе 5 «Резолверы». , в разделе https://www.rfc-editor.org/rfc/rfc1034.html#section-5 , и RFC 1035, раздел 7 «Реализация резольвера», в целом, и особенно с учетом раздела 7.2, в разделе https://www.rfc-editor.org/rfc/rfc1035#section-7.2 :

Некоторые тонкости:

Резолвер может столкнуться с ситуацией, когда адреса ни для одного из серверов имен, указанных в SLIST, недоступны, а серверы в списке — это именно те серверы, которые обычно используются для поиска их собственных адресов. Такая ситуация обычно возникает, когда RR связующего адреса имеют меньший TTL, чем делегирование маркировки RR NS, или когда распознаватель кэширует результат поиска NS. Резолвер должен обнаружить это условие и перезапустить поиск в следующей родительской зоне или, альтернативно, в корне.

Клиент выполняет последовательность запросов, проходя через иерархию доменных имен, в основном преобразуя компоненты субдомена в IP-адреса, обычно находя сначала «корневой» сервер «доменное имя», затем его IP-адрес, а затем «глобальный верхний уровень». сервер домена «имя домена», затем его IP-адрес, затем «имя домена» третьего уровня, «имя домена подзоны», делегируемое на данный момент родительским глобальным доменом верхнего уровня, и поиск IP-адреса для сервер протокола DNS этой зоны. Сервер глобального домена верхнего уровня авторитетно предоставит «вырезание зоны», указав «доменное имя подзоны». И тогда клиенту понадобится IP-адрес для этого сервера DNS-протокола третьего уровня «доменное имя подзоны». Однако, как уже говорилось, в каждом «разрезании» иерархии доменных имен «родительская» зона по своей природе не является авторитетным источником IP-адреса сервера протокола DNS для «дочерней» зоны . Тем не менее, клиенту нужен IP-адрес — откуда?

Клиент может начать следовать по другому пути в иерархии доменных имен в поисках этого IP-адреса, который заканчивается только тогда, когда клиент идентифицирует сервер с «Источником полномочий» для IP-адреса указанного сервера DNS-протокола. для этого доменного имени дочерней подзоны и любой другой требуемой записи. Но независимо от этого, при каждом «разрезе» от зоны к подзоне у клиента должен быть «мост» от недоверенного источника IP-адреса сервера к «авторитетному» источнику этого IP-адреса. Вот почему «связывающую запись» можно назвать всего лишь «подсказкой» об IP-адресе сервера. Сервер родительской зоны предлагает «наилучшее предположение», «предложение», перенаправляет клиента с текущего сервера на «следующий» сервер, продолжает поиск клиента сервера с «Источником полномочий», чтобы наконец авторитетно заявить , что это IP-адрес — это IP -адрес сервера DNS-протокола «имя хоста» для целевого «доменного имени подзоны».

«Связывающие записи» обеспечивают «мост» IP-адреса от неавторитетного исходного сервера к, в конечном итоге, авторитетному исходному серверу. Будет ли клиент проверять, что IP-адрес текущего сервера действительно соответствует IP-адресу авторитетного DNS-сервера имен для целевого «доменного имени подзоны», остается на усмотрение клиента. Надейтесь на лучшее — или подтвердите это вручную. Возможно, можно было бы полностью исключить перечисление первого класса самоописательных авторитетных NS-записей из файла зоны и по-прежнему предоставлять клиенту любую другую запись ресурса - до тех пор, пока клиент просто «надеется на лучшее» и не делает этого. На самом деле я не проверяю записи NS и связанные с ними записи адреса.

См. также RFC 8499 «Терминология DNS» 2019, https://www.rfc-editor.org/rfc/rfc8499.html.