idnits 2.17.1 draft-ietf-dnsind-binary-labels-00.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-26) 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 is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (February 19, 1998) is 9563 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) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 2 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 February 19, 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 any 34 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 assigned to the Bit-String 73 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 4. Processing Rules 173 A One-Bit Label never matches any other kind of label. In 174 particular, the DNS labels represented by the single ASCII 175 characters "0" and "1" do not match One-Bit Labels represented by 176 the bit values 0 and 1. 178 When an authoritative server processes a query which includes a 179 Bit-String Label in the QNAME, a special "longest-match" processing 180 rule is invoked in two cases. The following definition will be 181 helpful in explaining the longest-match rule. 183 A "binary ancestor" of a given domain name "D" is another domain 184 name "A" which is a suffix of D obtainable by removing one or more 185 least-significant One-Bit Labels from D. Among several binary 186 ancestors of D which satisfy a certain condition, the "nearest 187 binary ancestor" is that binary ancestor which is obtained by 188 removing the fewest One-Bit Labels from D. 190 As an example, the domain name 192 \[b1011].foo.\[b0011].example 194 Has exactly four binary ancestors, which are, from nearest to 195 farthest, 197 \[b101].foo.\[b0011].example 198 \[b10].foo.\[b0011].example 199 \[b1].foo.\[b0011].example 200 foo.\[b0011].example 202 The first case in which the longest-match rule MUST be invoked is 203 when a match to the QNAME becomes impossible at a certain One-Bit 204 Label (that is, the algorithm of RFC1034's section 4.3.2 reaches 205 step 3.c. [DNSCF]), and the "*" label does not exist at that point. 206 Let Q1 be the label at which the match to QNAME became impossible, 207 and let Q2 be the nearest binary ancestor of Q1 which has an RRs 208 which match QTYPE. The server MUST copy those RRs from Q2 to the 209 Additional Section of the reply. The RCODE is set as in RFC1034: to 210 Name Error if the failing QNAME is the name from the original query, 211 or to No Error if the failing QNAME was obtained by following a 212 CNAME. 214 The second case of application of the longest-match rule is when the 215 whole of QNAME is matched (step 3.a. of the above-referenced 216 algorithm), but no RRs are present which match the QTYPE. Again, 217 RRs which match QTYPE MUST copied from the nearest binary ancestor 218 which has such RRs to the Additional Section of the reply. The 219 RCODE MUST be set to No Error. 221 In both cases, if the server reaches a zone boundary before finding 222 a suitable binary ancestor, it MUST copy the SOA record of the zone 223 to the additional section. If and only if the server is 224 authoritative for the parent zone also, then it MAY continue 225 searching for the nearest binary ancestor in the parent zone. If 226 appropriate RRs are found at a binary ancestor in an ancestor zone, 227 they MUST be placed after the SOA record(s) of the lower zone(s). 229 5. Discussion 231 A Count of zero in the wire-form represents a 256-bit sequence, not 232 to optimize that particular case, but to make it completely 233 impossible to have a zero-bit label. The only sensible meaning I 234 can attach to a zero-bit label is a synonym for the DNS root, and 235 such a thing must not exist. (IMHO, of course.) This point is not 236 universally agreed. 238 It is expected that the primary use of the "*" label below a One-Bit 239 Label will be to block the action of the longest-match rule. 241 Paul Vixie is preparing a draft defining what I have tentatively 242 called "extended label codes" in section 3.1.. 244 Does the longest-match rule need examples? Motivation? 246 6. Acknowledgments 248 Jerry Scharf suggested the backslash, which was an improvement over 249 my very lame initial notation. Paul Vixie suggested that the 250 dotted-quad notation be supported. They should not be assumed to 251 support every choice represented in this draft, however. 253 7. References 255 [ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 256 Specifications: ABNF", RFC 2234. 258 [DNSCF] P.V. Mockapetris, "Domain names - concepts and facilities", 259 RFC 1034. 261 [DNSIS] P.V. Mockapetris, "Domain names - implementation and 262 specification", RFC 1035. 264 [KWORD] S. Bradner, "Key words for use in RFCs to Indicate 265 Requirement Levels," RFC 2119. 267 8. Author's Address 269 Matt Crawford 270 Fermilab MS 368 271 PO Box 500 272 Batavia, IL 60510 273 USA 275 Phone: +1 630 840-3461 277 EMail: crawdad@fnal.gov