idnits 2.17.1 draft-gavrichenkov-dnsop-dnssapi-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 212: '...xtensible. An MDNSSP SHOULD implement...' RFC 2119 keyword, line 215: '...wever, an MDNSSP MAY implement its own...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 05, 2018) is 2216 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Name System Operations A. Gavrichenkov 3 Internet-Draft Qrator Labs 4 Intended status: Standards Track March 05, 2018 5 Expires: September 6, 2018 7 Domain Name System Service Application Programming Interface 8 draft-gavrichenkov-dnsop-dnssapi-00 10 Abstract 12 Managed DNS services are widely used to maintain DNS zones. 13 Virtually all of them have an API of some sort, in most cases an XML- 14 RPC or JSON-RPC API, while most of them lack the support of zone 15 transfers. The latter is unlikely to change any time soon due to the 16 reasons outlined below. This document describes a protocol, a common 17 denominator of existing API protocols, that both a service provider 18 and its customer can use to exchange information about DNS zones and 19 policies. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 6, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Functionality supported by managed DNS service providers . . 3 57 2.1. Failover . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2. Location-based DNS routing . . . . . . . . . . . . . . . 4 59 2.3. Firewalling . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.4. Load balancing . . . . . . . . . . . . . . . . . . . . . 4 61 2.5. Rate limiting . . . . . . . . . . . . . . . . . . . . . . 5 62 2.6. Statistics . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. General policy on additional extensions . . . . . . . . . . . 5 64 4. DNSSAPI protocol specification . . . . . . . . . . . . . . . 5 65 5. Normative References . . . . . . . . . . . . . . . . . . . . 5 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 Today, managed DNS services are a common solution for setting up and 71 maintaining a DNS infrastructure for an enterprise. Those services 72 often offer convenient functionality out of the box, e.g. failover, 73 granular load balancing or geotargeting, while being more resilient 74 to distributed denial-of-service attacks than a simple in-house 75 solution could be. 77 However, the main challenge with managed DNS services is managing 78 them. In case there's an update in the DNS setup, an enterprise 79 would want it to be propagated to the managed service as soon as 80 possible. However, existing mechanisms like zone transfer [RFC5936] 81 or dynamic updates [RFC2136] are rarely implemented by managed DNS 82 service providers, leaving an enterprise with an uncomfortable choice 83 of either using a Web interface to manually set up zones and 84 policies, or using an API of that provider. 86 There are reasons why existing mechanisms fail to gain popularity 87 among service providers and their customers. First, zone transfer 88 doesn't support virtually any of the features a customer might want 89 from a service provider, except for a trivial name resolution. For 90 instance, it is impossible to propagate a geography-based policy 91 towards a service provider using zone transfer itself, with 92 accordance to standard; this can be achieved ad hoc if both a 93 customer and a provider agree on a particular zone naming policy, 94 however, as this is not supported by an Internet standard, it makes 95 changing a service provider or adding a new one a touch challenge. 97 Second, an enterprise which is using a managed DNS service might not 98 be operating its own primary DNS server at all, sticking with simple 99 deployment database exports. An XML-RPC or JSON-RPC API fits that 100 model rather well, as handlers for those are highly likely to be 101 implemented by a personnel quite familiar with the concepts of XML 102 and/or JSON-RPC. However, implementing a binary protocol might be 103 viewed as another challenge. 105 Next, both zone transfers and dynamic updates go in one direction, 106 while an enterprise generally might want a feedback, including, but 107 not limited to, traffic statistics overview, average response time, 108 query type statistics, and so on. This is, once again, usually 109 incorporated in a managed DNS service API. 111 However, the main issue with the latter is that there's currently no 112 Internet standard providing a guidance for the API design. As the 113 result, each DNS provider implements and maintains its own API, with 114 its own naming schemes and type layouts, once again making migration 115 from one provider to another - or operating more than one provider 116 simultaneously - a challenge for network and system operations 117 departments. 119 This might be viewed by some as a sort of a vendor lock-in, however, 120 this issue alone is highly unlikely to really help retaining a 121 customer who is somehow dissatisfied with the service and is eager to 122 change the provider. What is beyond doubt is that a customer will 123 just be further disappointed after they will face all the projected 124 issues while moving to another service. 126 This way, it might be useful to agree on a common API protocol, JSON- 127 RPC-based, with a built-in support for all the features offered by 128 managed DNS services today, and extensible in order to add more 129 features in future. The purpose of this document is to provide a 130 description of such a protocol. This protocol might then be viewed 131 as a guidance for new DNS providers which are going to implement 132 their API, or for existing providers refactoring their code. 134 2. Functionality supported by managed DNS service providers 136 Here is the list of features implemented by managed DNS service 137 providers (MDNSSP) today. 139 2.1. Failover 141 Enterprises are often in a high demand for online business 142 continuency, and as the result, they opt for some redundancy. E.g. 143 if they operate a Web site, they often have more than one server, on 144 more than one IP address, serving the Web content. There are mainly 145 two options to implement that redundancy: 147 o Those servers may be put in an anycast IP prefix, announced from 148 different locations, so that if a location goes down, its traffic 149 is then served by nearest network locations 151 o Those servers may operate simultaneously, on a round-robin basis, 152 all being put in a DNS A record entry. 154 The issue with the latter approach is that one has to set up 155 monitoring and keep-alive checks of some sort to take a failing 156 server out of round-robin as soon as possible. MDNSSP often offer 157 convenient built-in features to do that. 159 2.2. Location-based DNS routing 161 Geography-based DNS routing, known also as geo-balancing, is a widely 162 used method to reduce the latency between network clients and 163 services by looking at the IP source of a DNS query and returning an 164 answer with an IP address which is as close to a client as possible 165 in terms of geolocation. The distance between a client and each in 166 the set of servers may be measured in different ways, including 167 looking at the country a source IP address belongs to, a region or 168 city, or even comparing latitude and longitude. 170 However, due to routing policies of network operators and also due to 171 the reported inaccuracy of regional internet registries' databases 172 (which are the only officially recognized source of the mapping 173 between IP addresses and countries and geographic regions), there 174 might be latency issues now with geography-based DNS routing. Some 175 MDNSSP handle that by allowing more specific policies to be set up, 176 e.g. ASN-based or prefix-based policies. 178 2.3. Firewalling 180 Firewall access rules might be viewed as a subset of location-based 181 policies, except for a simpler policy of just dropping the traffic 182 instead of processing it. However, sometimes further requirements 183 may take place, e.g. forcing a challenge towards a source IP address, 184 and so on. Those features are a subject of a different extension 185 than location-based routing, being applied before it. 187 2.4. Load balancing 189 There are a lot of things a DNS server can do to balance traffic 190 towards a set of servers. The simplest example would be shuffling 191 answers based on their weight. 193 2.5. Rate limiting 195 An MDNSSP may limit the amount of requests coming towards a single 196 server by returning intentionally wrong reponse to an A query, e.g. 197 NXDOMAIN. This might help to keep a server running in case of a 198 sudden traffic spike. 200 The exact amount of queries triggering that condition must be 201 specified as an argument during the setup. 203 2.6. Statistics 205 Generally, an MDNSSP offers metrics regarding the overall inbound and 206 outbound network traffic, query count, average and/or median response 207 time, and all or some of this data for different query names, types, 208 response codes and so on. 210 3. General policy on additional extensions 212 The API is designed to be extensible. An MDNSSP SHOULD implement 213 functionality in a way specified by this document in case this 214 functionality can be handled by methods described in this 215 specification. However, an MDNSSP MAY implement its own private 216 extension if the standard functionality doesn't fit their needs. 218 An extension for the DNSSAPI protocol must either follow the naming 219 structure for the private extensions' domain or use an IANA-allocated 220 extension name. 222 4. DNSSAPI protocol specification 224 ... 226 5. Normative References 228 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 229 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 230 RFC 2136, DOI 10.17487/RFC2136, April 1997, 231 . 233 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 234 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 235 . 237 Author's Address 239 Artyom Gavrichenkov 240 Qrator Labs 242 Email: ag@qrator.net