RFC 3403 Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database

Network Working Group                                    M. Mealling
Request for Comments: 3403                                  VeriSign
Obsoletes: 2915, 2168                                   October 2002
Category: Standards Track

Система DDDS. Часть 3 – База данных DNS

Dynamic Delegation Discovery System (DDDS)

Part Three: The Domain Name System (DNS) Database

PDF

Статус документа

Этот документ содержит спецификацию стандартного протокола, предложенного сообществу Internet, и служит приглашением к дискуссии в целях развития. Текущее состояние стандартизации и статус описанного здесь протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2002). All Rights Reserved.

Аннотация

Этот документ описывает Базу данных DDDS¹, использующую систему DNS² в качестве распределенной базы Правил. Ключами являются доменные имена и Правила представляются с использованием записей NAPTR RR³.

Поскольку этот документ отменяет действие RFC 2915, он является официальной спецификацией для записей NAPTR в DNS. Документ также является частью серии, полностью указанной в документе Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS (RFC 3401). Важно подчеркнуть, что понимание любого документа этой серии невозможно без прочтения других документов.

1. Введение

Система DDDS обеспечивает возможность организации связей между строками данных для поддержки систем передачи полномочий (делегирования0 с динамической конфигурацией. Работа DDDS основана на отображении некой уникальной строки на данные, хранящиеся в Базе данных DDDS путем итеративного применения правил преобразования строк до выполнения условий завершения.

Этот документ описывает способ, при котором используется система DNS в качестве хранилища Правил, обеспечивающих функционирование Приложения DDDS. Документ не задает какого-либо конкретного приложения или сценария использования. Вся серия документов описана в Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS (RFC 3401) [1]. Важно подчеркнуть, что понимание любого документа этой серии невозможно без прочтения других документов.

Описанная здесь запись DNS NAPTR была изначально предложена рабочей группой URN в качестве способа представления наборов правил в DNS, позволяющих разобрать делегированную часть URI⁴ таким образом, чтобы она могла быть изменена и ределегирована с течением времени. В результате получились записи RR⁵, включающие регулярные выражения, которые используются клиентскими программами для преобразования строк в доменные имена.

Регулярные выражения были выбраны за их возможность компактно выражать большие объемы информации для передачи в обычно небольших пакетах DNS.

Со временем процесс был обобщен для других Приложений и Баз данных о Правилах. В этом документе определена База данных о Правилах без задания какого-либо Приложения, поскольку может существовать множество Приложений, способных использовать эту Базу данных о Правилах.

2. Терминология

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [6].

Все прочие термины, особенно выделенные шрифтом, заимствованы из [3].

3. Спецификация Базы данных DDDS

General Description – общее описание

Эта база данных использует систему DNS, описанную в [8] и [7].

Набором символов, используемых для задания различных значений записей NAPTR является UTF-8 [17]. Следует соблюдать осторожность в тех случаях, когда ввод или вывод выражений для замены содержит коды, выходящие за пределы эквивалентности ASCII/Unicode в UTF-8 – любые символы UTF-8 интерпретируются как последовательности кодовых точек (code-point), а не байтов. Это сделано для поддержки других языков в расширенных регулярных выражениях POSIX⁶, чтобы обеспечить возможность соответствия предназначенным кодовым точкам. Недопустимо писать выражения для замены так, чтобы они зависели от локальных установок POSIX⁷, поскольку это приведет к потере выражениями для замены их универсальности в применении.

Все записи о ресурсах DNS имеют связанное с ними значение времени жизни TTL⁸. По истечении с момента отыскания записи соответствующего числа секунд корректность записи теряется и нужно сделать новый запрос для получения новых записей. Таким образом, как указано в Алгоритме DDDS, могут возникать ситуации, когда срок действия данного Правила истекает. В тех случаях, когда приложение пытается вернуться к ранее найденным наборам Правил (в случае неподходящего пути передачи полномочий или при отказе сервера) приложение должно обеспечить гарантию того, что ни одна из записей, к которым происходит возврат, не перестала быть корректной по времени жизни. Если истек срок действия хотя бы одной записи приложение должно вернуть процесс на первый шаг алгоритма.

Key Format – формат ключей

Ключ представляет собой корректно сформированное доменное имя DNS.

Lookup Request – поисковый запрос

Чтобы запросить набор правил для данного Ключа, клиент вводит запрос, соответствующий стандартным правилам DNS, для записис NAPTR RR, соответствующей данному доменному имени.

Lookup Response – отклик при поиске

Отклик на запрос для данного Ключа (доменное имя) будет серией записей NAPTR. Формат записи NAPTR описан в главе 4.

Rule Insertion Procedure – процедура вставки правил

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

Collision Avoidance – предотвращение конфликтов

В том случае, когда два Приложения могут использовать эту Базу данных (на практике это случай использования базы приложениями ENUM и URI Resolution, описанный в параграфе 6.2), возможно возникновение конфликта между правилами, когда в домене появляются две записи NAPTR, применимые более, чем к одному Приложению. Существуют три способа предотвращения конфликтов.

• Создание в домене новой зоны, которая содержит только записи NAPTR, которые подходят для Приложения. Например, все записи URI Resolution могут размещаться в зоне urires.example.com, а все записи ENUM – в зоне enum.example.com. В том случае, когда такое решение невозможно по причине отсутствия контроля над восходящим делегированием⁹, следует использовать второй метод.

• Создание регулярного выражения, содержащего часть строки AUS¹⁰, достаточную для однозначной идентификации приложения. Например, URI Resolution может использовать имя схемы слева для привязки регулярного выражения к соответствию этой схеме. Связанные с ENUM записи в той же зоне могут привязываться слева к соответствию символу “+”, который определен в ENUM как начало каждой строки AUS. В результате данной строке AUS может соответствовать лишь одна из записей, а не две.

• Если два приложения используют различные значения Flags или Services, тогда записи другого Приложения можно игнорировать, поскольку они не будут соответствовать значению Services/Flags.

4. Формат NAPTR RR

4.1 Формат пакета

Формат пакетов NAPTR RR показан на рисунке. Код типа DNS для NAPTR имеет значение 35.

                                       1  1  1  1  1  1
         0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       |                     ORDER                     |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       |                   PREFERENCE                  |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       /                     FLAGS                     /
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       /                   SERVICES                    /
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       /                    REGEXP                     /
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       /                  REPLACEMENT                  /
       /                                               /
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Определения <character-string> (строка символов) и <domain-name> (доменное имя) приведены в RFC 1035 [7].

ORDER

16-битовое целое число без знака, задающее порядок, в котором должны обрабатываться записи NAPTR для точного представления упорядоченного списка Правил. Упорядочивание идет от меньших значений к большим. Если две записи имеют одинаковое значение порядка, считается, что они являются одним правилом и выбор следует делать на основе комбинации значений Preference и Services

PREFERENCE

Хотя это поле и носит название «предпочтение» в соответствии с принятой в DNS терминологией, в Алгоритме DDDS оно является эквивалентом значения Priority. Это 16-битовое целое число без знака, которое задает порядок, в котором следует обрабатывать записи NAPTR с одинаковыми значениями поля Order (младшие номера обрабатываются раньше старших). Это похоже на поле Preference в записи MX и используется так, чтобы администратор домена мог направить клиентов на более подходящие хосты или менее отягощенные протоколы. Клиент может обращаться к записям с более высокими значениями поля Preference, если у клиента есть достаточные основания для этого (например, отсутствие поддержки некоторых протоколов или служб).

Важное различие между полями Order и Preference заключается в том, что после того, как найдено соответствие, для клиента недопустимо обращаться к записям с другими значениями поля Order, но можно обрабатывать записи с одинаковыми значениями Order и различными значениями Preferences. Единственное исключение из этого правила указано в Примечании к спецификации алгоритма DDDS по части разрешения клиенту использовать более сложное определение сервиса между п. 3 и п. 4 в алгоритме. Значение Preference используется для обозначения более высокого качества сервиса в правилах, которые рассматриваются как одинаковые с точки зрения передачи полномочий, но не с точки зрения распределения нагрузки.

Важно отметить, что DNS поддерживает несколько механизмов распределения нагрузки и если распределение нагрузки требуется как сервис, для распределения нагрузки следует использовать такие средства, как записи SRV или множественные записи типа A.

FLAGS

Строка символов (<character-string>), содержащая флаги для контроля деталей перезаписи и интерпретации полей записи. Флаги представляют собой одиночные буквы от A до Z или цифры от 0 до 9. регистр букв во внимание не принимается. Поле флагов может быть пустым.

Приложение само задает, как оно использует эту Базу данных для определения флагов в этом поле. Приложение должно определить, какие из флагов трактуются как завершающие.

SERVICES

Строка символов (<character-string>), задающая Параметры сервиса (Service Parameters), применимые к данному пути передачи полномочий. Значения этого поля определяются спецификацией Приложения.

REGEXP

Строка символов (<character-string>), содержащая выражение для замены, которое применяется к исходной строке, сохраняемой клиентом для конструирования следующего искомого доменного имени. Синтаксис этого поля описан в спецификации Алгоритма DDDS.

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

REPLACEMENT

Строка <domain-name>, которая является следующим доменным именем для запроса в зависимости от возможных значений поля флагов. Это поле используется в тех случаях, когда регулярное выражение представляет собой простую операцию замены. Любое значение в этом поле должно быть полным доменным именем. Сокращение имен для этого поля не применяется.

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

4.2 Обработка дополнительной информации

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

4.2.1 Обработка раздела Additional Information серверами DNS

Серверы DNS могут добавлять в раздел дополнительной информации наборы RRset, имеющие отношение к ответу и такой же уровень аутентичности, что и данные в разделе Answer. В общем случае это могут быть записи A и SRV, в зависимости от приложения.

4.2.2 Обработка Additional Information преобразователями и приложениями

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

4.3 Формат Master-файла

Формат master-файла соответствует стандартным правилам RFC 1035. Поля Order и Preference, будучи 16-битовыми целыми числами без знака, могут принимать значения от 0 до 65535. Поля Flags, Services и Regexp являются заключенными в кавычки строками (<character-string>). Поскольку поле Regexp может содержать множество символов обратной дробной черты ((backslash), это поле следует трактовать с осторожностью. Работа с регулярными выражениями рассмотрена в главе 7.

5. Спецификация Приложения

Эта База данных DDDS применима для любых приложений, использующих алгоритм DDDS. В дополнение к элементам, требуемым для спецификации Приложения DDDS, приложения, желающие использовать эту базу данных, должны определить перечисленные ниже значения.

• К какому домену относится Ключ, создаваемый правилом First Well Known Rule. Каждое приложение должно обеспечивать гарантию того, что его правила не будут конфликтовать с правилами, используемыми другими приложениями, которые работают в этой же Базой данных. Например, приложение foo может задать, что все его ключи, создаваемые первым общеизвестным правилом будут относиться к зоне foo.net.
• Какие значения допустимы в полях Services и Protocols.

• Каким предполагается вывод завершающего правила перезаписи в дополнение к способу реального представления и использования флагов.

6. Примеры

6.1 Пример URN

Записи NAPTR изначально создавались для использования с сервисом URN RDS¹² [15]. В этом примере рассматривается, как конкретное имя URN будет использовать запись NAPTR для поиска преобразователя, который может ответить на вопрос о URN. Спецификация этого Приложения приведена в документе [2].

Рассмотрим пространство имен a URN, основанное на MIME Content-Id (гипотетическое пространство). URN может иметь вид:

urn:cid:199606121851.1@bar.example.com

Первое общеизвестное правило Приложения служит для извлечения символов между первым и вторым двоеточием. В нашем примере это будет cid. Приложение также задает, что для построения корректного Ключа в конце результата работы First Well Known Rule следует добавить строку urn.arpa. Окончательным результатом тогда будет служить cid.urn.arpa. Далее клиент запрашивает в DNS записи NAPTR для доменного имени cid.urn.arpa. Результатом будет единственная запись:

cid.urn.arpa.
  ;; order pref flags service regexp replacement
  IN NAPTR   100   10 "" "" "!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i"  .

Поскольку запись является единственной в отклике, проблемы упорядочения не возникает. Поле замены пусто, поэтому используется шаблон, возвращенный в поле regexp. Применим выражение regexp ко всему значению URN для проверки наличия соответствия. Последовательность выражения для замены \2 возвращает подстроку example.com. Поскольку поле флагов пусто, поиск не является завершающим и наш следующий запрос к DNS возвратит большее число записей NAPTR, где новое доменное имя example.com.

Отметим, что правило не выделяет полное доменное имя из CID, предполагая вместо этого, что CID происходит от хоста и выделяется домен для этого хоста. Когда все хосты (такие, как bar) могут иметь свои записи NAPTR, поддержка таких записей для всех машин сайта может стать чересчур обременительной. Шаблоны здесь не подойдут, поскольку они возвращают результат только в тех случаях, когда в системе отсутствует точное соответствие для имен.

Запись, возвращенная для запроса example.com может иметь вид:

example.com.
   ;; order pref flags service regexp replacement
   IN NAPTR 100 50 "a" "z3950+N2L+N2C" ""     cidserver.example.com.
   IN NAPTR 100 50 "a" "rcds+N2C" ""          cidserver.example.com.
   IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" ""  www.example.com.

Продолжая этот пример, отметим, что значения полей Order и Preference равны для всех записей, поэтому клиент может выбрать любую запись. Приложение определяет, что флаг ‘a’ указывает на завершение поиска и выводом перезаписи будет доменное имя, для которого следует запросить запись типа A. Когда клиент сделает это, он узнает хост, его IP-адрес, протокол и доступные для этого протокола службы. Этой информации клиенту достаточно для контакта с сервером и передачи тому запроса о URN.

Повторно используем регулярное выражения, содержащее \2, для выделения доменного имени из CID и \. для соответствия символу ‘.’, разделяющему компоненты доменного имени. Поскольку \ является escape-символом, включение самого этого символа должно использовать предшествующий ему дополнительный символ \ (escape). Для случая приведенной выше записис cid.urn.arpa регулярное выражение в master-файле должно иметь вид “!^urn:cid:.+@([^\\.]+\\.)(.*)$!\\2!i”. Когда клиент получит реальную запись, та будет преобразована к виду “!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i”.

6.2 Пример E164

Рабочая группа ENUM подготовила спецификацию сервиса, который позволяет отображать телефонные номера на URI [18]. Строка AUS для Приложения ENUM представляет собой телефонный номер E.164 с удаленными символами “-”. Первое общеизвестное правило обеспечивает удаление из телефонного номера ненужные символы¹³ и полученное в результате значение используется как первый Ключ. Например, телефонный номер 770-555-1212¹⁴ в формате E.164 будет иметь вид +1-770-555-1212. Полученный в результате преобразования первый Ключ будет иметь значение 17705551212.

В настоящее время ENUM является единственным приложением, использующим эту Базу данных. Спецификация приложения задает для преобразования первого Ключа в формат, корректный для Базы данных вставку точек между цифрами и добавления строки “e164.arpa.” в конце. Для упомянутого выше телефонного номера преобразованный ключ будет иметь значение “2.1.2.1.5.5.5.0.7.7.1.e164.arpa.”. Это доменное имя используется для нахождения Правил перезаписи, как записей NAPTR.

Для нашего примера мы можем получить в результате следующие записи NAPTR:

$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.
IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@foo.se!i" .
IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information@foo.se!i" .

Оба приложения ENUM [18] и URI Resolution [4] используют флаг ‘u’. Это флаг говорит, что Правило является завершающим и результатом служит значение URI, которое содержит информацию, требуемую для обращения в телефонную компанию. ENUM также использует такой формат для своих параметров сервиса (Service Parameters). Это показывает, что для доступа к телефонному сервису поддерживается протокол Session Initiation Protocol или SMTP (электронная почта).

7. Совет администраторам DNS

Остерегайтесь регулярных выражений. Они не только достаточно сложны сами по себе, но ещ и взаимодействуют с DNS, как было отмечено выше. Любые символы обратной дробной черты (\) в регулярном выражении должны указываться дважды, чтобы в отклике на запрос появился одиночный символ \. Более того, использование двойных символов \ возможно не было протестировано со всеми реализациями серверов DNS.

Чтобы не возникало ненужных проблем с файлами зон, администраторам рекомендуется использовать при написании правил перезаписи свойство регулярных выражений default delimiter¹⁵. По спецификации DDDS регулярные выражения начинаются с символа, который будет использоваться в качестве ограничителя. Следовательно, если первым символом регулярного выражения является восклицательный знак (например), регулярное выражение можно создать с использованием меньшего числа символов \.

8. Примечания

Клиент должен обрабатывать множество записей NAPTR, упорядоченных по значению поля Order, и недопустимо просто использовать первую запись, которая обеспечивает известную комбинацию Service Parameter.

Если множество записей RR имеют одинаковое значение поля Order и все прочие критерии дают одинаковый результат, клиенту следует использовать значение поля Preference для выбора следующей рассматриваемой записи NAPTR. Однако, поскольку во многих случаях существуют предпочтительные протоколы или службы, клиент может использовать для сортировки записей иные критерии.

При отказе после перезаписи клиенту настоятельно рекомендуется сообщить об отказе, а не просто переходить к использованию других путей перезаписи.

9. Согласование с IANA

Значения полей Services и Flags будут определяться Приложением, использующим эту Базу данных DDDS. Это может потребовать механизма регистрации и связанных с такой регистрацией ресурсов IANA. Данная спецификация таких требований не включает.

10. Вопросы безопасности

Записи NAPTR, подобно всем прочим записям DNS, могут подписываться и проверяться в соответствии с процедурами DNSSEC.

Эта База данных делает идентификаторы из других пространств имен объектами тех же атак, которым подвержены обычные доменные имена. Поскольку этот вопрос не был разрешен ранее, он может рассматриваться (или не рассматриваться) как проблемы.

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

Литература

[1] Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS”, RFC 3401, October 2002.

[2] Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm”, RFC 3402, October 2002.

[3] Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database”, RFC 3403, October 2002.

[4] Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application”, RFC 3404, October 2002.

[5] Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures”, RFC 3405, October 2002.

[6] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[7] Mockapetris, P., “Domain names – implementation and specification”, STD 13, RFC 1035, November 1987.

[8] Mockapetris, P., “Domain names – concepts and facilities”, STD 13, RFC 1034, November 1987.

[9] Gulbrandsen, A., Vixie, P. and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV)”, RFC 2782, February 2000.

[10] Crocker, D., “Augmented BNF for Syntax Specifications: ABNF”, RFC 2234, November 1997.

[11] Daniel, R., “A Trivial Convention for using HTTP in URN Resolution”, RFC 2169, June 1997.

[12] IEEE, “IEEE Standard for Information Technology – Portable Operating System Interface (POSIX) – Part 2: Shell and Utilities (Vol. 1)”, IEEE Std 1003.2-1992, January 1993.

[13] Berners-Lee, T., Fielding, R. and L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax”, RFC 2396, August 1998.

[14] Moats, R., “URN Syntax”, RFC 2141, May 1997.

[15] Sollins, K., “Architectural Principles of Uniform Resource Name Resolution”, RFC 2276, January 1998.

[16] Daniel, R. and M. Mealling, “Resolution of Uniform Resource Identifiers using the Domain Name System”, RFC 2168, June 1997.

[17] Yergeau, F., “UTF-8, a transformation format of ISO 10646”, RFC 2279, January 1998.с

[18] Faltstrom, P., “E.164 number and DNS”, RFC 2916, September 2000.

Адрес автора

Michael Mealling

VeriSign

21345 Ridgetop Circle

Sterling, VA 20166

US

EMail: michael@neonym.net

URI: http://www.verisignlabs.com

Полное заявление авторский прав

Copyright (C) The Internet Society (2002). Все права защищены.

Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

---

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru