Network Working Group M. Crawford
Request for Comments: 2673 Fermilab
Updates: 1035 August 1999
Category: Standards Track
Двоичные метки в DNS
Binary Labels in the Domain Name System
Статус документа
В этом документе описан предлагаемый стандарт протокола для сообщества Internet; документ служит приглашением к дискуссии в целях развития протокола. Информацию о текущем состоянии стандартизации протокола можно найти в документе Internet Official Protocol Standards (STD 1). Данный документ может распространяться свободно.
Авторские права
Copyright (C) The Internet Society (1999). All Rights Reserved.
1. Введение и терминология
В этом документе определены метки, представляющие собой строку битов (Bit-String Label), которые могут появляться в доменных именах. Новый тип меток компактно представляет последовательность однобитовых меток (One-Bit Label) и позволяет сохранять записи о ресурсах в любых битах раздела binary-named в дереве доменных имен.
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [KWORD].
2. Мотивация
Двоичные метки предназначены для эффективного решения проблемы хранения данных и передачи полномочий на произвольной границе, когда структуру лежащего в основе пространства имен более естественно представлять в двоичном формате.
3. Формат меток
До 256 однобитовых меток можно группировать в одну метку в форме строки битов. Внутри такой метки наиболее значимый бит (бит верхнего уровня) появляется первым. Это отличается от упорядочения самих меток DNS, в которых первым появляется младший бит (бит низшего уровня). Тем не менее, такая схема упорядочения выглядит наиболее естественной и эффективной для представления двоичных меток.
Среди последовательных меток в форме битовой строки биты, появляющиеся первыми, являются менее значимыми (биты нижнего уровня), нежели биты последующих меток Bit-String (как и при упорядочении меток ASCII).
3.1. Представление
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+
|0 1| ELT | Count | Label … |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+
(каждая «клеточка» представляет 1 бит)
ELT – двоичное значение 000001 – шестибитовое значение расширенного типа метки [EDNS0], выделенное для Bit-String Label.
Count – число значимых битов в поле Label. Нулевое значение поля Count говорит о размере метки 256 битов (таким образом, пустая метка, обозначающая корень DNS, не может быть представлена в формате Bit-String).
Label – строка битов, представляющая собой последовательность однобитовых меток, в которой старший бит указывается первым (т. е., однобитовая метка в позиции 17 на рисунке представляет субдомен домена, представленного однобитовой меткой в позиции 16 и т. д.).
Поле Label дополняется справа битами заполнения (от 0 до 7) для выравнивания размера метки в целом по границе октета. Для заполнения при передаче должно использоваться значение 0, которое должно игнорироваться на приемной стороне.
Последовательность битов может быть расщеплена на две или более метки Bit-String, но точка раздела не имеет значения и ее не требуется сохранять. Изощренные реализации серверов могут делить метки Bit-String для повышения эффективности сжатия сообщений [DNSIS]. Более простые серверы могут делить метки Bit-String по границам зон, если какая-нибудь из таких границ попадает между однобитовыми метками.
3.2. Текстовое представление
Метки в форме битовых строк представляются в текстовом формате (например, в файлах зон), как <bit-spec>, окруженные в качестве граничных маркеров символами \[ и ]. <bit-spec> представляет собой квартет с разделением точки или индикатор базы и последовательность цифр, подходящих для этой базы, за которыми может следовать символ дробной черты и поле размера. В качестве индикаторов базы используются символы b, o и x для обозначения базы 2, 8 и 16, соответственно. Поле размера учитывает значимые биты и должно иметь значение от 1 до 32, включительно, для разделенных точками квартетов или от 1 до 256, включительно, для других форм. Если размер опущен, используется неявное значение 32 для квартетов с точками или 1-, 3- или 4-кратное число двоичных, восьмеричных или шестнадцатеричных цифр в остальных вариантах представления.
Расширенная форма Бэкуса-Наура [ABNF] имеет вид
bit-string-label = “\[” bit-spec “]”
bit-spec = bit-data [ “/” length ]
/ dotted-quad [ “/” slength ]
bit-data = “x” 1*64HEXDIG
/ “o” 1*86OCTDIG
/ “b” 1*256BIT
dotted-quad = decbyte “.” decbyte “.” decbyte “.” decbyte
decbyte = 1*3DIGIT
length = NZDIGIT *2DIGIT
slength = NZDIGIT [ DIGIT ]
OCTDIG = %x30-37
NZDIGIT = %x31-39
При наличии поля <length>, числа цифр в <bit-data> должно быть достаточно для размещения количества битов, заданного полем <length>. При наличии неиспользуемых битов в шестнадцатеричной или восьмеричной цифре эти биты должны иметь значение 0. Поле <dotted-quad> всегда имеет все 4 части, даже если связанное с ним значение <slength> меньше 24. Подобно другим формам неиспользуемые биты должны иметь значение 0.
Каждое число, представляемое <decbyte> должно иметь значение от 0 до 255, включительно.
Число, представленное полем <length> должно иметь значение от 1 до 256, включительно.
Число, представленное полем <slength> должно иметь значение от 1 до 32, включительно.
Когда текстовое представление метки Bit-String генерируется машиной, размер следует указывать явно, не основываясь на принятых по умолчанию значениях.
3.2.1. Примеры
Ниже показаны 4 варианта текстового представления одной метки Bit-String.
\[b11010000011101]
\[o64072/14]
\[xd074/14]
\[208.116.0.0/14]
Ниже представлены две последовательные метки Bit-String, которые обозначают ту же относительную точку в дереве DNS, что и показанные выше одиночные метки Bit-String.
\[b11101].\[o640]
3.3. Каноническое представление и порядок сортировки
Как для сигнальной (передаваемой), так и для текстовой формы представления двоичных меток обеспечивается уровень гибкости, достаточный для для их группировки в последовательность меток Bit-String. Для генерации и проверки подписей DNS [DNSSEC] двоичные метки должны иметь предсказуемую форму. Эта каноническая форма определяется, как минимальная возможная последовательность меток Bit-String, в которой все метки, за возможным исключением первой, имеют максимальный размер.
Например, каноническая форма любой последовательности, содержащей до 256 однобитовых меток имеет одну метку Bit-String, а каноническая форма последовательности из 513 – 768 однобитовых меток имеет три метки Bit-String, из которых вторая и третья содержат по 256 битов.
Канонический порядок сортировки доменных имен [DNSSEC] расширяется с учетом применения двоичных меток. Сортировка продолжает осуществляться пометочно (label-by-label), от наименее значимой метки (метка может быть однобитовой или стандартной – код 00). Любая однобитовая метка помещается при сортировке перед всеми стандартными метками, а значение 0 — впереди значения 1. Отсутствующая метка при сортировке помещается впереди всех меток, как указано в [DNSSEC].
Ниже приведен пример корректно отсортированных доменных имен.
foo.example
\[b1].foo.example
\[b100].foo.example
\[b101].foo.example
bravo.\[b10].foo.example
alpha.foo.example
4. Правила обработки
Однобитовая метка никогда не соответствует какой-либо метке иного типа. В частности метки DNS, представленные символами ASCII 0 и 1 не соответствуют однобитовым меткам со значениями 0 и 1.
5. Обсуждение
Нулевое значение Count в передаваемой форме представляет 256-битовую последовательность не в целях оптимизации, а для предотвращения возможности создания меток размером 0 битов.
6. Согласование с IANA
В этом документе определяется расширенный тип метки (Extended Label Type) под названием Bit-String Label и запрашивается регистрация двоичного кода 000001 в пространстве имен, определенном [EDNS0].
7. Вопросы безопасности
Все вопросы безопасности, относящиеся к традиционным ASCII-меткам DNS, в такой же мере применимы и к двоичным меткам. Правила канонизации и сортировка (параграф 3.3) позволяют решать эти вопросы с помощью DNS Security [DNSSEC].
8. Литература
[ABNF] Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, RFC 2234, November 1997.
[DNSIS] Mockapetris, P., “Domain names – implementation and specification”, STD 13, RFC 1035, November 1987.
[DNSSEC] Eastlake, D., 3rd, C. Kaufman, “Domain Name System Security Extensions”, RFC 2065, January 1997
[EDNS0] Vixie, P., “Extension mechanisms for DNS (EDNS0)”, RFC 2671, August 1999.
[KWORD] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997.
9. Адрес автора
Matt Crawford
Fermilab MS 368
PO Box 500
Batavia, IL 60510
USA
Phone: +1 630 840-3461
EMail: crawdad@fnal.gov
Перевод на русский язык
Николай Малых
10. Полное заявление авторских прав
Copyright (C) The Internet Society (1999). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.
Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.
Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.
Подтверждение
Финансирование функций RFC Editor обеспечено Internet Society.
