Skip to main content

Domain Connect API - Communications between DNS Provider and Services
draft-carney-regext-domainconnect-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Arnold Blinn , Roger Carney
Last updated 2016-10-20
Replaced by draft-kowalik-regext-domainconnect
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-carney-regext-domainconnect-01
Registration Protocols Extensions                               A. Blinn
Internet-Draft                                                 R. Carney
Intended status: Informational                              GoDaddy Inc.
Expires: April 23, 2017                                 October 20, 2016

 Domain Connect API - Communications between DNS Provider and Services
                  draft-carney-regext-domainconnect-01

Abstract

   This document provides information related to the Domain Connect API
   that was built to support communications between DNS Providers and
   Service Providers (hosting, social, email, hardware, etc.).

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 April 23, 2017.

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
   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.

Blinn & Carney           Expires April 23, 2017                 [Page 1]
Internet-Draft               Domain Connect                 October 2016

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  The API . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  Web-Based Authentication, Authorization & Template Action
           Flow  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  OAuth Based Authentication and Authorization Flow . . . .   5
     4.3.  DNS Provider Initiated Flows  . . . . . . . . . . . . . .   6
     4.4.  DNS Provider Discovery  . . . . . . . . . . . . . . . . .   6
     4.5.  Domain Connect Endpoints  . . . . . . . . . . . . . . . .   7
       4.5.1.  Web Based Flow  . . . . . . . . . . . . . . . . . . .   8
       4.5.2.  OAuth Flow  . . . . . . . . . . . . . . . . . . . . .   9
         4.5.2.1.  Getting an Authorization Token  . . . . . . . . .  10
         4.5.2.2.  Requesting an Access Token  . . . . . . . . . . .  11
         4.5.2.3.  Making Requests with Access Tokens  . . . . . . .  12
         4.5.2.4.  Apply Template to Domain  . . . . . . . . . . . .  12
         4.5.2.5.  Revert Template . . . . . . . . . . . . . . . . .  13
         4.5.2.6.  Revoke Access . . . . . . . . . . . . . . . . . .  14
     4.6.  Domain Connect Objects and Templates  . . . . . . . . . .  14
     4.7.  Implementation Notes  . . . . . . . . . . . . . . . . . .  15
     4.8.  Operational and Implementation Considerations . . . . . .  19
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  20
   7.  Change History  . . . . . . . . . . . . . . . . . . . . . . .  20
     7.1.  Change from 00 to 01  . . . . . . . . . . . . . . . . . .  20
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

   Configuring a service at a Service Provider to work with a domain is
   a complex task and is difficult for users.

   Typically a customer will try to configure their service by entering
   their domain name with the Service Provider.  The Service Provider
   then uses a number of techniques to discover the DNS Provider.  This
   might include DNS queries to determine the registrar and/or the
   nameserver providing DNS.

   Once the Service Provider discovers the DNS Provider, they typically
   give the customer instructions for proper configuration of DNS.  This
   might include help text, screen shots, or even links to the
   appropriate tools.

   This often presents a number of technologies or processes to the user
   that they may not understand.  DNS record types, TTLs, Hostnames,

Blinn & Carney           Expires April 23, 2017                 [Page 2]
Internet-Draft               Domain Connect                 October 2016

   etc. are all confusing to many users.  Instructions authored by the
   Service Provider may also be out of date, further confusing the
   issue.

   The goal of the protocol presented in this RFC is to create a system
   where Service Providers can easily enable their applications/services
   to work with the domain names of their customers.  This includes both
   discovery of the DNS Provider and subsequent modification of DNS.

2.  Terminology

   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].

   XML is case sensitive.  Unless stated otherwise, XML specifications
   and examples provided in this document MUST be interpreted in the
   character case presented in order to develop a conforming
   implementation.

3.  Definitions

   The following definitions are used in this document:

   o  Service Providers - refers to entities that provide products and
      services attached to domain names.  Examples include web hosting
      providers (such as Wix or SquareSpace), email Service Providers
      (such as Microsoft or Google) and potentially even hardware
      manufacturers with DNS-enabled devices including home routers or
      automation controls (such as Linksys, Nest, and Philips).
   o  DNS Providers - refers to entities that provide DNS services such
      as registrars (e.g.  GoDaddy, eNom or Tucows) or standalone DNS
      services (e.g.  CloudFlare).
   o  Customer/User - refers to the end-user of these services.
   o  Templates/Service Templates - refers to a file that describes a
      set of changes to DNS and domain functionality to enable a
      specific service.

4.  The API

   The system will be implemented using simple web based interactions
   and standard authentication protocols, allowing for the creation and
   modification of DNS settings through the application of templates
   instead of direct manipulation of individual DNS records.

   The core of this proposal is based on templates.  Templates describe
   a service owned by a Service Provider, and contain all of the
   information necessary to describe the changes to the domain and to

Blinn & Carney           Expires April 23, 2017                 [Page 3]
Internet-Draft               Domain Connect                 October 2016

   DNS required to enable and operate/maintain a service.  These changes
   are in the form of records/commands which map to records in DNS or
   other domain behavior (e.g. redirects).

   The individual records/commands may be identified by a group
   identifier.  This allows for the application of templates in
   different stages.  For example, an email provider might first set a
   TXT record to verify the domain, and later set an MX record to
   configure email.  While done separately, both changes are
   fundamentally part of the same service.

   Templates can also contain variable portions, as often values of data
   in the template change based on the rules of the Service Provider
   (e.g.  the IP address of a service).

   Configuration and onboarding of templates between the DNS Provider
   and the Service Provider is initially seen as a manual process.  The
   template is defined by the Service Provider and given to the DNS
   Provider.  Future versions of this specification may allow for an
   independent repository of templates.

   By basing the protocol on templates instead of DNS Records, several
   advantages are achieved.  The DNS Provider has very explicit
   knowledge and control on the settings being changed to enable a
   service.  The system is also more secure as templates are tightly
   controlled and contained.

   All parties benefit by having an open standard.  With more DNS
   Providers supporting the standard, more Service Providers are likely
   to adopt and vice versa.

   The value to customers is simple, Domain Connect makes configuration
   of services much easier.  Instead of editing individual DNS records,
   a customer simply approves the application of a template to their
   domain.

   To attach a domain name to a service provided by a Service Provider,
   the customer would first enter their domain name.

   Instead of relying on examination of the nameserver and mapping these
   to DNS Providers, DNS Provider discovery would be handled through
   simple records in DNS and an API.  The Service Provider would query
   for a specific record in the zone to determine a REST endpoint, call
   an API, and a Domain Connect compliant DNS Provider would return
   information about that domain at the DNS Provider.

Blinn & Carney           Expires April 23, 2017                 [Page 4]
Internet-Draft               Domain Connect                 October 2016

   For the application of the changes to DNS, there are two main use
   cases.  The first is a synchronous web flow.  The second is the API
   when the OAuth flow is used.

4.1.  Web-Based Authentication, Authorization & Template Action Flow

   This flow is tailored for the Service Provider that requires a one-
   time synchronous change to DNS.

   The user would first enter their domain name at the Service Provider.

   After the Service Provider determines the DNS Provider, the Service
   Provider would display a link to the user indicating that they can
   "Connect their Domain" to the service.

   After clicking the link, the user is directed to a browser window on
   the DNS Provider's site.  This could be in place, another tab, or in
   a new browser window.  This link would indicate the domain name being
   updated, the service being enabled, and any additional parameters
   needed to configure the service.

   The user would be asked to authenticate at the DNS Provider site.

   After authenticating at the DNS Provider, the DNS Provider would
   verify the domain name, provided by the user, is owned by the user.
   The DNS Provider would also verify other parameters passed in are
   valid and would prompt the user to give consent for making the change
   to DNS.

   Assuming the user grants this consent, the DNS changes would be
   applied.  Upon successful application of the DNS changes, an optional
   callback URL would be called at the Service Provider indicating
   success.

4.2.  OAuth Based Authentication and Authorization Flow

   The OAuth flow is tailored for the Service Provider that wishes to
   make changes to DNS asynchronously to the user interaction, or may
   wish to make multiple or additional changes to DNS over time.

   The OAuth based authentication and authorization flow begins
   similarly to the web based synchronous flow.

   However, instead of applying the DNS changes on user confirmation,
   OAuth access is granted to the Service Provider.  An OAuth token is
   generated and handed back to the Service Provider.

Blinn & Carney           Expires April 23, 2017                 [Page 5]
Internet-Draft               Domain Connect                 October 2016

   The permission granted in the OAuth token is a right for the Service
   Provider to apply changes based on the template to the specific
   domain owned by a specific user.

   The Service Provider would call an API that applies this template to
   the domain, including any necessary parameters along with the access
   token(s).  As in all OAuth flows, access can be revoked by the user
   at any time.  This would be done on the DNS Providers user
   experience.

   If the OAuth flow is used, once a Service Provider has an OAuth token
   the Domain Connect API becomes available for use.  The Domain Connect
   API is a simple REST service.

   This REST service allows the application or removal of the changes in
   the template on a domain name.  The domain name, user, and template
   must be authorized through the OAuth token and corresponding access
   token.

   Additional parameters named keys are expected to be passed as name/
   value pairs on the query string of each API call.

4.3.  DNS Provider Initiated Flows

   It may be desired to expose different services available from the DNS
   Provider, mainly to expose interesting services that the user could
   attach to their domain.  An example would be suggesting to a user
   that they might want to connect their domain to a partner Service
   Provider.

   If the template for the service is static, it is sometimes possible
   to simply apply the template, and be done.

   However, often the template has some dynamic elements.  For this
   scenario, the DNS Provider need simply call a URL at the Service
   Provider.  The Service Provider can then sign the user in, collect
   any necessary information, and call the normal web-based flows
   described above.

4.4.  DNS Provider Discovery

   In order to facilitate discovery of the DNS Provider given a domain
   name, a domain will contain a record in DNS.

   This record will be a simple TXT record containing a URL used as a
   prefix for calling a discovery API.  This record will be named
   domainconnect.

Blinn & Carney           Expires April 23, 2017                 [Page 6]
Internet-Draft               Domain Connect                 October 2016

   An example of this record would contain:

   https://domainconnect.godaddy.com

   As a practical matter of implementation, the DNS Provider need not
   contain a copy of this data in each and every zone.  Instead, the DNS
   Provider needs simply to respond to the DNS query for the
   domainconnect TXT record with the appropriate data.  How this is
   implemented is up to the DNS Provider.

   Once the URL prefix is discovered, it can be used by the Service
   Provider to determine the additional settings for using Domain
   Connect on this domain at the DNS Provider.  This is done by calling
   a REST API.

      GET
      v2/{domain}/settings

   This will return a JSON structure containing the settings to use for
   Domain Connect on the domain name (passed in on the path) at the DNS
   Provider.  This JSON structure will contain the following fields:

   o  providerName: The name of the DNS Provider suitable for display on
      the Service Provider UX.
   o  urlSyncUX: The URL Prefix for linking to the UX elements of Domain
      Connect for the synchronous flow at the DNS Provider.
   o  urlAsyncUX: The URL Prefix for linking to the UX elements of
      Domain Connect for the asynchronous flow at the DNS Provider
   o  urlAPI: This is the URL Prefix for the REST API for the
      asynchronous OAuth API.

   As an example, the JSON returned by this call might contain.

      {
      "providerName": "GoDaddy",
      "urlSyncUX": "https://domainconnect.godaddy.com",
      "urlAsyncUX": "https://domainconnect.godaddy.com",
      "urlAPI" : "https://api.domainconnect.godaddy.com"
      }

4.5.  Domain Connect Endpoints

   Domain Connect contains endpoints in the form of URLs.

   The first set of endpoints are for the UX that the Service Provider
   links to.

Blinn & Carney           Expires April 23, 2017                 [Page 7]
Internet-Draft               Domain Connect                 October 2016

   These are for the UX which includes the web-based flow where the user
   clicks on the link, and the OAuth flow where the user clicks on the
   link for consent.

   The second set of endpoints are for the API that is called as part of
   the asynchronous OAuth flow via REST.

   All endpoints begin with a root URL for the DNS Provider such as
   https://connect.dnsprovider.com/ and may also include any prefix at
   the discretion of the DNS Provider, for example,
   https://connect.dnsprovider.com/api/

   The root URLs for the UX endpoints and the API endpoints are returned
   in the JSON payload during DNS Provider discovery.

4.5.1.  Web Based Flow

      GET
      v2/domainTemplates/providers/{providerDomain}/services/{serviceNam
      e}/apply?[properties]

   This is the URL used to apply a template to a domain.  This URL is
   embedded on the Service Provider's site to start the Domain Connect
   protocol.

   Parameters/properties passed to this URL include:

   o  domain: This parameter contains the domain name being configured.
   o  name/value pairs: Any variable fields consumed by this template.
      The name portion of this API call corresponds to the variable(s)
      specified in the template and the value corresponds to the value
      that should be used when applying the template.
   o  requestId: This OPTIONAL parameter may contain a value that will
      be passed back to the calling Service Provider via the template's
      callback URL.  A Service Provider may use this value to identify a
      specific call or for any other purpose.
   o  groupId: This OPTIONAL parameter specifies the group of changes
      from the template to apply.  If no group is specified, all changes
      are applied.

   An example query string is below:

      GET
      https://webconnect.dnsprovider.com/v2/domainTemplates/providers/co
      olprovider.com/services/hosting/
      apply?www=192.168.42.42&m=192.168.42.43&domain=example.com

Blinn & Carney           Expires April 23, 2017                 [Page 8]
Internet-Draft               Domain Connect                 October 2016

   This call indicates that the Service Provider wishes to connect the
   domain example.com to the service using the template identified by
   the composite key of the provider (coolprovider.com) and the service
   owned by them (hosting).  In this example, there are two variables in
   this template, "www" and "m" which both require values (in this case
   each requires an IP address).  These variables are passed as name/
   value pairs.

   As part of the Domain Connect flow, a callback URL will be invoked if
   provided.

   It should also be noted that successfully getting a callback URL
   invoked in a flow such as this isn't 100% reliable.  Requests often
   fail, and users may close their web browser before such a callback is
   invoked.

   This callback URL is largely for tracking and convenience.  As such
   the lack of reliability is likely not a factor.  A Service Provider
   who wishes to continue any process with certainty will simply check
   the DNS for any applied changes as a trigger for further action.

   The URL called is specified as part of the onboarding process with
   the service.  This URL would allow for the substitution of three
   values:

   o  domain: The domain name configured with domain connect.
   o  requestId: The passed in requestId in the initial call.
   o  status: The status or results of the operation (SUCCESS, CANCELED,
      FAILED, ERROR).

   The format of this URL provided by the Service Provider to the DNS
   Provider would be similar to:

   http://example.com/
   connectresults?domain=%domain%&request=%requestId%&status=%status%

4.5.2.  OAuth Flow

   Using the OAuth flow is a more advanced use case, needed by Service
   Providers that have more complex configurations that may require
   multiple steps and/or are asynchronous from the user's interaction.

   Details of an OAuth implementation are beyond the scope of this
   specification.  Instead, an overview of how OAuth fits with Domain
   Connect is given here.

Blinn & Carney           Expires April 23, 2017                 [Page 9]
Internet-Draft               Domain Connect                 October 2016

   Service providers wishing to use the OAuth flow must register as an
   OAuth client with the DNS Provider.  This is envisioned as a manual
   process.

   To register, the Service Provider would provide (in addition to their
   template) one or more callback URLs that specify where the customer
   will be redirected after the provider authorization.  In return, the
   DNS Provider will give the Service Provider a client id and secret
   which will be used when requesting tokens as part of the OAuth
   process flow.

4.5.2.1.  Getting an Authorization Token

      GET
      v2/domainTemplates/
      providers/{providerDomain}/services/{serviceName}

   To initiate the OAuth flow the Service Provider would link to the DNS
   Provider to gain consent.  This endpoint is similar to the
   synchronous flow described above, and will handle authenticating the
   user and asking for the user's permission to allow the Service
   Provider to make the specified changes to the domain.

   Upon successful authorization, the DNS Provider will direct the end
   user's browser to the redirect URI provided in the request, appending
   the authorization code as a query parameter of "code".

   Upon error, the DNS Provider will direct the end user's browser to
   the redirect URI provided in the request, appending the error code as
   a query parameter "error".

   The following describes the values to be included in the query string
   parameters for this request.

   o  domain: This parameter contains the domain name being configured.
   o  client_id: This is the client id that was provided by the DNS
      Provider, to the Service Provider during registration.
   o  redirect_uri: The location to direct the client's browser to upon
      successful authorization, or upon error.
   o  scope: This is the name of the resource that the Service Provider
      is requesting access to.
   o  response_type: OPTIONAL.  If included should be the string 'code'
      to indicate an authorization code is being requested.
   o  state: OPTIONAL but recommended.  This is a random, unique string
      passed along to prevent CSRF.  It will be returned as a parameter
      when redirecting to the redirect_url described above.

Blinn & Carney           Expires April 23, 2017                [Page 10]
Internet-Draft               Domain Connect                 October 2016

4.5.2.2.  Requesting an Access Token

      POST /v2/oauth/access_token

   Once authorization has been granted the Service Provider must use the
   Authorization Token provided to request an Access Token.  The OAuth
   specification recommends that the Authorization Token be a short
   lived token, and a reasonable recommended setting is ten minutes.  As
   such this exchange needs to be completed before that time has expired
   or the process will need to be repeated.

   This token exchange is done via a server to server API call from the
   Service Provider to the DNS Provider.

   The Access Token granted will also have a short-lived lifespan, also
   on the order of ten minutes.  To get a new access token, the Refresh
   Token is used.

   The following describes the POST parameters to be included in the
   request.

   o  code: The authorization code that was provided in the previous
      step when the customer accepted the authorization request, or the
      refresh_token for a subsequent access token.
   o  redirect_uri: OPTIONAL.  If included, needs to be the same
      redirect uri provided in the previous step, simple for
      verification.
   o  grant_type: The type of code in the request.  Usually the string
      'authorization_code' or 'refresh_token'.
   o  client_id: This is the client id that was provided by the DNS
      Provider, to the Service Provider during registration.
   o  client_secret: The secret provided to the Service Provider during
      registration.

   Upon successful token exchange, the DNS Provider will return a
   response with 4 properties in the body of the response.

   o  access_token: The access token to be used when making API
      requests.
   o  token_type: Always the string "bearer".
   o  expires_in: The number of seconds until the access_token expires.
   o  refresh_token: The token that can be used to request new access
      tokens when this one has expired.

Blinn & Carney           Expires April 23, 2017                [Page 11]
Internet-Draft               Domain Connect                 October 2016

4.5.2.3.  Making Requests with Access Tokens

   Once the Service Provider has the access token, they can call the DNS
   Provider's API to make change to DNS on behalf of the user.

   All calls to this API pass the access token in the Authorization
   Header of the request to the call to the API.  More details can be
   found in the OAuth specifications, but as an example:

      GET /resource/1 HTTP/1.1
      Host: example.com
      Authorization: Bearer mF_9.B5f-4.1JqM

4.5.2.4.  Apply Template to Domain

      POST
      v2/domainTemplates/
      providers/{providerId}/services/{serviceId}/apply?[properties]

   The primary function of the API is to apply a template to a customer
   domain.

   While the providerId and serviceId are also implied in the
   authorization, these are on the path for consistency with the
   synchronous flows.  If not matching what is in the authorization, an
   error is returned.

   In addition, the call must accept the following parameters:

   o  domain: This contains the domain name being configured.  It must
      match the domain in the authorization token.
   o  name/value pairs: Any variable fields consumed by this template.
      The name portion of this API call corresponds to the variable(s)
      specified in the record and the value corresponds to the value
      that should be used when applying the template as per the
      implementation notes.
   o  groupId: This OPTIONAL parameter specifies the group of changes in
      the template to apply.  If omitted, all changes are applied.

   An example call is below.  In this example, it is contemplated that
   there are two variables in this template, "www" and "m" which both
   require values (in this case each requires an IP address).  These
   variables are passed as name/value pairs.

      POST
      https://connect.dnsprovider.com/v2/domainTemplates/providers/coolp
      rovider.com/services/hosting/
      apply?www=192.168.42.42&m=192.168.42.43

Blinn & Carney           Expires April 23, 2017                [Page 12]
Internet-Draft               Domain Connect                 October 2016

   The API must validate the access token for the Service Provider and
   that the domain belongs to the customer and is represented by the
   token being presented.  With these checks passing, the template may
   be applied to the domain after verifying that doing so would not
   cause an error condition, either because of problems with required
   variables or the current state of the domain itself (for example,
   already having a conflicting template applied).

   Results of this call can include information indicating success, or
   an error.  Errors will be 400 status codes, with the following codes
   defined.

   o  Success (204): A response of an http status code of 204 indicates
      that call was successful and the template applied.  Note that any
      200 level code should be considered a success.
   o  Unauthorized (401,403): A response of a 401 indicates that caller
      is not authorized to make this call.  This can be because the
      token was revoked, or other access issues.
   o  Error (404,422): This indicates something wrong with the request
      itself, such as bad parameters.
   o  Failed (409): This indicates that the call was good, and the
      caller authorized, but the change could not be applied due to
      other conditions.  This might be the application of a conflicting
      template or a domain state that prevents updates.

4.5.2.5.  Revert Template

      POST
      v2/domainTemplates/
      providers/{providerId}/services/{serviceId}/revert?domain={domain}

   This API allows the removal of a template from a customer domain
   using an OAuth request.

   The provider and service name in the authorizatoin must match the
   values in the URL.  So must the domain name on the query string.

   This call must validate that the template requested exists and has
   been applied to the domain by the Service Provider or a warning must
   be returned that the call would have no effect.  This call must
   validate that there is a valid authorization token for the domain
   passed in or an error condition must be reported.

   An example query string might look like:

      POST
      https://connect.dnsprovider.com/v2/domainTemplates/providers/coolp
      rovider.com/services/hosting/revert?domain=example.com

Blinn & Carney           Expires April 23, 2017                [Page 13]
Internet-Draft               Domain Connect                 October 2016

   Response codes are identical to above.

4.5.2.6.  Revoke Access

   Like all OAuth flows, the user can revoke the access at any time
   using UX at the DNS Provider site.  So the Service Provider needs to
   be aware that their access to the API may be denied.

4.6.  Domain Connect Objects and Templates

   This description represents the values in the template.  Since
   onboarding of a Service Provider with a DNS Provider is initially a
   manually oriented process, this format is a recommendation.

   There may be a repository of templates in the future.

   A template is defined as a standard JSON data structure containing
   the following data:

   o  providerId: The unique identifier of the Service Provider that
      created this template.  This is used in the URLs to identify the
      Service Provider.  To ensure non-coordinated uniqueness, this
      would be the domain name of the Service Provider.
   o  providerName: The name of the Service Provider.  This will be
      displayed to the user.
   o  templateId: The name or identifier of the template.  This is used
      in URLs to identify the template.
   o  templateName: The friendly name of this service.  This will be
      displayed to the user.
   o  logoUrl: A graphical logo for use in any web-based flow.  This is
      a URL to a graphical logo sufficient for retrieval.
   o  description: A textual description of what this template attempts
      to do.  This is meant to assist integrators, and therefore should
      not be displayed to the user.
   o  launchUrl: OPTIONAL.  A URL suitable for a DNS Provider to call to
      initiate the execution of this template.  This allows the flow to
      begin with the DNS Provider as described above.
   o  returnUrl: OPTIONAL.  The URL to call indicating the status of the
      call.
   o  records: A list of records and/or actions for the template.

   Each template record is an entry that contains a type and several
   optional parameters based on the value.

   For all entries of a record template other than "type" and "groupId",
   the value can contain variables denoted by %<variable name>%. These
   are the values substituted at runtime when writing into DNS.

Blinn & Carney           Expires April 23, 2017                [Page 14]
Internet-Draft               Domain Connect                 October 2016

   It should be noted that as a best practice, the variable should be
   equal to the portion of the values in the template that change as
   little as possible.

   For example, say a Service Provider requires a CNAME of one of three
   values for their users: s01.example.com, s02.example.com, and
   s03.example.com.

   The value in the template could simply contain %servercluster%, and
   the fully qualified string passed in.  Alternatively, the value in
   the template could contain s%var%.example.com.  By placing more fixed
   data into the template, the data is more constrained.  And by using a
   generic name the values in the query string are more obscured.

   Each record will contain the following elements:

   o  type: Describes the type of record in DNS, or the operation
      impacting DNS.  Valid values include: A, AAAA, CNAME, MX, TXT,
      SRV, NS, APEXCNAME, REDIR301, or REDIR302.
   o  groupId: This OPTIONAL parameter identifies the group the record
      belongs to when applying changes.
   o  host: The host for A, AAAA, CNAME, TXT, and MX values.  This is
      the hostname in DNS.
   o  pointsTo: The pointsTo location for A, AAAA, CNAME, MX, and
      APEXCNAME records.
   o  ttl: This is the time-to-live for the record in DNS.  Valid for A,
      AAAA, CNAME, TXT, MX, and SRV records.
   o  data: This is the data for a TXT record in DNS.
   o  priority: This is the priority for an MX or SRV record in DNS.
   o  weight: This is the weight for the SRV record.
   o  port: This is the port for the SRV record.
   o  protocol: This is the protocol for the SRV record.
   o  service: This is the protocol for the SRV record.
   o  target: This is the target url for REDIR301 and REDIR302.

4.7.  Implementation Notes

   This template format is intended for internal use by a DNS Provider
   and there are no codified API endpoints for creation or modification
   of these objects.  API endpoints do not use this object directly.
   Instead, API endpoints reference a template by ID and then provide
   key/value pairs that match any variable values in these record
   objects.

   However, by defining a standard template format it is believed it
   will make it easier for Service Providers to share their provisioning
   across DNS Providers.  Further revisions of this specification may
   include a repository for publishing and consuming these templates.

Blinn & Carney           Expires April 23, 2017                [Page 15]
Internet-Draft               Domain Connect                 October 2016

   Implementers are responsible for data integrity and should use the
   record type field to validate that variable input meets the criteria
   for each different data type.

   Certain record types may not be valid with others (e.g. a redirect
   and an A record), and it is up to the DNS and Service Providers to
   author templates appropriately.  As such, a practical matter may be
   the redirect is valid only by itself.

   Additional record types and/or extensions to the data that can be set
   into the template can be implemented on a per DNS Provider basis.
   For example, if a DNS Provider supports additional record types,
   these can be added to this specification and templates.

   Similarly other providers may not wish to support certain record
   types (redirects, APEXCNAME).  Should this be the case, a Service
   Provider depending on this functionality would not be able to operate
   with said DNS Provider.

   Example Records: Single static host record

   Consider a template for setting a single host record.  The records
   section of the template would have a single record of type "A" and
   could have a value of:

      [{
      ''type'': ''A'',
      ''host'': ''www'',
      ''pointsTo'': ''192.168.1.1'',
      ''ttl'': 600
      }]

   This would have no variable substitution and the application of this
   template to a domain would simply set the host name "www" to the IP
   address "192.168.1.1"

   Example Records: Single variable host record for A

   In the case of a template for setting a single host record from a
   variable, the template would have a single record of type "A" and
   could have a value of:

      [{
      ''type'': ''A'',
      ''host'': ''@'',
      ''pointsTo'': ''192.168.1.%srv%'',
      ''ttl'': 600
      }]

Blinn & Carney           Expires April 23, 2017                [Page 16]
Internet-Draft               Domain Connect                 October 2016

   A query string with a key/value pair of

   srv=8

   would cause the application of this template to a domain to set the
   host name for the apex A record to the IP address "192.168.1.8" with
   a TTL of 600.

   Example: Multiple variable host record for A

   In the case of a template for setting a single host record from
   multiple variables, the template would have a single record of type
   "A" and could have a value of:

      [{
      ''type'': ''A'',
      ''host'': ''%hostname1%'',
      ''pointsTo'': ''%hostip1%'',
      ''ttl'': 600
      }]

   A query string with key/value pairs of

   hostname1=example&hostip1=192.168.1.3

   would cause the application of this template to a domain to set the
   host name "example" to the IP address "192.168.1.3" with a TTL of
   600.

   Example: Redirect

   In the case of a template for setting an HTTP redirect, the template
   would have a record of type "REDIRECT" and could have a value of:

      [{
      ''type'': REDIR301,
      ''target'': %url%
      }]

   A query string with key/value pairs of

   url=http://www.example-two.com.

   would cause the application of this template to signal to the DNS
   Provider to provision URL redirection to the target URL.

   Example Template JSON Format

Blinn & Carney           Expires April 23, 2017                [Page 17]
Internet-Draft               Domain Connect                 October 2016

      {
      "providerId": "example.com",
      "providerName": "Example Web Hosting",
      "templateId": "hosting",
      "templateName": "Wordpress by example.com",
      "logoUrl": "https://www.example.com/images/billthecat.jpg",
      "description": "This connects your domain to our super cool web
      hosting",
      "returnUrl": "https://www.example.com/connectresults",
      "launchURL" : "https://www.example.com/connectlaunch",
      "records": [

         {
         "groupId" : "service",
         "type": "A",
         "host": "www",
         "pointsTo": "%var1%",
         "ttl": "%var2%"
         },
         {
         "groupId" : "service",
         "type": "A",
         "host": "m",
         "pointsTo": "%var3%",
         "ttl": "%var2%"
         },
         {
         "groupId" : "service",
         "type": "CNAME",
         "host": "webmail",
         "pointsTo": "%var4%",
         "ttl": "%var2%"
         },
         {
         "groupId" : "verification",
         "type": "TXT",
         "host": "example",
         "pointsTo": "%var5%",
         "ttl": "%var2%"
         }
      ]
      }

Blinn & Carney           Expires April 23, 2017                [Page 18]
Internet-Draft               Domain Connect                 October 2016

4.8.  Operational and Implementation Considerations

   From a DNS Provider standpoint, it is envisioned that the user has
   appropriate warnings and checks in place to prevent accidental
   destruction of other records in DNS when applying a template or
   making manual changes in DNS.

   For example, if the application of a template through the web based
   flow would interfere with previously set DNS records (either through
   another template or manual settings), it is envisioned that the user
   would be asked to confirm the clearing of the previously set
   template.  If it would interfere with DNS records accessible through
   a previously issued OAuth flow, the provider could revoke the
   previously issued token.

   Similarly, when granting an OAuth token that interferes with a
   previously issued OAuth token, access to the old token could
   automatically be revoked.

   By doing so, this minimizes if not eliminates the case where an OAuth
   token cannot be applied due to conflicting templates or records
   existing on the domain.

   Manual changes to DNS through the DNS Provider could have appropriate
   warnings in place to prevent unwanted changes; with overrides being
   possible removing conflicting templates.

   The behavior of these interactions is left to the sophistication of
   the DNS Provider.

   Variables in templates that are hard-coded host names are the
   responsibility of the DNS Provider to protect.  That is, DNS
   Providers are responsible for ensuring that host names do not
   interfere with known values (such as m. or www. or mail.) or internal
   names that provide critical functionality that is outside the scope
   of this specification.

5.  IANA Considerations

   This document uses URNs to describe XML namespaces and XML schemas
   conforming to a registry mechanism described in [RFC3688].  The
   following URI assignment is requested of IANA:

   URI: ietf:params:xml:ns:validate-1.0

   Registrant Contact: See the "Author's Address" section of this
   document.

Blinn & Carney           Expires April 23, 2017                [Page 19]
Internet-Draft               Domain Connect                 October 2016

6.  Acknowledgements

   The authors wish to thank the following persons for their feedback
   and suggestions:

   o  Chris Ambler of GoDaddy Inc.
   o  Jody Kolker of GoDaddy Inc.

7.  Change History

7.1.  Change from 00 to 01

   Minor edits and clarifications found during implementation.

8.  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>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <http://www.rfc-editor.org/info/rfc3688>.

Authors' Addresses

   Arnold Blinn
   GoDaddy Inc.
   14455 N. Hayden Rd. #219
   Scottsdale, AZ  85260
   US

   Email: arnoldb@godaddy.com
   URI:   http://www.godaddy.com

   Roger Carney
   GoDaddy Inc.
   14455 N. Hayden Rd. #219
   Scottsdale, AZ  85260
   US

   Email: rcarney@godaddy.com
   URI:   http://www.godaddy.com

Blinn & Carney           Expires April 23, 2017                [Page 20]