[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                      J. Hildebrand
Internet-Draft                                             Cisco Systems
Intended status: Informational                                P. Hoffman
Expires: September 22, 2016                                        ICANN
                                                          March 21, 2016


                    DNS Editing Through HTTPS (DETH)
                        draft-hildebrand-deth-00

Abstract

   There is a strong desire in many communities for service operators to
   be able to dynamically update DNS records in an easy-to-deploy,
   standardized method.  For example, operating SIP requires DNS records
   to be added and updated as the SIP service starts and is moved among
   different servers.  This document describes an HTTPS-based mechanism
   for service operators who are authorized by their DNS administrator
   to add, change, and delete DNS records.

Status of This Memo

   This Internet-Draft is submitted 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 22, 2016.

Copyright Notice

   Copyright (c) 2016 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.  Code Components extracted from this document must



Hildebrand & Hoffman   Expires September 22, 2016               [Page 1]


Internet-Draft                     I-D                        March 2016


   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.

1.  Introduction

   This document describes a standardized mechanism called DNS Editing
   Through HTTPS (DETH) for developer-friendly dynamic DNS updates over
   HTTPS [RFC7230].  Such a mechanism allows a DNS administrator to
   authorize particular users to update the records in their zones
   without any manual intervention on the part of the DNS administrator.

   All transactions described here are authorized.  Two types of
   authorization are specified: authenticated by HTTP Digest [RFC7235]
   and OAUTH [RFC6749].  The DNS administrator can create policies to
   allow different users different capabilities for updating zones; such
   policies are outside the scope of this document.

   A client determines the DETH server for a zone using a DNS lookup.
   It then sends HTTPS queries to that server to get information about
   what the client can change, as well as requests for changes.

   The DETH protocol is meant for users who do not currently have a way
   to update a zone using the DNS protocol itself.  Although there
   already is a protocol for dynamic update of DNS records, [RFC3007],
   it is rarely used in practice for more anything more complicated than
   inserting a single A or AAAA record.  In many scenarios, using DETH
   is a simpler way to allow users to update a zone than provisioning
   DNS dynamic update.

   Some large DNS operators have implemented their own non-standard
   mechanisms for allowing users to update their DNS records, often
   using HTTP.  This indicates that HTTP-based update is desired in the
   industry, and a standardized mechanism could be valuable in many
   environments.

1.1.  Goals of this Protocol

   o  Authorized additions of a new record to a zone

   o  Authorized changes to the RDATA and TTL of a record in a zone

   o  Authorized deletions of a record from a zone

   o  Discovery of a URI used for editing a zone, such that the client
      doing the editing can tell that the server they are contacting is
      authorized for the record being edited




Hildebrand & Hoffman   Expires September 22, 2016               [Page 2]


Internet-Draft                     I-D                        March 2016


   o  Discovery of what actions can be taken by an authorized user

   o  Responses can give useful information about why a request was
      rejected

   o  Ease of writing an implementation for a wide variety of languages
      and platforms is of paramount importance

1.2.  Non-Goals for this Protocol

   o  Updating the contents of any type of configuration other than DNS
      zones

   o  Managing DNS servers for anything other than the contents of zones
      for which they are authoritative, such as causing them to reload a
      zone after update or to clear cache entries

   o  Pluggable authorization modules

   o  Editing records in DNS Classes other than IN

1.3.  Possible Deployment Architectures

   There are many ways that the DETH protocol could be deployed.  This
   section gives some sample architectures.

   Native:  An authoritative DNS server system also speaks DETH and uses
      the results of updates directly in the zones it serves.  The DETH
      protocol could be built into DNS server software.

   Bridge:  A DETH server is deployed in front of the management
      interface for an authoritative DNS server.  The DETH server
      receives authorized updates from users, and uses DNS dynamic
      update [RFC3007] to update the zones on the authoritative DNS
      server.

   Data store front end:  A DETH server receives authorized updates from
      users, modifies a DNS data store, tells DNS server to reload.

1.4.  Actors

   The following actors are used in this document:

   DETH Server:  A server that speaks HTTPS, and provides an
      implementation of the server side of the DETH API, rooted at a
      discoverable HTTPS URI.  The DETH Server is authorized by the
      associated DNS infrastructure for a set of domains to make policy




Hildebrand & Hoffman   Expires September 22, 2016               [Page 3]


Internet-Draft                     I-D                        March 2016


      decisions about DNS edits.  The DETH server is responsible for
      enforcing authorization in conformance with this policy.

   DETH Client:  A piece of authorized software that would like to make
      changes to one or more DNS records.  In order to make man-in-the-
      middle attacks more difficult, the DETH client is responsible for
      ensuring that it is communicating with the correct DETH Server for
      the domain it wants to modify.

   Parent Domain:  The thing that you want to add records to.  (Paul:
      need DNS terminology here)

1.5.  Terminology

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

2.  Protocol

   The DETH protocol uses a simple client-server interactions.  The
   client determines the location of the server either through a DNS
   lookup or local configuration.  After that, all protocol interactions
   are over HTTPS.

   In the following sections, the client wants to edit records in the
   "example.com" zone.  The HTTPS examples use the "dig" program [dig]
   and "curl" program [curl] to get URLs, but clients will most likely
   use internal calls to get this information.

2.1.  Determining the DETH Server for a Zone

   A client uses a DNS query with the TXT RTYPE using the name of the
   parent zone, prefixed with the "_deth" label, for the QNAME.  The
   answer is the base URI for the HTTPS server running the DETH
   protocol.  This URI returned MUST use the HTTPS scheme.

   For example, to find the DETH server for the "example.com" zone, the
   query would have a QNAME of "_deth.example.com" and a QTYPE of TXT.
   A command-line equivalent would be:

   $ dig +short TXT _deth.example.com
   https://example.com/deth/v1/

   If no TXT record is found for a name, the client can assume that the
   parent does not implement the DETH protocol.  However, explicit
   configuration might still allow a client to find a DETH server.



Hildebrand & Hoffman   Expires September 22, 2016               [Page 4]


Internet-Draft                     I-D                        March 2016


   If the DETH server is found using the DNS lookup described here, the
   client MUST perform the following checks before using the result:

   o  Ensure that the string is a valid HTTPS URI (see [RFC7230],
      section 2.7.2).

   o  Ensure that the TXT record has a valid DNSSEC [RFC4035] signature
      OR that the host portion of the URI matches the parent domain,
      with no port specified.

   o  Ensure that the certificate offered when the URI is accessed using
      HTTPS matches the domain name using the rules in [RFC6125].

   o  Ensure that the DETH server's certificate is signed by a trusted
      Certificate Authority.

2.2.  Determining Authorized Edits

   The DETH client does an HTTPS GET request to the DETH server go get a
   list of edits that the client is authorized to perform.  For example:

   curl -X GET https://example.com/deth/v1/

   Might return:

   {
     "A": {
       "URI": "https://example.com/deth/v1/A/",
       "methods": ["PUT", "DELETE"]
     },
     "AAAA": {
       "URI": "https://example.com/deth/v1/AAAA/",
       "methods": ["PUT"]
     },
     "SRV": {
       "URI": "https://example.com/deth/v1/example.com/SRV/",
       "methods": ["PUT", "DELETE"]
     },
     "TYPE255": {
       "URI": "https://example.com/deth/v1/example.com/TYPE255/",
       "methods": ["PUT", "DELETE"]
     }
   }

                        Figure 1: Directory Example

   The valid keys for the top level JSON object are a popular subset of
   [IANA-rrtypes], plus a mechanism for supporting all other RDATA.  The



Hildebrand & Hoffman   Expires September 22, 2016               [Page 5]


Internet-Draft                     I-D                        March 2016


   response is formally described in CDDL
   [I-D.greevenbosch-appsawg-cbor-cddl] as:

   directory = {
     * rrtype => edit_details
   }

   rrtype =  "A" / "AAAA" / "CNAME" / "NS" / "PTR" / "MX" /
             "TXT" / "SPF" / "SRV" /
             rrtype_num

   rrtype_num = tstr .regexp "TYPE\\d+"

   edit_details = {
     URI: tstr,
     methods: [+ method_name]
   }

   method_name = "GET" / "PUT" / "DELETE"

                       Figure 2: DETH Directory CDDL

3.  Authentication and Authorization

   All requests are authenticated either by by HTTP Digest [RFC7235] and
   OAUTH [RFC6749].  Parameters supported for either of these mechanisms
   are determined by the DETH Server.  This document makes no
   recommendations for best authentication practices beyond what have
   already been described in other documents published by the IETF.

   After the DETH server authenticates a user, it determines which
   actions that user is authorized to make.  If using HTTP Digest, the
   authorization policy probably comes from a database.  If using OAUTH,
   that determination might be part of the OAUTH interaction.

4.  Forming Request URIs

   When a client wants to edit a particular DNS record, it appends the
   full name of the record to the URI for the RTYPE found in the
   directory JSON (see Section 2.2).  For example, if the directory JSON
   was that specified in Figure 1, and the client wanted to edit a
   "AAAA" record for "foo.example.com", the URL would be

   https://example.com/deth/v1/AAAA/foo.example.com

   TODO: specify more rules about URL combination to avoid attacks.





Hildebrand & Hoffman   Expires September 22, 2016               [Page 6]


Internet-Draft                     I-D                        March 2016


5.  Record Editing

   This section describes the semantics of requests to edit DNS records.
   The specification covers how to specify which edits are desired, but
   does not yet cover how the DNS server deals with updating SOA
   records, nor how any DNSSEC records would need to be updated.

5.1.  Encoding in JSON

   The JSON sent to the URIs formed according to the rules in Section 4
   looks like:

   {
     "RTYPE": "AAAA",
     "v6address": "::1",
     "TTL": 3600,
     "comment": "This is my home"
   }

                         Figure 3: Update Example

   All of the potential updates are specified by the following CDDL:

   update = A_update / AAAA_update / CNAME_update / NS_update /
            PTR_update / MX_update / SRV_update / TXT_update /
            rrtype_update

   A_update = {
     RTYPE: "A",
     v4address: tstr,
     common
   }

   AAAA_update = {
     RTYPE: "AAAA",
     v6address: tstr,
     common
   }

   CNAME_update = {
     RTYPE: "CNAME",
     cname: tstr,
     common
   }

   NS_update = {
     RTYPE: "NS",
     nsdname: tstr,



Hildebrand & Hoffman   Expires September 22, 2016               [Page 7]


Internet-Draft                     I-D                        March 2016


     common
   }

   PTR_update = {
     RTYPE: "PTR",
     ptrdname: tstr,
     common
   }

   MX_update = {
     RTYPE: "MX",
     preference: uint,
     exchange: tstr,
     common
   }

   SRV_update = {
     RTYPE: "SRV",
     priority: uint,
     weight: uint,
     target: tstr,
     common
   }

   TXT_update = {
     RTYPE: "TXT",
     data: tstr,
     common
   }

   rrtype_update = {
     RTYPE: tstr .regexp "TYPE\\d+",
     RDATA: tstr,
     common
   }

   common = (
     ? TTL: uint,
     ? comment: tstr
   )

                        Figure 4: DETH Update CDDL

   For updates that match the rrtype_update syntax, the rules for
   encoding RDATA from [RFC3597] are used.






Hildebrand & Hoffman   Expires September 22, 2016               [Page 8]


Internet-Draft                     I-D                        March 2016


5.2.  Getting Records

   Sending "GET" requests to the URIs formed in Section 4 is supported
   in order to allow clients more easily edit records.

   TODO: The response types for "GET" responses will be specified in a
   future version of this document.

5.3.  Creating Records

   A new record is created by sending the desired JSON document that
   matches Figure 4 to the URI formed by the rules in Section 4, using
   the "POST" HTTP verb.

   If a TTL is not sent with the request, a system default will be used.
   The response from this "PUT" will be the JSON form of the record, as
   inserted.  This response MUST have the TTL included.

5.4.  Deleting Records

   A new record is created by sending the desired JSON document that
   matches Figure 4 to the URI formed by the rules in Section 4, using
   the "DELETE" HTTP verb.

   Currently, this will delete all matching records.  TODO: Once
   matching rules have been defined in a later version of this document,
   individual record deleting may be allowed.

5.5.  Updating Records

   Updating records in place is not yet specified.  A prerequisite for
   this feature will be a way to match existing records, so that only
   one of several existing records with the same name and RTYPE will be
   modified.

   For now, a combination of request as specified in Section 5.4 and
   Section 5.3 may be used.

   TODO: Add matching feature or change this section.

5.6.  Return Codes and Errors

   Errors use the approach from [I-D.ietf-appsawg-http-problem].

   TODO: Error information will be specified in a future revision of
   this document.





Hildebrand & Hoffman   Expires September 22, 2016               [Page 9]


Internet-Draft                     I-D                        March 2016


6.  IANA Considerations

   No new IANA registries are expected.

7.  Security Considerations

   Careful authorization of all edits is very important.  All changes
   that are allowed by this specification MUST be authorized using the
   model described.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
              (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
              2003, <http://www.rfc-editor.org/info/rfc3597>.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
              <http://www.rfc-editor.org/info/rfc4035>.

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
              2011, <http://www.rfc-editor.org/info/rfc6125>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <http://www.rfc-editor.org/info/rfc6749>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

   [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Authentication", RFC 7235,
              DOI 10.17487/RFC7235, June 2014,
              <http://www.rfc-editor.org/info/rfc7235>.



Hildebrand & Hoffman   Expires September 22, 2016              [Page 10]


Internet-Draft                     I-D                        March 2016


8.2.  Informative References

   [I-D.greevenbosch-appsawg-cbor-cddl]
              Vigano, C. and H. Birkholz, "CBOR data definition language
              (CDDL): a notational convention to express CBOR data
              structures", draft-greevenbosch-appsawg-cbor-cddl-08 (work
              in progress), March 2016.

   [I-D.ietf-appsawg-http-problem]
              mnot, m. and E. Wilde, "Problem Details for HTTP APIs",
              draft-ietf-appsawg-http-problem-03 (work in progress),
              January 2016.

   [draft-jennings-app-dns-update]
              Jennings, C., Daly, T., and J. Hitchcock, "HTTP API for
              Updating DNS Records", 2009, <https://tools.ietf.org/html/
              draft-jennings-app-dns-update>.

   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
              <http://www.rfc-editor.org/info/rfc3007>.

   [dig]      ISC, "dig utility", 2016, <https://www.isc.org/downloads/
              bind/>.

   [curl]     Stenberg, D., "curl program", 2016,
              <https://curl.haxx.se/>.

   [IANA-rrtypes]
              IANA, "Resource Record TYPEs", February 2016,
              <http://www.iana.org/assignments/dns-parameters/
              dns-parameters.xhtml#dns-parameters-4>.

Appendix A.  Acknowledgements

   This document borrows heavily from many earlier protocols.  Some of
   the text of this document is liberally lifted from the long-expired
   [draft-jennings-app-dns-update].

Authors' Addresses

   Joe Hildebrand
   Cisco Systems

   Email: jhildebr@cisco.com






Hildebrand & Hoffman   Expires September 22, 2016              [Page 11]


Internet-Draft                     I-D                        March 2016


   Paul Hoffman
   ICANN

   Email: paul.hoffman@icann.org















































Hildebrand & Hoffman   Expires September 22, 2016              [Page 12]


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