idnits 2.17.1 draft-ietf-dnsind-binary-labels-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 28, 1998) is 9366 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DNSSEC' is mentioned on line 193, but not defined == Unused Reference: 'DNSCF' is defined on line 222, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- No information found for draft-dnsind-edns - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'EDNS' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSIND Working Group Matt Crawford 2 Internet Draft Fermilab 3 August 28, 1998 5 Binary Labels in the Domain Name System 6 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a 19 ``working draft'' or ``work in progress.'' 21 To view the entire list of current Internet-Drafts, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 24 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 25 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 27 Distribution of this memo is unlimited. 29 1. Introduction and Terminology 31 This document defines a ``Bit-String Label'' which may appear within 32 domain names. This new label type compactly represents a sequence 33 of ``One-Bit Labels'' and enables resource records to be stored at 34 any bit-boundary in a binary-named section of the domain name tree. 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in [KWORD]. 40 2. Motivation 42 Binary labels are intended to efficiently solve the problem of 43 storing data and delegating authority on arbitrary boundaries when 44 the structure of underlying name space is most naturally represented 45 in binary. A new DNS option (described elsewhere [EDNS]) provides a 46 form of longest-match lookup which is useful when the binary name 47 space is like Internet addresses. 49 3. Label Format 51 Up to 256 One-Bit Labels can be grouped into a single Bit-String 52 Label. Within a Bit-String Label the most significant or "highest 53 level" bit appears first. This is unlike the ordering of DNS labels 54 themselves, which has the least significant or "lowest level" label 55 first. Nonetheless, this ordering seems to be the most natural and 56 efficient for representing binary labels. 58 Among consecutive Bit-String Labels, the bits in the first-appearing 59 label are less significant or "at a lower level" than the bits in 60 subsequent Bit-String Labels, just as ASCII labels are ordered. 62 3.1. Encoding 64 0 1 2 65 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 . . . 66 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+ 67 |0 1| ELT | Count | Label ... | 68 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+ 70 (Each tic mark represents one bit.) 72 ELT 000001 binary, the six-bit extended label type [EDNS] 73 assigned to the Bit-String Label. 75 Count The number of significant bits in the Label field. A 76 Count value of zero indicates that 256 bits are 77 significant. (Thus the null label representing the DNS 78 root cannot be represented as a Bit String Label.) 80 Label The bit string representing a sequence of One-Bit Labels, 81 with the most significant bit first. That is, the One-Bit 82 Label in position 17 in the diagram above represents a 83 subdomain of the domain represented by the One-Bit Label 84 in position 16, and so on. 86 The Label field is padded on the right with zero to seven 87 pad bits to make the entire field occupy an integral 88 number of octets. These pad bits MUST be zero on 89 transmission and ignored on reception. 91 A sequence of bits may be split into two or more Bit-String Labels, 92 but the division points have no significance and need not be 93 preserved. An excessively clever server implementation might split 94 Bit-String Labels so as to maximize the effectiveness of message 95 compression [DNSIS]. A simpler server might divide Bit-String 96 Labels at zone boundaries, if any zone boundaries happen to fall 97 between One-Bit Labels. 99 3.2. Textual Representation 101 A Bit-String Label is represented in text -- in a zone file, for 102 example -- as a surrounded by the delimiters "\[" and 103 "]". The is either a dotted quad or a base indicator and 104 a sequence of digits appropriate to that base, optionally followed 105 by a slash and a length. The base indicators are "b", "o" and "x", 106 denoting base 2, 8 and 16 respectively. The length counts the 107 significant bits and MUST be between 1 and 32, inclusive, after a 108 dotted quad, or between 1 and 256, inclusive, after one of the other 109 forms. If the length is omitted, the implicit length is 32 for a 110 dotted quad or 1, 3 or 4 times the number of binary, octal or 111 hexadecimal digits supplied, respectively, for the other forms. 113 In augmented Backus-Naur form [ABNF], 115 bit-string-label = "\[" bit-spec "]" 117 bit-spec = bit-data [ "/" length ] 118 / dotted-quad [ "/" slength ] 120 bit-data = "x" 1*64HEXDIG 121 / "o" 1*86OCTDIG 122 / "b" 1*256BIT 124 dotted-quad = decbyte "." decbyte "." decbyte "." decbyte 126 decbyte = 1*3DIGIT 128 length = NZDIGIT *2DIGIT 130 slength = NZDIGIT [ DIGIT ] 132 OCTDIG = %x30-37 134 NZDIGIT = %x31-39 136 If a is present, the number of digits in the 137 MUST be just sufficient to contain the number of bits specified by 138 the . If there are insignificant bits in a final 139 hexadecimal or octal digit, they MUST be zero. A 140 always has all four parts even if the associated is less 141 than 24, but, like the other forms, insignificant bits MUST be zero. 143 Each number represented by a must be between 0 and 255, 144 inclusive. 146 The number represented by must be between 1 and 256 147 inclusive. 149 The number represented by must be between 1 and 32 150 inclusive. 152 When the textual form of a Bit-String Label is generated by machine, 153 the length SHOULD be explicit, not implicit. 155 3.2.1. Examples 157 The following four textual forms represent the same Bit-String 158 Label. 160 \[b11010000011101] 161 \[o64072/14] 162 \[xd074/14] 163 \[208.116.0.0/14] 165 The following represents two consecutive Bit-String Labels which 166 denote the same relative point in the DNS tree as any of the above 167 single Bit-String Labels. 169 \[b11101].\[o640] 171 3.3. Canonical Representation and Sort Order 173 Both the wire form and the text form of binary labels have a degree 174 of flexibility in their grouping into multiple consecutive Bit- 175 String Labels. For generating and checking DNS signature records 176 [DNSSEC] binary labels must be in a predictable form. This 177 canonical form is defined as the form which has the fewest possible 178 Bit-String Labels and in which all except possibly the first (least 179 significant) label in any sequence of consecutive Bit-String Labels 180 is of maximum length. 182 For example, the canonical form of any sequence of up to 256 One-Bit 183 Labels has a single Bit-String Label, and the canonical form of a 184 sequence of 513 to 768 One-Bit Labels has three Bit-String Labels of 185 which the second and third contain 256 label bits. 187 The canonical sort order of domain names [DNSSEC] is extended to 188 encompass binary labels as follows. Sorting is still label-by- 189 label, from most to least significant, where a label may now be a 190 One-Bit Label or a standard (code 00) label. Any One-Bit Label 191 sorts before any standard label, and a 0 bit sorts before a 1 bit. 192 The absence of a label sorts before any label, as specified in 193 [DNSSEC]. 195 For example, the following domain names are correctly sorted. 197 foo.example 198 \[b1].foo.example 199 \[b100].foo.example 200 \[b101].foo.example 201 bravo.\[b10].foo.example 202 alpha.foo.example 204 4. Processing Rules 206 A One-Bit Label never matches any other kind of label. In 207 particular, the DNS labels represented by the single ASCII 208 characters "0" and "1" do not match One-Bit Labels represented by 209 the bit values 0 and 1. 211 5. Discussion 213 A Count of zero in the wire-form represents a 256-bit sequence, not 214 to optimize that particular case, but to make it completely 215 impossible to have a zero-bit label. 217 6. References 219 [ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 220 Specifications: ABNF", RFC 2234. 222 [DNSCF] P.V. Mockapetris, "Domain names - concepts and facilities", 223 RFC 1034. 225 [DNSIS] P.V. Mockapetris, "Domain names - implementation and 226 specification", RFC 1035. 228 [DNSSEC]D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security 229 Extensions", RFC 2065. 231 [EDNS] P. Vixie, "Extensions to DNS (EDNS)", Currently draft- 232 dnsind-edns-03.txt. 234 [KWORD] S. Bradner, "Key words for use in RFCs to Indicate 235 Requirement Levels," RFC 2119. 237 7. Author's Address 239 Matt Crawford 240 Fermilab MS 368 241 PO Box 500 242 Batavia, IL 60510 243 USA 245 Phone: +1 630 840-3461 247 EMail: crawdad@fnal.gov