idnits 2.17.1 draft-ietf-ipngwg-dns-lookups-00.txt: ** The Abstract section seems to be numbered 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 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 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. 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 13, 1998) is 9541 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) == Outdated reference: A later version (-05) exists of draft-ietf-dnsind-binary-labels-01 ** Downref: Normative reference to an Historic draft: draft-ietf-dnsind-binary-labels (ref. 'BITLBL') == Outdated reference: A later version (-03) exists of draft-ietf-dnsind-dname-00 ** Obsolete normative reference: RFC 2065 (ref. 'DNSSEC') (Obsoleted by RFC 2535) == Outdated reference: A later version (-03) exists of draft-ietf-dnsind-edns-01 -- Possible downref: Normative reference to a draft: ref. 'EDNS' Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPng Working Group Matt Crawford 2 Internet Draft Fermilab 3 March 13, 1998 5 DNS Lookups Keyed on IPv6 Addresses 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 ftp.is.co.za (Africa), ftp.nordu.net (North 24 Europe), ftp.nis.garr.it (South Europe), ds.internic.net (US East 25 Coast), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 Distribution of this memo is unlimited. 29 1. Abstract 31 This document defines a new structure for the zones which support 32 DNS lookups keyed on IPV6 addresses. (Often called reverse 33 lookups.) It allows address space to be delegated on arbitrary 34 bit-boundaries. The delegation information can be be usefully 35 cached. A zone describing delegated space can be used for multiple 36 parallel copies of that address space, as for a dual-homed provider 37 or site, and need not be modified if the space is renumbered at a 38 higher level. 40 The new structure can coexist with the old tree under the same name, 41 IP6.INT. 43 2. Background 45 To fulfill the grand claims made in the abstract, this document 46 relies on new DNS features described in Internet-Drafts designated 47 [BITLBL], [DNAME], and [EDNS]. This first draft is a working 48 document intended only to sketch the new structure with the 49 intention of convincing the reader that the above claims are 50 realistic. 52 3. Underlying Mechanisms 54 This section describes the new proposed new DNS features which this 55 document exploits. The reader is directed to the referenced drafts 56 for more details on each. 58 3.1. Delegation on Arbitrary Boundaries 60 This new scheme for reverse lookups relies on a new type of DNS 61 label called the "bit-string label" [BITLBL]. This label compactly 62 represents an arbitrary string of bits which is treated as a 63 hierarchical sequence of one-bit domain labels. Resource records 64 can be stored on arbitrary bit-boundaries and bit-string label 65 processing is subject to a longest-match rule which will return 66 records from the nearest ancestor node which has them if the 67 requested information cannot be found at the queried name itself. 69 Examples in section 4 will employ the following textual format for 70 bit-string labels. A base indicator, either "b" for binary or "x" 71 for hexadecimal, and sequence of digits in the indicated base is 72 enclosed between "\[x" and "]". The bits denoted by the digits 73 represent a sequence of one-bit domain labels ordered from most to 74 least significant. (This is the opposite of the order they would 75 appear if listed one bit at a time, but it appears to be a 76 convenient notation.) The digit string may be followed by a slash 77 ("/") and a decimal count. If omitted, the implicit count is equal 78 to the number of binary digits or four times the number of 79 hexadecimal digits. 81 Consecutive bit-string labels are equivalent (up to the limit 82 imposed by the size of the bit count field) to a single bit-string 83 label containing all the bits of the consecutive labels in the 84 proper order. As an example, either of the following domain names 85 could be used in a QCLASS=IN, QTYPE=PTR query to find the name of 86 the node with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32. 88 \[x3FFE07C0004000090A0020FFFE812B32/128].ip6.int. 90 \[x0A0020FFFE812B32/64].\[x0009/16]. 91 \[x07C00040/32].\[xFFF0/13].\[b001/3].ip6.int. 93 None of the bit counts in the either form are required except the 94 "/13". Note that bits are left-justified in a hexadecimal string. 96 3.2. Reusable Zones 98 DNS address space delegation is implemented not by zone cuts and NS 99 records, but by a new analogue to the CNAME record, called the DNAME 100 record [DNAME]. The DNAME record provides alternate naming to an 101 entire subtree of the domain name space, rather than to a single 102 node. It causes some suffix of a queried name to be substituted 103 with a name from the DNAME record's RDATA. 105 For example, a resolver or server providing recursion, while looking 106 up a QNAME a.b.c.d.e.tld may encounter a DNAME record 108 d.e.tld. DNAME w.xy. 110 which will cause it to look for a.b.c.w.xy. 112 3.3. Coexistence 114 All data supporting the new reverse lookup scheme will be stored at 115 DNS nodes whose names include at least one bit-string label. By 116 issuing a query for such a name, a resolver indicates that it 117 understands the new label type [EDNS]. Alternatively, a resolver 118 can indicate its compliance with EDNS features by inclusion of a new 119 OPT RR in a query. 121 4. Zone Structure 123 Very little of the new scheme's data actually appears under IP6.INT. 124 Only the first level of delegation needs to be under that (or 125 another fixed and well-known) domain, although more levels of 126 delegation could be done under IP6.INT if some top-level delegations 127 were done via NS records instead of DNAME records. This would incur 128 a possibly-negligible cost in loss of renumbering ease at the level 129 of TLAs [AARCH]. The examples which follow assume that delegations 130 by NS records are not done. 132 4.1. The Top Level 134 Supposing that address space assignments in the TLAs with Format 135 Prefix (001) binary and IDs 1, 2 and 3 were maintained in zones 136 called alpha-registry.tld, bravo.tla.nil and charlie-net.xy, the 137 IP6.INT zone would include 139 $ORIGIN IP6.INT. 140 \[x200100/24] DNAME alpha-registry.tld. 141 \[x200200/24] DNAME bravo.tla.nil. 142 \[x200300/24] DNAME charlie-net.xy. 144 Eight trailing zero bits have been included in each TLA ID to 145 reflect the eight reserved bits in the current aggregatable global 146 unicast addresses format [AARCH]. 148 4.2. The TLA level 150 Now suppose that Alpha-Registry has assigned the prefixes 151 2001:0:4000::0/34, 2001:1:200::0/39 and 2001:2:20::0/43 to a large 152 ISP, a medium-sized ISP, and a corporation with a network linking 25 153 sites. Its zone could record these assignments as 155 $ORIGIN alpha-registry.tld. 156 @ TXT "This domain delegates from a /24 prefix" 157 \[x004/10] DNAME ip6-addr.big-isp.example. 158 \[x0102/15] DNAME nla-space.med-isp.example. 159 \[x02002/19] DNAME site-register.world-wide-widgets.tld. 161 4.3. The ISP level 163 The medium-sized ISP of the previous section might list a lower- 164 level ISP and two customer sites in its zone as follows. 166 $ORIGIN nla-space.med-isp.example. 167 @ TXT "This domain delegates from a /39 prefix" 168 \[b001/3] DNAME customers.small-isp.example. 169 \[x800/9] DNAME reverse-zone.example.com. 170 \[x808/9] DNAME sla.example.org. 172 The last-listed customer site might be dual-homed to Big-ISP, who 173 delegates it another global prefix. 175 $ORIGIN ip6-addr.big-isp.example. 176 @ TXT "This domain delegates from a /34 prefix" 177 \[x1234/14] DNAME sla.example.org. 179 Note the same domain name in this DNAME record. The customer will 180 use the same zone to map both global prefixes. 182 4.4. The Site Level 184 Consider the customer Example.Org using sla.example.org for 185 address-to-name translations. This domain is now referenced by two 186 different DNAME records held by two different providers. 188 $ORIGIN \[x0001/16].sla.example.org. ; subnet 1 189 \[x020855FFFE012345] PTR www.example.org. 190 \[x020855FFFE345678] PTR ns1.example.org. 191 $ORIGIN \[x0001/16].sla.example.org. ; subnet 2 192 \[x020855FFFE67890A] PTR mailhub.example.org. 194 5. Lookups 196 A DNS resolver looking for a hostname for the address 197 2001:1:301:1:208:55ff:fe01:2345 would acquire certain of the DNAME 198 records shown above and would form new queries. Assuming that it 199 began the process knowing servers for IP6.INT, but that no server it 200 consulted provided recursion and none had other useful additional 201 information cached, the sequence of queried names and responses 202 would be: 204 To a server for ip6.int: 205 QTYPE=PTR QNAME=\[x2001000103010001020855fffe012345/128].ip6.int. 207 Answer: 208 \[x200100/24].ip6.int. DNAME alpha-registry.tld. 210 To a server for alpha-registry.tld: 211 QTYPE=PTR QNAME=\[x0103010001020855fffe012345/104].alpha-registry.tld. 213 Answer: 214 \[x0102/15].alpha-registry.tld. DNAME nla-space.med-isp.example. 216 To a server for nla-space.med-isp.example: 217 QTYPE=PTR QNAME=\[x80800081042affff0091a28/89]. 218 nla-space.med-isp.example. 220 Answer: 221 \[x808/9].nla-space.med-isp.example. DNAME sla.example.org. 223 To a server for sla.example.org: 224 QTYPE=PTR QNAME=\[x0001020855fffe012345].sla.example.org. 226 Answer: 227 \[x0001020855fffe012345].sla.example.org. PTR www.example.org. 229 All the DNAME (and NS) records acquired along the way can be cached 230 to expedite resolution of addresses topologically near to this 231 address. And if the other global address of www.example.org were 232 resolved within the TTL of the final PTR record, that record would 233 not have to be fetched again. 235 6. Uniformity 237 The examples above assume that organizations conspicuously fail to 238 employ any sort of uniform naming convention for the part of their 239 DNS space in which they record address delegations and assignments. 240 Registries, network providers and sites might benefit from such a 241 convention. 243 7. Security Considerations 245 DNS Security [DNSSEC] is fully applicable to bit-string labels and 246 DNAME records. However, authentication of data in the reverse zones 247 is not equivalent to authentication of any "forward" data, such as 248 AAAA records. 250 8. References 252 [AARCH] R. Hinden, S. Deering, "IP Version 6 Addressing 253 Architecture", Currently draft-ietf-ipngwg-addr-arch-v2- 254 06.txt. 256 [BITLBL] M. Crawford, "Binary Labels in the Domain Name System", 257 currently draft-ietf-dnsind-binary-labels-01.txt. 259 [DNAME] M. Crawford, "Non-Terminal DNS Name Redirection", currently 260 draft-ietf-dnsind-dname-00.txt. 262 [DNSSEC] D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security 263 Extensions", RFC 2065. 265 [EDNS] P. Vixie, "Extensions to DNS (EDNS)" currently draft-ietf- 266 dnsind-edns-01.txt. 268 9. Author's Address 270 Matt Crawford 271 Fermilab MS 368 272 PO Box 500 273 Batavia, IL 60510 274 USA 276 Phone: +1 630 840-3461 278 EMail: crawdad@fnal.gov