idnits 2.17.1 draft-manderson-rdns-xml-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 388 has weird spacing: '...bmitted times...' -- The document date (June 22, 2015) is 3231 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'OASIS' is mentioned on line 271, but not defined == Unused Reference: 'RFC4034' is defined on line 259, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3152 (Obsoleted by RFC 3596) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Manderson 3 Internet-Draft ICANN 4 Intended status: Informational June 22, 2015 5 Expires: December 24, 2015 7 XML Schemas for Reverse DNS Management 8 draft-manderson-rdns-xml-02 10 Abstract 12 This document defines an Extensible Markup Language (XML) Schema for 13 Reverse DNS Management in a tightly controlled Representational State 14 Transfer (REST) environment. This document describes a schema that 15 has been developed and deployed by ICANN in a "RESTful" based system 16 since 2011 and is being used by the registries responsible for 17 reverse DNS (rDNS) delegations underneath IN-ADDR.ARPA and IP6.ARPA 18 through an X.509 certificate mediated HTTPS transaction. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 24, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Implementation . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 62 7.2. Informative References . . . . . . . . . . . . . . . . . 6 63 Appendix A. Schema Definition for rDNS updates . . . . . . . . . 7 64 Appendix B. Schema Definition for rDNS Queue Entries . . . . . . 8 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Requirements Language 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [RFC2119]. 73 2. Introduction 75 This document defines an Extensible Markup Language (XML) Schema for 76 Reverse DNS Management in a tightly controlled Representational State 77 Transfer (REST) [REST] environment. This document describes a schema 78 that has been developed and deployed by ICANN in a "RESTful" based 79 system since 2011 and is being used by the registries responsible for 80 reverse DNS (rDNS) delegations underneath IN-ADDR.ARPA [RFC1034] and 81 IP6.ARPA [RFC3152] through an X.509 [RFC5280] certificate mediated 82 HTTPS [RFC2818] transaction. 84 As DNSSEC [RFC4033] adoption progresses the necessity to interact 85 with a delegation in the IN-ADDR.ARPA and IP6.APRA zones becomes more 86 frequent given that updates to DS records in the parent zone for 87 child delegations follow the key rollover and expiry of the child 88 zone. The modification of such critical areas at a relative high 89 frequency requires a system that allows the administrative holders of 90 such delegations to make such changes in a secure and trustworthy 91 manner where the chain of trust for submitting the necessary 92 information remains unbroken between the IN-ADDR.ARPA and IP6.APRA 93 zone maintainers and the zone customers. 95 At the request of the Regional Internet Registries to automate 96 reverse DNS updates with ICANN, a REST based HTTPS service was 97 deployed that: 99 o Provides for a secure authenticated mechanism to update zone data 100 (NS and DS records) 102 o Provides a well-formed data structure for both the IN-ADDR.ARPA 103 and IP6.ARPA zones 105 o Allows for "out of band" acknowledgement and notification of 106 updates 108 3. Implementation 110 The implemented system allows the entity responsible for its rDNS 111 delegations to effect changes in the reverse DNS zones IN-ADDR.ARPA 112 and IP6.ARPA by submitting an XML document to an atomic RESTful 113 service via a HTTPS [RFC2818] connection. In this service the HTTPS 114 layer provides the end-to-end security of the transaction and it 115 further provides authentication by use of mandatory X.509 [RFC5280] 116 client certificates with a known server certificate issued by a 117 Certificate Authority administered by the service operator. 119 Certificates for use in this system, issued by the system operator, 120 are specific to the entity responsible for the delegations in the 121 zone. 123 Updates are made to the system by using the HTTP [RFC2616] GET, PUT, 124 and DELETE operations over HTTP 1.1 [RFC2616] via HTTPS [RFC2818] 125 only. These operations are sent to a resource Uniform Resource 126 Identifier (URI) in the form of: 128 https://host.example.org// 130 A synthetic example of an XML document submitted to the deployed 131 system might take the following form (including all optional 132 attributes) as per the schema in Appendix A. 134 138 139 BLACKHOLE-1.IANA.ORG. 140 141 142 BLACKHOLE-2.IANA.ORG. 143 144 145 33682 5 1 ea8afb5fce7caf381ab101039 146 147 148 33682 5 2 7d44874f1d93aaceb793a88001739a 149 150 152 When PUT and DELETE operations are used, the well formed XML is 153 required to be sent with the appropriate content-length headers. The 154 GET operation requires only the URI. 156 One requirement of the system was to allow the separation of update 157 and approval with an out of band notification mechanism. When such 158 options are configured for a customer of the service, submitted 159 updates may be queued for later approval. When a customer has queued 160 updates pending approval, the customer may submit a GET request to 161 retrieve either an individual entry, or a full listing of all queued 162 entries. 164 To fetch a listing of the customer's queue the customer would GET a 165 URI in the form of: 167 https://host.example.org/queuelist 169 To fetch an individual queue entry the customer would GET the 170 canonical URL (as per the schema) for this queue record: 172 https://host.example.org/queue/ 174 Were is a system generated and system specific value 175 that identifies this particular queue entry. All XML returned from 176 from queue based operations ('queue' and 'queuelist') would return an 177 XML document following the specification in Appendix B. A synthetic 178 example from a GET of 'queuelist' would be: 180 182 188 189 BLACKHOLE-1.IANA.ORG. 190 191 192 BLACKHOLE-2.IANA.ORG. 193 194 195 33682 5 1 ea8afb5fce7caf381ab101039 196 197 198 33682 5 2 7d44874f1d93aaceb793a88001739a 199 200 201 203 4. IANA Considerations 205 This memo includes no request to IANA. This section may be removed 206 by the RFC Editor prior to publication. 208 5. Security Considerations 210 This document provides an XML schema for facilitating the management 211 of reverse DNS delegations in the IN-ADDR.ARPA and IP6.APRA zones. 212 The schema itself contains no authentication data and all other 213 information contained is considered public data as it is either 214 published in DNS, or propagated to other public information sources 215 like WHOIS. 217 The system which implements this XML schema requires HTTPS to be used 218 and also uses known server and client X.509 certificates for 219 authentication to protect against message modification, message 220 insertion/deletion, man-in-the-middle, and replay attacks. 221 Authorisation for which delegations the X.509 certificate 222 authentication sessions can affect are out of scope of this document, 223 along with any denial of service type attack vectors. 225 6. Acknowledgements 227 An XML schema was initially provided by APNIC, however necessity 228 required a branch and as such a new namespace and schema has been 229 created. Recognition goes to APNIC for prior efforts in this area. 231 The author acknowledges feedback from a collective made up of various 232 RIR technical folk, however heartfelt thanks goes to Anand Buddhdev 233 of the RIPE-NCC and Robert Loomans of APNIC for being both alpha and 234 beta testers and providing valuable feedback. 236 7. References 238 7.1. Normative References 240 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 241 STD 13, RFC 1034, November 1987. 243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14, RFC 2119, March 1997. 246 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 247 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 248 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 250 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 252 [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, 253 August 2001. 255 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 256 Rose, "DNS Security Introduction and Requirements", RFC 257 4033, March 2005. 259 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 260 Rose, "Resource Records for the DNS Security Extensions", 261 RFC 4034, March 2005. 263 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 264 Housley, R., and W. Polk, "Internet X.509 Public Key 265 Infrastructure Certificate and Certificate Revocation List 266 (CRL) Profile", RFC 5280, May 2008. 268 7.2. Informative References 270 [RELAXNG] The Organization for the Advancement of Structured 271 Information Standards [OASIS], "RELAX NG Compact 272 Specification", 2002, . 275 [REST] Fielding, R., "Architectural Styles and the Design of 276 Network-based Software Architectures", 2000, 277 . 280 Appendix A. Schema Definition for rDNS updates 282 The following Schema, used for PUT, GET, and DELETE operations, is an 283 XML document using the RelaxNG Compact [RELAXNG] specification. 285 default namespace = "http://download.research.icann.org/rdns/1.1" 287 # A document may either be a single zone (update) or 288 # a collection of zones (view) 289 start = zone | zonelist | zonereflist 291 # A list of zone names for view only. 292 zonereflist = element zonereflist { 293 attribute version { 294 xsd:decimal { minInclusive="1.1" fractionDigits="1" } 295 }, 296 zoneref* 297 } 299 # A bulk list of zones for view only. 300 zonelist = element zonelist { 301 attribute version { 302 xsd:decimal { minInclusive="1.1" fractionDigits="1" } 303 }, 304 zone* 305 } 307 # A zone reference (accepted by REST engine for query) 308 zoneref = element zoneref { 309 attribute name { text }, 310 attribute href { xsd:anyURI } 311 } 313 # A single zone record 314 zone = element zone { 315 # The zone record's name, eg 10.in-addr.arpa 316 attribute name { text }, 317 # The customer, optional, it is derived from known state. 319 attribute cust { text }?, 320 # The canonical URL for this zone record (optional) 321 attribute href { xsd:anyURI }?, 322 # The address IP version for the zone record (optional) 323 attribute ipversion { "ipv4" | "ipv6" }?, 324 # The administrative state of the zone (optional) 325 attribute state { "active" | "pending" | "error" }?, 326 # The last modified timestamp in UTC (optional) 327 attribute modified { xsd:dateTime }?, 328 # The schema version (optional) 329 attribute version { 330 xsd:decimal { minInclusive="1.1" fractionDigits="1" } 331 }?, 332 # A zone NS RRset MUST have at least two NS records 333 nserver, 334 nserver+, 335 # It MAY contain some DS records 336 ds* 337 } 339 # DNS-SEC records 340 ds = element ds { 341 # rdata MUST contain 342 # | | | 343 # as per RFC4034 344 # 345 element rdata { text } 346 } 348 # A single name server 349 nserver = element nserver { 350 # An nserver entry MUST contain a DNS FQDN 351 # for a NS RR (RFC 1035) 352 element fqdn { text } 353 } 355 Appendix B. Schema Definition for rDNS Queue Entries 357 The XML schema definition below, in RelaxNG Compact [RELAXNG] form is 358 used for queue interaction operations. 360 default namespace = "http://download.research.icann.org/rq/1.0" 362 # A document MAY either be a single queue entry 363 # or a collection of queued entries 364 start = queue | queuelist 365 # A list of zone names for view only. 366 queuelist = element queuelist { 367 attribute version { 368 xsd:decimal { minInclusive="1.0" fractionDigits="0" } 369 }, 370 queue* 371 } 373 # A single queued zone record 374 queue = element queue { 375 # The zone record's name, eg 10.in-addr.arpa 376 attribute name { text }, 377 # The customer, optional, derived from known state. 378 attribute cust { text }?, 379 # The canonical URL for this queue record (optional) 380 attribute href { xsd:anyURI }?, 381 # The acknowlgement URL for this queue record (optional) 382 attribute ack { xsd:anyURI }?, 383 # The address IP version for the zone record (optional) 384 attribute ipversion { "ipv4" | "ipv6" }?, 385 # The state of the zone (optional, and for a queue 386 # SHOULD always be pending) 387 attribute state { "pending" }?, 388 # The submitted timestamp (optional) 389 attribute submitted { xsd:dateTime }?, 390 # The HTTP method used to update 391 attribute method { "PUT" | "DELETE" }, 392 # The schema version (1.0) (optional) 393 attribute version { 394 xsd:decimal { minInclusive="1.0" fractionDigits="1" } 395 }?, 396 # A zone NS RRset must have at least two NS records 397 nserver, 398 nserver+, 399 # It MAY contain some DS records 400 ds* 401 } 403 # DNS-SEC records 404 ds = element ds { 405 # rdata MUST contain Flags | Protocol | Algorithm | Public Key 406 # as per RFC4034 407 # 408 element rdata { text } 409 } 411 # A single name server 412 nserver = element nserver { 413 # An nserver entry MUST contain a DNS FQDN 414 # for a NS RR (RFC 1035) 415 element fqdn { text } 416 } 418 Author's Address 420 Terry Manderson 421 ICANN 423 Email: terry.manderson@icann.org