idnits 2.17.1 draft-ietf-dnsind-binary-labels-01.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-27) 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. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. 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 (March 9, 1998) is 9546 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 192, but not defined ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNK' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 3 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 March 9, 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 learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet Drafts 23 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 25 Rim). 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 catch-all Additional Section processing rule 46 provides a form of longest-match lookup which is useful when the 47 name 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| ELC | Count | Label ... | 68 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+ 70 (Each tic mark represents one bit.) 72 ELC The six-bit Extended Label Code [UNK] assigned to the 73 Bit-String Label. [TBA. 0?] 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 ABNF [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 = NZDIGIT *2DIGIT 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 place in the DNS tree as any of the above 167 single Bit-String Labels. 169 \[b11101/5].\[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 group into multiple consecutive Bit-String 175 Labels. For generating and checking DNS signature records [DNSSEC] 176 binary labels must be in a predictable form. This canonical form is 177 defined as the form which has the fewest possible Bit-String Labels 178 and in which all except possibly the first (least significant) label 179 in any sequence of consecutive Bit-String Labels is of maximum 180 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, as specified in [DNSSEC], sorts before any 193 label. 195 For example, the following domain names are correctly sorted. 197 foo.tld 198 \[b1].foo.tld 199 \[b100].foo.tld 200 \[b101].foo.tld 201 bar.\[b10].foo.tld 202 baz.foo.tld 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 When an authoritative server processes a query which includes a 212 Bit-String Label in the QNAME, a special "longest-match" processing 213 rule is invoked in two cases. The following definition will be 214 helpful in explaining the longest-match rule. 216 A "binary ancestor" of a given domain name "D" is another domain 217 name "A" which is a suffix of D obtainable by removing one or more 218 least-significant One-Bit Labels from D. Among several binary 219 ancestors of D which satisfy a certain condition, the "nearest 220 binary ancestor" is that binary ancestor which is obtained by 221 removing the fewest One-Bit Labels from D. 223 As an example, the domain name 225 \[b1011].foo.\[b0011].example 227 Has exactly four binary ancestors, which are, from nearest to 228 farthest, 229 \[b101].foo.\[b0011].example 230 \[b10].foo.\[b0011].example 231 \[b1].foo.\[b0011].example 232 foo.\[b0011].example 234 The first case in which the longest-match rule MUST be invoked is 235 when a match to the QNAME becomes impossible at a certain One-Bit 236 Label (that is, the algorithm of RFC1034's section 4.3.2 reaches 237 step 3.c. [DNSCF]), and the "*" label does not exist at that point. 238 Let Q1 be the label at which the match to QNAME became impossible, 239 and let Q2 be the nearest binary ancestor of Q1 which has an RRs 240 which match QTYPE. The server MUST copy those RRs from Q2 to the 241 Additional Section of the reply. The RCODE is set as in RFC1034: to 242 Name Error if the failing QNAME is the name from the original query, 243 or to No Error if the failing QNAME was obtained by following a 244 CNAME. 246 The second case of application of the longest-match rule is when the 247 whole of QNAME is matched (step 3.a. of the above-referenced 248 algorithm), but no RRs are present which match the QTYPE. Again, 249 RRs which match QTYPE MUST copied from the nearest binary ancestor 250 which has such RRs to the Additional Section of the reply. The 251 RCODE MUST be set to No Error. 253 In both cases, if the server reaches a zone boundary before finding 254 a suitable binary ancestor, it MUST copy the SOA record of the zone 255 to the additional section. If and only if the server is 256 authoritative for the parent zone also, then it MAY continue 257 searching for the nearest binary ancestor in the parent zone. If 258 appropriate RRs are found at a binary ancestor in an ancestor zone, 259 they MUST be placed after the SOA record(s) of the lower zone(s). 261 5. Discussion 263 A Count of zero in the wire-form represents a 256-bit sequence, not 264 to optimize that particular case, but to make it completely 265 impossible to have a zero-bit label. The only sensible meaning I 266 can attach to a zero-bit label is a synonym for the DNS root, and 267 such a thing must not exist. (IMHO, of course.) This point is not 268 universally agreed. 270 I expect that the primary use of the "*" label below a One-Bit Label 271 will be to block the action of the longest-match rule. 273 Paul Vixie is preparing a draft defining what I have tentatively 274 called "extended label codes" in section 3.1. 276 Does the longest-match rule need examples? Motivation? 278 6. Acknowledgments 280 Jerry Scharf suggested the backslash, which was an improvement over 281 my very lame initial notation. Paul Vixie suggested that the 282 dotted-quad notation be supported. They should not be assumed to 283 support every choice represented in this draft, however. 285 7. References 287 [ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 288 Specifications: ABNF", RFC 2234. 290 [DNSCF] P.V. Mockapetris, "Domain names - concepts and facilities", 291 RFC 1034. 293 [DNSIS] P.V. Mockapetris, "Domain names - implementation and 294 specification", RFC 1035. 296 [DNSSEC]D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security 297 Extensions", RFC 2065. 299 [KWORD] S. Bradner, "Key words for use in RFCs to Indicate 300 Requirement Levels," RFC 2119. 302 [UNK] P. Vixie, Work in progress. 304 8. Author's Address 306 Matt Crawford 307 Fermilab MS 368 308 PO Box 500 309 Batavia, IL 60510 310 USA 312 Phone: +1 630 840-3461 314 EMail: crawdad@fnal.gov