File: rfc2673.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (395 lines) | stat: -rw-r--r-- 12,379 bytes parent folder | download | duplicates (9)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395






Network Working Group                                        M. Crawford
Request for Comments: 2673                                      Fermilab
Category: Standards Track                                    August 1999


                Binary Labels in the Domain Name System

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

1.  Introduction and Terminology

   This document defines a "Bit-String Label" which may appear within
   domain names.  This new label type compactly represents a sequence of
   "One-Bit Labels" and enables resource records to be stored at any
   bit-boundary in a binary-named section of the domain name tree.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [KWORD].

2.  Motivation

   Binary labels are intended to efficiently solve the problem of
   storing data and delegating authority on arbitrary boundaries when
   the structure of underlying name space is most naturally represented
   in binary.

3.  Label Format

   Up to 256 One-Bit Labels can be grouped into a single Bit-String
   Label.  Within a Bit-String Label the most significant or "highest
   level" bit appears first.  This is unlike the ordering of DNS labels
   themselves, which has the least significant or "lowest level" label
   first.  Nonetheless, this ordering seems to be the most natural and
   efficient for representing binary labels.






Crawford                    Standards Track                     [Page 1]

RFC 2673        Binary Labels in the Domain Name System      August 1999


   Among consecutive Bit-String Labels, the bits in the first-appearing
   label are less significant or "at a lower level" than the bits in
   subsequent Bit-String Labels, just as ASCII labels are ordered.

3.1.  Encoding

      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 ...         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+

   (Each tic mark represents one bit.)


   ELT       000001 binary, the six-bit extended label type [EDNS0]
             assigned to the Bit-String Label.

   Count     The number of significant bits in the Label field.  A Count
             value of zero indicates that 256 bits are significant.
             (Thus the null label representing the DNS root cannot be
             represented as a Bit String Label.)

   Label     The bit string representing a sequence of One-Bit Labels,
             with the most significant bit first.  That is, the One-Bit
             Label in position 17 in the diagram above represents a
             subdomain of the domain represented by the One-Bit Label in
             position 16, and so on.

             The Label field is padded on the right with zero to seven
             pad bits to make the entire field occupy an integral number
             of octets.  These pad bits MUST be zero on transmission and
             ignored on reception.

   A sequence of bits may be split into two or more Bit-String Labels,
   but the division points have no significance and need not be
   preserved.  An excessively clever server implementation might split
   Bit-String Labels so as to maximize the effectiveness of message
   compression [DNSIS].  A simpler server might divide Bit-String Labels
   at zone boundaries, if any zone boundaries happen to fall between
   One-Bit Labels.

3.2.  Textual Representation

   A Bit-String Label is represented in text -- in a zone file, for
   example -- as a <bit-spec> surrounded by the delimiters "\[" and "]".
   The <bit-spec> is either a dotted quad or a base indicator and a
   sequence of digits appropriate to that base, optionally followed by a



Crawford                    Standards Track                     [Page 2]

RFC 2673        Binary Labels in the Domain Name System      August 1999


   slash and a length.  The base indicators are "b", "o" and "x",
   denoting base 2, 8 and 16 respectively.  The length counts the
   significant bits and MUST be between 1 and 32, inclusive, after a
   dotted quad, or between 1 and 256, inclusive, after one of the other
   forms.  If the length is omitted, the implicit length is 32 for a
   dotted quad or 1, 3 or 4 times the number of binary, octal or
   hexadecimal digits supplied, respectively, for the other forms.

   In augmented Backus-Naur form [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

   If a <length> is present, the number of digits in the <bit-data> MUST
   be just sufficient to contain the number of bits specified by the
   <length>.  If there are insignificant bits in a final hexadecimal or
   octal digit, they MUST be zero.  A <dotted-quad> always has all four
   parts even if the associated <slength> is less than 24, but, like the
   other forms, insignificant bits MUST be zero.

   Each number represented by a <decbyte> must be between 0 and 255,
   inclusive.

   The number represented by <length> must be between 1 and 256
   inclusive.

   The number represented by <slength> must be between 1 and 32
   inclusive.





Crawford                    Standards Track                     [Page 3]

RFC 2673        Binary Labels in the Domain Name System      August 1999


   When the textual form of a Bit-String Label is generated by machine,
   the length SHOULD be explicit, not implicit.

3.2.1.  Examples

   The following four textual forms represent the same Bit-String Label.

                             \[b11010000011101]
                             \[o64072/14]
                             \[xd074/14]
                             \[208.116.0.0/14]

   The following represents two consecutive Bit-String Labels which
   denote the same relative point in the DNS tree as any of the above
   single Bit-String Labels.

                             \[b11101].\[o640]

3.3.  Canonical Representation and Sort Order

   Both the wire form and the text form of binary labels have a degree
   of flexibility in their grouping into multiple consecutive Bit-String
   Labels.  For generating and checking DNS signature records [DNSSEC]
   binary labels must be in a predictable form.  This canonical form is
   defined as the form which has the fewest possible Bit-String Labels
   and in which all except possibly the first (least significant) label
   in any sequence of consecutive Bit-String Labels is of maximum
   length.

   For example, the canonical form of any sequence of up to 256 One-Bit
   Labels has a single Bit-String Label, and the canonical form of a
   sequence of 513 to 768 One-Bit Labels has three Bit-String Labels of
   which the second and third contain 256 label bits.

   The canonical sort order of domain names [DNSSEC] is extended to
   encompass binary labels as follows.  Sorting is still label-by-label,
   from most to least significant, where a label may now be a One-Bit
   Label or a standard (code 00) label.  Any One-Bit Label sorts before
   any standard label, and a 0 bit sorts before a 1 bit.  The absence of
   a label sorts before any label, as specified in [DNSSEC].











Crawford                    Standards Track                     [Page 4]

RFC 2673        Binary Labels in the Domain Name System      August 1999


   For example, the following domain names are correctly sorted.

                         foo.example
                         \[b1].foo.example
                         \[b100].foo.example
                         \[b101].foo.example
                         bravo.\[b10].foo.example
                         alpha.foo.example

4.  Processing Rules

   A One-Bit Label never matches any other kind of label.  In
   particular, the DNS labels represented by the single ASCII characters
   "0" and "1" do not match One-Bit Labels represented by the bit values
   0 and 1.

5.  Discussion

   A Count of zero in the wire-form represents a 256-bit sequence, not
   to optimize that particular case, but to make it completely
   impossible to have a zero-bit label.

6.  IANA Considerations

   This document defines one Extended Label Type, termed the Bit-String
   Label, and requests registration of the code point 000001 binary in
   the space defined by [EDNS0].

7.  Security Considerations

   All security considerations which apply to traditional ASCII DNS
   labels apply equally to binary labels.  he canonicalization and
   sorting rules of section 3.3 allow these to be addressed by DNS
   Security [DNSSEC].

















Crawford                    Standards Track                     [Page 5]

RFC 2673        Binary Labels in the Domain Name System      August 1999


8.  References

   [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.  Author's Address

   Matt Crawford
   Fermilab MS 368
   PO Box 500
   Batavia, IL 60510
   USA

   Phone: +1 630 840-3461
   EMail: crawdad@fnal.gov
























Crawford                    Standards Track                     [Page 6]

RFC 2673        Binary Labels in the Domain Name System      August 1999


10.  Full Copyright Statement

   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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Crawford                    Standards Track                     [Page 7]