Internet DRAFT - draft-gavrichenkov-dnsop-dnssapi

draft-gavrichenkov-dnsop-dnssapi







Domain Name System Operations                            A. Gavrichenkov
Internet-Draft                                               Qrator Labs
Intended status: Standards Track                          March 05, 2018
Expires: September 6, 2018


      Domain Name System Service Application Programming Interface
                  draft-gavrichenkov-dnsop-dnssapi-00

Abstract

   Managed DNS services are widely used to maintain DNS zones.
   Virtually all of them have an API of some sort, in most cases an XML-
   RPC or JSON-RPC API, while most of them lack the support of zone
   transfers.  The latter is unlikely to change any time soon due to the
   reasons outlined below.  This document describes a protocol, a common
   denominator of existing API protocols, that both a service provider
   and its customer can use to exchange information about DNS zones and
   policies.

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 https://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 6, 2018.

Copyright Notice

   Copyright (c) 2018 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
   (https://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



Gavrichenkov            Expires September 6, 2018               [Page 1]

Internet-Draft                   DNSSAPI                      March 2018


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Functionality supported by managed DNS service providers  . .   3
     2.1.  Failover  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Location-based DNS routing  . . . . . . . . . . . . . . .   4
     2.3.  Firewalling . . . . . . . . . . . . . . . . . . . . . . .   4
     2.4.  Load balancing  . . . . . . . . . . . . . . . . . . . . .   4
     2.5.  Rate limiting . . . . . . . . . . . . . . . . . . . . . .   5
     2.6.  Statistics  . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  General policy on additional extensions . . . . . . . . . . .   5
   4.  DNSSAPI protocol specification  . . . . . . . . . . . . . . .   5
   5.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Today, managed DNS services are a common solution for setting up and
   maintaining a DNS infrastructure for an enterprise.  Those services
   often offer convenient functionality out of the box, e.g. failover,
   granular load balancing or geotargeting, while being more resilient
   to distributed denial-of-service attacks than a simple in-house
   solution could be.

   However, the main challenge with managed DNS services is managing
   them.  In case there's an update in the DNS setup, an enterprise
   would want it to be propagated to the managed service as soon as
   possible.  However, existing mechanisms like zone transfer [RFC5936]
   or dynamic updates [RFC2136] are rarely implemented by managed DNS
   service providers, leaving an enterprise with an uncomfortable choice
   of either using a Web interface to manually set up zones and
   policies, or using an API of that provider.

   There are reasons why existing mechanisms fail to gain popularity
   among service providers and their customers.  First, zone transfer
   doesn't support virtually any of the features a customer might want
   from a service provider, except for a trivial name resolution.  For
   instance, it is impossible to propagate a geography-based policy
   towards a service provider using zone transfer itself, with
   accordance to standard; this can be achieved ad hoc if both a
   customer and a provider agree on a particular zone naming policy,
   however, as this is not supported by an Internet standard, it makes
   changing a service provider or adding a new one a touch challenge.




Gavrichenkov            Expires September 6, 2018               [Page 2]

Internet-Draft                   DNSSAPI                      March 2018


   Second, an enterprise which is using a managed DNS service might not
   be operating its own primary DNS server at all, sticking with simple
   deployment database exports.  An XML-RPC or JSON-RPC API fits that
   model rather well, as handlers for those are highly likely to be
   implemented by a personnel quite familiar with the concepts of XML
   and/or JSON-RPC.  However, implementing a binary protocol might be
   viewed as another challenge.

   Next, both zone transfers and dynamic updates go in one direction,
   while an enterprise generally might want a feedback, including, but
   not limited to, traffic statistics overview, average response time,
   query type statistics, and so on.  This is, once again, usually
   incorporated in a managed DNS service API.

   However, the main issue with the latter is that there's currently no
   Internet standard providing a guidance for the API design.  As the
   result, each DNS provider implements and maintains its own API, with
   its own naming schemes and type layouts, once again making migration
   from one provider to another - or operating more than one provider
   simultaneously - a challenge for network and system operations
   departments.

   This might be viewed by some as a sort of a vendor lock-in, however,
   this issue alone is highly unlikely to really help retaining a
   customer who is somehow dissatisfied with the service and is eager to
   change the provider.  What is beyond doubt is that a customer will
   just be further disappointed after they will face all the projected
   issues while moving to another service.

   This way, it might be useful to agree on a common API protocol, JSON-
   RPC-based, with a built-in support for all the features offered by
   managed DNS services today, and extensible in order to add more
   features in future.  The purpose of this document is to provide a
   description of such a protocol.  This protocol might then be viewed
   as a guidance for new DNS providers which are going to implement
   their API, or for existing providers refactoring their code.

2.  Functionality supported by managed DNS service providers

   Here is the list of features implemented by managed DNS service
   providers (MDNSSP) today.

2.1.  Failover

   Enterprises are often in a high demand for online business
   continuency, and as the result, they opt for some redundancy.  E.g.
   if they operate a Web site, they often have more than one server, on




Gavrichenkov            Expires September 6, 2018               [Page 3]

Internet-Draft                   DNSSAPI                      March 2018


   more than one IP address, serving the Web content.  There are mainly
   two options to implement that redundancy:

   o  Those servers may be put in an anycast IP prefix, announced from
      different locations, so that if a location goes down, its traffic
      is then served by nearest network locations

   o  Those servers may operate simultaneously, on a round-robin basis,
      all being put in a DNS A record entry.

   The issue with the latter approach is that one has to set up
   monitoring and keep-alive checks of some sort to take a failing
   server out of round-robin as soon as possible.  MDNSSP often offer
   convenient built-in features to do that.

2.2.  Location-based DNS routing

   Geography-based DNS routing, known also as geo-balancing, is a widely
   used method to reduce the latency between network clients and
   services by looking at the IP source of a DNS query and returning an
   answer with an IP address which is as close to a client as possible
   in terms of geolocation.  The distance between a client and each in
   the set of servers may be measured in different ways, including
   looking at the country a source IP address belongs to, a region or
   city, or even comparing latitude and longitude.

   However, due to routing policies of network operators and also due to
   the reported inaccuracy of regional internet registries' databases
   (which are the only officially recognized source of the mapping
   between IP addresses and countries and geographic regions), there
   might be latency issues now with geography-based DNS routing.  Some
   MDNSSP handle that by allowing more specific policies to be set up,
   e.g.  ASN-based or prefix-based policies.

2.3.  Firewalling

   Firewall access rules might be viewed as a subset of location-based
   policies, except for a simpler policy of just dropping the traffic
   instead of processing it.  However, sometimes further requirements
   may take place, e.g. forcing a challenge towards a source IP address,
   and so on.  Those features are a subject of a different extension
   than location-based routing, being applied before it.

2.4.  Load balancing

   There are a lot of things a DNS server can do to balance traffic
   towards a set of servers.  The simplest example would be shuffling
   answers based on their weight.



Gavrichenkov            Expires September 6, 2018               [Page 4]

Internet-Draft                   DNSSAPI                      March 2018


2.5.  Rate limiting

   An MDNSSP may limit the amount of requests coming towards a single
   server by returning intentionally wrong reponse to an A query, e.g.
   NXDOMAIN.  This might help to keep a server running in case of a
   sudden traffic spike.

   The exact amount of queries triggering that condition must be
   specified as an argument during the setup.

2.6.  Statistics

   Generally, an MDNSSP offers metrics regarding the overall inbound and
   outbound network traffic, query count, average and/or median response
   time, and all or some of this data for different query names, types,
   response codes and so on.

3.  General policy on additional extensions

   The API is designed to be extensible.  An MDNSSP SHOULD implement
   functionality in a way specified by this document in case this
   functionality can be handled by methods described in this
   specification.  However, an MDNSSP MAY implement its own private
   extension if the standard functionality doesn't fit their needs.

   An extension for the DNSSAPI protocol must either follow the naming
   structure for the private extensions' domain or use an IANA-allocated
   extension name.

4.  DNSSAPI protocol specification

   ...

5.  Normative References

   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, DOI 10.17487/RFC2136, April 1997,
              <https://www.rfc-editor.org/info/rfc2136>.

   [RFC5936]  Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
              (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
              <https://www.rfc-editor.org/info/rfc5936>.








Gavrichenkov            Expires September 6, 2018               [Page 5]

Internet-Draft                   DNSSAPI                      March 2018


Author's Address

   Artyom Gavrichenkov
   Qrator Labs

   Email: ag@qrator.net













































Gavrichenkov            Expires September 6, 2018               [Page 6]