[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 01 02 RFC 7745

Internet Engineering Task Force                             T. Manderson
Internet-Draft                                                     ICANN
Intended status: Informational                            March 19, 2013
Expires: September 20, 2013


                 XML Schemas for Reverse DNS Management
                      draft-manderson-rdns-xml-01

Abstract

   This document defines an Extensible Markup Language (XML) Schema for
   Reverse DNS Management in a tightly controlled Representational State
   Transfer (REST) environment.  This document describes a schema that
   has been developed and deployed by ICANN in a "RESTful" based system
   since 2011 and is being used by the registries responsible for
   reverse DNS (rDNS) delegations underneath IN-ADDR.ARPA and IP6.ARPA
   through an X.509 certificate mediated HTTPS transaction.

Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 20, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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.




Manderson              Expires September 20, 2013               [Page 1]


Internet-Draft             Abbreviated Title                  March 2013


Table of Contents

   1.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Implementation  . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Schema Definition for rDNS updates . . . . . . . . .   7
   Appendix B.  Schema Definition for rDNS Queue Entries . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Introduction

   This document defines an Extensible Markup Language (XML) Schema for
   Reverse DNS Management in a tightly controlled Representational State
   Transfer (REST) [REST] environment.  This document describes a schema
   that has been developed and deployed by ICANN in a "RESTful" based
   system since 2011 and is being used by the registries responsible for
   reverse DNS (rDNS) delegations underneath IN-ADDR.ARPA [RFC1034] and
   IP6.ARPA [RFC3152] through an X.509 [RFC5280] certificate mediated
   HTTPS [RFC2818] transaction.

   As DNSSEC [RFC4033]  adoption progresses the necessity to interact
   with a delegation in the IN-ADDR.ARPA and IP6.APRA zones becomes more
   frequent given that updates to DS records in the parent zone for
   child delegations follow the key rollover and expiry of the child
   zone.  The modification of such critical areas at a relative high
   frequency requires a system that allows the administrative holders of
   such delegations to make such changes in a secure and trustworthy
   manner where the chain of trust for submitting the necessary
   information remains unbroken between the IN-ADDR.ARPA and IP6.APRA
   zone maintainers and the zone customers.

   At the request of the Regional Internet Registries to automate
   reverse DNS updates with ICANN, a REST based HTTPS service was
   deployed that:





Manderson              Expires September 20, 2013               [Page 2]


Internet-Draft             Abbreviated Title                  March 2013


   o  Provides for a secure authenticated mechanism to update zone data
      (NS and DS records)

   o  Provides a well-formed data structure for both the IN-ADDR.ARPA
      and IP6.ARPA zones

   o  Allows for "out of band" acknowledgement and notification of
      updates

3.  Implementation

   The implemented system allows the entity responsible for its rDNS
   delegations to effect changes in the reverse DNS zones IN-ADDR.ARPA
   and IP6.ARPA by submitting an XML document to an atomic RESTful
   service via a HTTPS [RFC2818] connection.  In this service the HTTPS
   layer provides the end-to-end security of the transaction and it
   further provides authentication by use of mandatory X.509 [RFC5280]
   client certificates with a known server certificate issued by a
   Certificate Authority administered by the service operator.

   Certificates for use in this system, issued by the system operator,
   are specific to the entity responsible for the delegations in the
   zone.

   Updates are made to the system by using the HTTP [RFC2616] GET, PUT,
   and DELETE operations over HTTP 1.1 [RFC2616] via HTTPS [RFC2818]
   only.  These operations are sent to a resource Uniform Resource
   Identifier (URI) in the form of:

                  https://host.example.org/<ipversion>/<zone>


   A synthetic example of an XML document (in RelaxNG Compact [RELAXNG]
   format) submitted to the deployed system might take the following
   form (including all optional attributes) as per the schema in
   Appendix A.

        <zone xmlns="http://download.research.icann.org/rdns/1.1"
          name="10.in-addr.arpa" cust="IANA" ipversion="ipv4"
          version="1.1" modified="2012-01-18T01:00:06"
          state="active" href="https://host.example.org/ipv4/10">
          <nserver>
            <fqdn>BLACKHOLE-1.IANA.ORG.</fqdn>
          </nserver>
          <nserver>
            <fqdn>BLACKHOLE-2.IANA.ORG.</fqdn>
          </nserver>
          <ds>



Manderson              Expires September 20, 2013               [Page 3]


Internet-Draft             Abbreviated Title                  March 2013


            <rdata>33682 5 1 ea8afb5fce7caf381ab101039</rdata>
          </ds>
          <ds>
            <rdata>33682 5 2 7d44874f1d93aaceb793a88001739a</rdata>
          </ds>
        </zone>


   When PUT and DELETE operations are used, the well formed XML is
   required to be sent with the appropriate content-length headers.  The
   GET operation requires only the URI.

   One requirement of the system was to allow the separation of update
   and approval with an out of band notification mechanism.  When such
   options are configured for a customer of the service, submitted
   updates may be queued for later approval.  When a customer has queued
   updates pending approval, the customer may submit a GET request to
   retrieve either an individual entry, or a full listing of all queued
   entries.

   To fetch a listing of the customer's queue the customer would 'GET' a
   URI in the form of:

                      https://host.example.org/queuelist


   To fetch an individual queue entry the customer would 'GET' the
   canonical URL (as per the schema) for this queue record:

                  https://host.example.org/queue/<identifier>


   Were "identifier" is a system generated and system specific value
   that identifies this particular queue entry.  All XML returned from
   from queue based operations ('queue' and 'queuelist') would return an
   XML document following the specification in Appendix B.  A synthetic
   example from a GET of 'queuelist' would be:

       <queuelist xmlns="http://download.research.icann.org/rq/1.0"
        version="1.0">
        <queue xmlns="http://download.research.icann.org/rq/1.0"
         name="10.in-addr.arpa" cust="IANA" ipversion="ipv4"
         version="1.0" submitted="2013-01-11T05:22:15"
         state="pending" method="PUT"
         ack="https://host.example.org/ack/25a531f50e5ba45"
         href="https://host.example.org/queue/25a531f50e5ba45">
         <nserver>
           <fqdn>BLACKHOLE-1.IANA.ORG.</fqdn>



Manderson              Expires September 20, 2013               [Page 4]


Internet-Draft             Abbreviated Title                  March 2013


         </nserver>
         <nserver>
           <fqdn>BLACKHOLE-2.IANA.ORG.</fqdn>
         </nserver>
         <ds>
           <rdata>33682 5 1 ea8afb5fce7caf381ab101039</rdata>
         </ds>
         <ds>
           <rdata>33682 5 2 7d44874f1d93aaceb793a88001739a</rdata>
         </ds>
        </queue>
       </queuelist>


4.  IANA Considerations

   This memo includes no request to IANA.  This section may be removed
   by the RFC Editor prior to publication.

5.  Security Considerations

   This document provides an XML schema for facilitating the management
   of reverse DNS delegations in the IN-ADDR.ARPA and IP6.APRA zones.
   The schema itself contains no authentication data and all other
   information contained is considered public data as it is either
   published in DNS, or propagated to other public information sources
   like WHOIS.

   The system which implements this XML schema requires HTTPS to be used
   and also uses known server and client X.509 certificates for
   authentication to protect against message modification, message
   insertion/deletion, man-in-the-middle, and replay attacks.
   Authorisation for which delegations the X.509 certificate
   authentication sessions can affect are out of scope of this document,
   along with any denial of service type attack vectors.

6.  Acknowledgements

   An XML schema was initially provided by APNIC, however necessity
   required a branch and as such a new namespace and schema has been
   created.  Recognition goes to APNIC for prior efforts in this area.

   The author acknowledges feedback from a collective made up of various
   RIR technical folk, however heartfelt thanks goes to Anand Buddhdev
   of the RIPE-NCC and Robert Loomans of APNIC for being both alpha and
   beta testers and providing valuable feedback.





Manderson              Expires September 20, 2013               [Page 5]


Internet-Draft             Abbreviated Title                  March 2013


7.  References

7.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC3152]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
              August 2001.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, March 2005.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

7.2.  Informative References

   [RELAXNG]  The Organization for the Advancement of Structured
              Information Standards [OASIS], "RELAX NG Compact
              Specification", 2002, <https://www.oasis-open.org/
              committees/relax-ng/compact-20021121.html>.

   [REST]     Fielding, R.T., "Architectural Styles and the Design of
              Network-based Software Architectures", 2000, <http://
              www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>.









Manderson              Expires September 20, 2013               [Page 6]


Internet-Draft             Abbreviated Title                  March 2013


Appendix A.  Schema Definition for rDNS updates

   The following Schema, used for PUT, GET, and DELETE operations, is an
   XML document using the RelaxNG Compact [RELAXNG] specification.

     default namespace = "http://download.research.icann.org/rdns/1.1"

     # A document may either be a single zone (update) or
     # a collection of zones (view)
     start = zone | zonelist | zonereflist

     # A list of zone names for view only.
     zonereflist = element zonereflist {
       attribute version {
         xsd:decimal { minInclusive="1.1" fractionDigits="1" }
       },
       zoneref*
     }

     # A bulk list of zones for view only.
     zonelist = element zonelist {
       attribute version {
         xsd:decimal { minInclusive="1.1" fractionDigits="1" }
       },
       zone*
     }

     # A zone reference (accepted by REST engine for query)
     zoneref = element zoneref {
       attribute name { text },
       attribute href { xsd:anyURI }
     }

     # A single zone record
     zone = element zone {
       # The zone record's name, eg 10.in-addr.arpa
       attribute name { text },
       # The customer, optional, it is derived from known state.
       attribute cust { text }?,
       # The canonical URL for this zone record (optional)
       attribute href { xsd:anyURI }?,
       # The address IP version for the zone record (optional)
       attribute ipversion { "ipv4" | "ipv6" }?,
       # The administrative state of the zone (optional)
       attribute state { "active" | "pending" | "error" }?,
       # The last modified timestamp in UTC (optional)
       attribute modified  { xsd:dateTime }?,
       # The schema version (optional)



Manderson              Expires September 20, 2013               [Page 7]


Internet-Draft             Abbreviated Title                  March 2013


       attribute version {
         xsd:decimal { minInclusive="1.1" fractionDigits="1" }
       }?,
       # A zone NS RRset MUST have at least two NS records
       nserver,
       nserver+,
       # It MAY contain some DS records
       ds*
     }

     # DNS-SEC records
     ds = element ds {
       # rdata MUST contain
       #  <Keytag> | <Algorithm> | <Digest type> | <Digest>
       # as per RFC4034
       #
       element rdata { text }
     }


     # A single name server
     nserver = element nserver {
       # An nserver entry MUST contain a DNS FQDN
       # for a NS RR (RFC 1035)
       element fqdn { text }
     }



Appendix B.  Schema Definition for rDNS Queue Entries

   The XML schema definition below, in RelaxNG Compact [RELAXNG] form is
   used for queue interaction operations.

     default namespace = "http://download.research.icann.org/rq/1.0"

     # A document MAY either be a single queue entry
     #  or a collection of queued entries
     start = queue | queuelist

     # A list of zone names for view only.
     queuelist = element queuelist {
       attribute version {
         xsd:decimal { minInclusive="1.0" fractionDigits="0" }
       },
       queue*
     }




Manderson              Expires September 20, 2013               [Page 8]


Internet-Draft             Abbreviated Title                  March 2013


     # A single queued zone record
     queue = element queue {
       # The zone record's name, eg 10.in-addr.arpa
       attribute name { text },
       # The customer, optional, derived from known state.
       attribute cust { text }?,
       # The canonical URL for this queue record (optional)
       attribute href { xsd:anyURI }?,
       # The acknowlgement URL for this queue record (optional)
       attribute ack { xsd:anyURI }?,
       # The address IP version for the zone record (optional)
       attribute ipversion { "ipv4" | "ipv6" }?,
       # The state of the zone (optional, and for a queue
       # SHOULD always be pending)
       attribute state { "pending" }?,
       # The submitted  timestamp (optional)
       attribute submitted  { xsd:dateTime }?,
       # The HTTP method used to update
       attribute method { "PUT" | "DELETE" },
       # The schema version (1.0) (optional)
       attribute version {
         xsd:decimal { minInclusive="1.0" fractionDigits="1" }
       }?,
       # A zone NS RRset must have at least two NS records
       nserver,
       nserver+,
       # It MAY contain some DS records
       ds*
     }

     # DNS-SEC records
     ds = element ds {
       # rdata MUST contain  Flags | Protocol | Algorithm | Public Key
       # as per RFC4034
       #
       element rdata { text }
     }

     # A single name server
     nserver = element nserver {
       # An nserver entry MUST contain a DNS FQDN
       # for a NS RR (RFC 1035)
       element fqdn { text }
     }







Manderson              Expires September 20, 2013               [Page 9]


Internet-Draft             Abbreviated Title                  March 2013


Author's Address

   Terry Manderson
   ICANN

   Email: terry.manderson@icann.org












































Manderson              Expires September 20, 2013              [Page 10]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/