Please enter banners and links.
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 22341, November 1997.
[DNSIS] Mockapetris, P., “Domain names – implementation and specification”, STD 13, RFC 10351, 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 21191, 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). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Подтверждение
Финансирование функций RFC Editor обеспечено Internet Society.
1Перевод этого документа на русский язык имеется на сайте protocols.ru. Прим. перев.
