idnits 2.17.1 draft-hallambaker-xptr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 307. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 320. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 137 has weird spacing: '...ordType recor...' == Line 165 has weird spacing: '...ordType recor...' -- 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 (June 29, 2007) is 6118 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBS' is mentioned on line 71, but not defined Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Hallam-Baker 3 Internet-Draft VeriSign Inc 4 Intended status: Informational June 29, 2007 5 Expires: December 31, 2007 7 XPTR: DNS Prefix Pointer 8 draft-hallambaker-xptr-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 31, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The DNS XPTR resource record is defined. An XPTR record may be used 42 in combination with prefixed DNS records to create the effect of 43 wildcarding and to simplify management where prefixed records are 44 employed on an extended scale. 46 Table of Contents 48 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Resolving Prefix records with XPTR . . . . . . . . . . . . . . 4 52 3.1. Basic Prefix Resolution . . . . . . . . . . . . . . . . . . 4 53 3.2. Reverse Prefix Resolution . . . . . . . . . . . . . . . . . 4 54 4. Using XPTR . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4.1. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.2. Policy Administration . . . . . . . . . . . . . . . . . . . 6 57 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 60 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 Intellectual Property and Copyright Statements . . . . . . . . . . 8 64 1. Definitions 66 The following definitions are used in this document: 68 DNS Resource Record A DNS Resource Record as defined in [TBS] 70 Prefixed Record A DNS Resource Record in which one or more labels 71 contain characters that are not valid DNS host names. [TBS] 73 1.1. Requirements Language 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC 2119 [RFC2119]. 79 2. Introduction 81 Prefixed resource records, first introduced in the SRV specification 82 provide a means of extending the DNS without allocating a new 83 resource record 85 The principle disadvantage faced when using prefixed DNS records is 86 that the existing DNS specifications do not provide a 'midpoint 87 wildcard' of the form _prefix.*.example.com. While a DNS server can 88 implement such a wildcard in response to a DNS query as a 'synthetic' 89 wildcard this usage is not compatible with the mechanisms of DNSSEC 90 or Zone Transfer. 92 While support for wildcarding of prefixed records has not been 93 considered an essential requirement in service discovery applications 94 such as SRV and NAPTR, wildcarding is considered an essential 95 requirement for publication of protocol policy statements. In 96 particular the ability to make policy statements of the form 'All 97 mail from *.example.com is signed' is frequently a requirement. 99 While such a requirement could be satisified by issuing separate DNS 100 RRs for each protocol policy advertisement, this approach is only 101 acceptable if the number of policy advertisements is expected to be 102 small. While the number of official prefix registrations is small, 103 informal registrations number in excess of 500 in June 2007. This 104 number is likely to rise rapidly as the use of Web Services 105 increases. 107 The DNS resource record is expressed as a fixed 16 bit field giving 108 65,336 possible values. An architecture which limits the Internet to 109 65,336 possible protocols for machine-machine interaction is not 110 sustainable. 112 3. Resolving Prefix records with XPTR 114 XPTR allows a resolution algorithm to be defined that supports the 115 use of wildcards in conjunction with prefixed DNS records by 116 introducing an additional step of indirection. Although a wildcard 117 cannot be applied to prefixed DNS record itself, a wildcard can be 118 applied to the XPTR indirection record. 120 3.1. Basic Prefix Resolution 122 The basic XPTR prefix resolution (basic) algorithm MAY be specified 123 as the means of resolving a particular DNS record prefix. 125 The basic resolution algorithm resolves a triple consisting of a DNS 126 node, a DNS prefix label and a DNS record type. The resolution 127 algorithm returns either the record requested or the result ?not 128 present?. 130 The resolution algorithm always produces a result in a maximum of 131 three steps when applied to DNS nodes in the forward DNS. The 132 requestor first looks for a prefix record at the query node itself. 133 If this search fails the requestor looks for a PREPTR record at the 134 query node and if this is found: 136 Record BasicPrefixResolve ( 137 String node, String prefix, RecordType record) 138 1. Record F1 = Lookup (prefix + "." + node, record) 139 If (F1 <> NIL) Return F1 140 2. Record F2 = Lookup (node, PREPTR) 141 If (F2 = NIL) Return NIL 142 3. Record F3 = Lookup (prefix + "." + F2.domain) 143 Return F3 145 3.2. Reverse Prefix Resolution 147 In most cases an Internet service is identified by means of a domain 148 name. In certain circumstances it is desirable to perform service 149 and policy discovery by means of the IP address. This requirement is 150 most likely to occur in protocols for real time reporting of security 151 incidents where the IP address of the source of attack is known with 152 some degree of certainty, but not a domain name. 154 In such situations the service discovery process MAY specify the use 155 of the Reverse DNS. The reverse DNS is an area of the DNS space (in- 156 addr.arpa, ipv6.arpa). A PTR record in the reverse DNS maps an IPv4 157 or IPv6 address to a DNS name. 159 Depending on the requirements of the service it MAY be desirable for 160 discovery to process XPTR records in the reverse DNS directly or to 161 first attempt to follow a PTR record to obtain a DNS node where basic 162 prefix resolution is to be performed. 164 Record ReversePrefixResolve( 165 IPAddress address, String prefix, RecordType record) 166 1. Record R1 = Lookup (prefix + "." + 167 ReverseToNode (address), record) 168 If (F1 <> NIL) Return F1 169 2. Record R2 = Lookup (node, ReverseToNode (address) 170 If (R2 = NIL) Return NIL 171 Else Return BasicPrefixResolve (R2.domain, prefix, record) 173 4. Using XPTR 175 XPTR may be used to simplfy administration of prefixed DNS records 176 and to permit the resolution of wildcard DNS records. 178 4.1. Wildcards 180 In order to illustrate the use of XPTR we consider the resolution of 181 a hypothetical Internet protocol 'NOOP'. 183 The discovery protocol for NOOP is specified as using SRV with the 184 basic prefix resolution protocol. There is no default port 185 assignment. 187 All service requests for the 'NOOP' service with SRV Prefix _noop in 188 the domain example.com are to be directed to the main noop server, 189 except for the mathematics department math.example.com which has its 190 own server. 192 The zone file is: 194 _noop._tcp.example.com SRV 1 1 80 noop.example.com 195 _noop._tcp.math.example.com SRV 1 1 80 math.example.com 197 h1.example.com A 10.1.1.1 198 h1.example.com XPTR example.com 199 *.example.com XPTR example.com 201 Although XPTR addresses the lack of a DNS midpoint wildcard it does 202 not address the fact that the semantics of DNS wildcards are 203 considerably more restrictive than is generally convenient and a DNS 204 wildcard only binds to a DNS zone if there are no other records of 205 any type defined for that node. It is therefore necessary to specify 206 an XPTR record for the node h1.example.com which is outside the scope 207 of the wildcard. 209 4.2. Policy Administration 211 We hypothecate the existence of a protocol policy prefixes 212 _a._policy, _b._policy etc. to be used to specify protocol 213 configuration options. 215 The administrator of example.com has three basic types of machine; 216 desktops, laptops and servers. The range of services a particular 217 machine is allowed to offer is determined by its class. Instead of 218 defining the protocol configuration policy for each machine 219 individually the administrator specifies an XPTR record to direct 220 resolution to a node where the characteristics for the whole class 221 are defined: 223 _a._policy.laptop.example.com TXT "SSL=always" 224 _b._policy.laptop.example.com TXT "MinVersion=2.3 MaxVersion=3.4" 226 _a._policy.desktop.example.com TXT "" 227 _b._policy.desktop.example.com TXT "MinVersion=2.1 MaxVersion=3.4" 229 _a._policy.server.example.com TXT "" 230 _b._policy.server.example.com TXT "MinVersion=1.0 MaxVersion=3.4" 232 alice.example.com XPTR laptop.example.com 233 bob.example.com XPTR laptop.example.com 234 carol.example.com XPTR desktop.example.com 235 doug.example.com XPTR laptop.example.com 236 _b._policy.doug.example.com TXT "MinVersion=2.3 MaxVersion=3.4" 237 edward.example.com XPTR server.example.com 238 mail.example.com XPTR server.example.com 240 The default policy may be overriden as necessary by a policy declared 241 at the specific node. In this case the administrator has overriden 242 policy B for doug.example.com. 244 5. Acknowledgements 246 The ideas in this document arose from extensive discussions with the 247 DKIM and DNSEXT working groups. 249 6. IANA Considerations 251 This document requests allocation of a DNS Resource Record for the 252 XPTR record. 254 7. Security Considerations 256 The XPTR record does not change the security model or field of 257 application of DNS. It does however make it more likely that DNS 258 will be used in situations where the need for robust integrity and 259 authenticity controls such as those provided by DNSSEC will become 260 more apparent. 262 In particular it is highly desirable for a prefixed record used to 263 distribute a security policy to be signed. 265 In cases where an XPTR directs resolution of prefixed records to a 266 DNS zone that is under a different administrative control regime, 267 administrative control and the ability to enforce security controls 268 is transfered to another party. 270 8. Normative References 272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 273 Requirement Levels", BCP 14, RFC 2119, March 1997. 275 Author's Address 277 Phillip Hallam-Baker 278 VeriSign Inc 280 Email: pbaker@verisign.com 282 Full Copyright Statement 284 Copyright (C) The IETF Trust (2007). 286 This document is subject to the rights, licenses and restrictions 287 contained in BCP 78, and except as set forth therein, the authors 288 retain all their rights. 290 This document and the information contained herein are provided on an 291 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 292 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 293 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 294 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 295 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 296 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 298 Intellectual Property 300 The IETF takes no position regarding the validity or scope of any 301 Intellectual Property Rights or other rights that might be claimed to 302 pertain to the implementation or use of the technology described in 303 this document or the extent to which any license under such rights 304 might or might not be available; nor does it represent that it has 305 made any independent effort to identify any such rights. Information 306 on the procedures with respect to rights in RFC documents can be 307 found in BCP 78 and BCP 79. 309 Copies of IPR disclosures made to the IETF Secretariat and any 310 assurances of licenses to be made available, or the result of an 311 attempt made to obtain a general license or permission for the use of 312 such proprietary rights by implementers or users of this 313 specification can be obtained from the IETF on-line IPR repository at 314 http://www.ietf.org/ipr. 316 The IETF invites any interested party to bring to its attention any 317 copyrights, patents or patent applications, or other proprietary 318 rights that may cover technology that may be required to implement 319 this standard. Please address the information to the IETF at 320 ietf-ipr@ietf.org. 322 Acknowledgment 324 Funding for the RFC Editor function is provided by the IETF 325 Administrative Support Activity (IASA).