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

Versions: 00

Network Working Group                                         R. Edmonds
Internet-Draft                                                    Fastly
Intended status: Standards Track                            July 2, 2017
Expires: January 3, 2018


                       Signaling DNS Capabilities
                  draft-edmonds-dnsop-capabilities-00

Abstract

   This document defines an Extension Mechanisms for DNS (EDNS0) option
   that allows DNS clients and servers to signal support for DNS
   protocol capabilities.  Clients and servers that support this option
   can take advantage of new DNS protocol features when completing a
   transaction, and by caching the set of capabilities advertised by a
   DNS server, a DNS client can utilize any mutually supported DNS
   protocol capability in subsequent queries.

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 January 3, 2018.

Copyright Notice

   Copyright (c) 2017 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



Edmonds                  Expires January 3, 2018                [Page 1]


Internet-Draft              DNS Capabilities                   July 2017


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Option Format . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  The "DNS Features" Capability . . . . . . . . . . . . . .   5
     4.2.  The "EDNS0 Option Codes" Capability . . . . . . . . . . .   6
   5.  Protocol Description  . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Originating the Option  . . . . . . . . . . . . . . . . .   7
     5.2.  Generating a Response . . . . . . . . . . . . . . . . . .   7
     5.3.  Caching the Option  . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Implementation Status . . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   10. TODO  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     11.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   The lack of explicit capability signaling in the DNS protocol
   [RFC1035] makes it hard to deploy new functionality.  For instance,
   Client Subnet in DNS Queries [RFC7871] defines an EDNS option to be
   used with a subset of specialized zones on the Internet capable of
   producing "tailored responses".  It describes two strategies for
   deciding when to originate the Client Subnet option: the use of
   periodic probes by the resolver, and the use of a safelist of
   nameservers permitted by the resolver operator to use the option.  In
   practice, few EDNS options have been defined, and EDNS options have
   not been originated routinely by general purpose resolvers on the
   Internet.  If many EDNS options were to be widely used, it would be
   unreasonable to expect resolver implementations to perform option-
   specific probing or resolver operators to perform option-specific
   safelisting for each newly introduced EDNS option.

   EDNS options are not the only aspect of the DNS protocol that can
   benefit from explicit capability signaling.  Extension Mechanisms for
   DNS (EDNS(0)) [RFC6891] includes a VERSION field in the OPT Pseudo-
   RR, but encourages clients to set this field to the "lowest
   implemented level capable of expressing a transaction, to minimize
   the responder and network load of discovering the greatest common



Edmonds                  Expires January 3, 2018                [Page 2]


Internet-Draft              DNS Capabilities                   July 2017


   implementation level between requestor and responder".  If new EDNS
   VERSIONs were to be introduced, capability signaling would permit a
   DNS transaction initiated with a lower implementation level to be
   completed with the highest mutually supported implementation level.

   Similarly, Q and Meta-TYPEs [RFC6895] (Section 3.1) have been
   allocated sparingly.  Introducing a new general purpose QTYPE is
   problematic, because by definition the existing installed base of
   nameservers will not support the new QTYPE.

   This document defines an EDNS0 option that allows DNS clients and
   servers to exchange lists of supported "DNS Capabilities".  This new
   option includes explicit client-side caching semantics that allow
   future queries to be initiated that take advantage of mutually
   supported functionality.  It also defines two DNS Capabilities.  The
   first, "DNS Features", encodes an array of feature flags that future
   DNS protocol features may take advantage of.  The second, "EDNS0
   Option Codes", encodes the set of EDNS0 options supported by the
   client or server.

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

3.  Overview

   A DNS client that implements this protocol will include the "DNS
   Capabilities" EDNS0 option described in Section 4 in queries that it
   initiates (Section 5.1).  If a DNS server that implements this
   protocol receives a query that includes this option, it will generate
   a corresponding response (Section 5.2) indicating which DNS
   Capabilities it supports and the length of time that the client may
   cache the server's capabilities for (Section 5.3).

4.  Option Format

   This protocol uses an EDNS0 [RFC6891] option to encode the
   capabilities supported by the client or server.  For each capability,
   the option contains a TLV element <Capability Type, Capability
   Length, Capability Value>.  Multiple Capability TLVs may be
   concatenated together, and the ordering of Capability TLVs within the
   option is not significant.  The option is structured as follows:







Edmonds                  Expires January 3, 2018                [Page 3]


Internet-Draft              DNS Capabilities                   July 2017


                +0 (MSB)                            +1 (LSB)
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   0: |                          OPTION-CODE                          |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   2: |                         OPTION-LENGTH                         |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   4: |                      OPTION-TTL-MINUTES                       |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   6: |        CAPABILITY TYPE        |       CAPABILITY LENGTH       |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   8: |                                                               |
      /                      CAPABILITY VALUE...                      /
      /                                                               /
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      /                                                               /
      /                (Additional Capability TLVs...)                /
      /                                                               /
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   o  (Defined in [RFC6891]) OPTION-CODE, 2 octets, for the DNS
      Capabilities option is TBD-DNS-CAPABILITIES-OPT.

   o  (Defined in [RFC6891]) OPTION-LENGTH, 2 octets, contains the
      length of the payload (everything after OPTION-LENGTH) in octets.

   o  OPTION-TTL-MINUTES, 2 octets, unsigned, indicates the number of
      minutes clients may cache this DNS Capabilities option.

   o  CAPABILITY TYPE, 1 octet, identifies the Capability encoded in the
      Capability TLV, using codes as assigned in TBD-DNS-CAPABILITIES-
      TYPE-REGISTRY.

   o  CAPABILITY LENGTH, 1 octet, unsigned, encodes the number of octets
      in the CAPABILITY VALUE field.

   o  CAPABILITY VALUE, variable number of octets, contains capability-
      specific data.

   The format of the CAPABILITY VALUE field depends on the value of the
   CAPABILITY TYPE field.  This document defines the following
   CAPABILITY TYPE values:










Edmonds                  Expires January 3, 2018                [Page 4]


Internet-Draft              DNS Capabilities                   July 2017


   +---------+-------------------------------+-----------+-------------+
   |   Value |              Name             | Singleton |  Reference  |
   +---------+-------------------------------+-----------+-------------+
   |       0 |            Reserved           |           |     This    |
   |         |                               |           |   document  |
   |       1 |          DNS Features         |     Y     | Section 4.1 |
   |       2 |       EDNS0 Option Codes      |     Y     | Section 4.2 |
   |   3-249 |           Unassigned          |           |             |
   | 250-254 |          Reserved for         |           |     This    |
   |         |     Local/Experimental Use    |           |   document  |
   |     255 |            Reserved           |           |     This    |
   |         |                               |           |   document  |
   +---------+-------------------------------+-----------+-------------+

                          CAPABILITY TYPE values.

   The "DNS Features" and "EDNS0 Option Codes" capabilities are further
   described below.

4.1.  The "DNS Features" Capability

   The "DNS Features" capability is a variable length array of feature
   flags encoded as a bitmap with trailing zero octets omitted.

   New DNS protocol functionality that requires upgraded semantics may
   register a flag in this capability.  DNS clients and servers that
   support a new protocol feature with a feature flag in this capability
   MUST set the corresponding bit in this capability in queries and
   responses when those messages include a DNS Capabilities option.

   Each feature flag is assigned an individual bit in the "DNS Features"
   bitmap.  For example, the first feature flag corresponds to the Most
   Significant Bit (MSB) of the first octet of the array, the ninth
   feature flag corresponds to the MSB of the second octet of the array,
   and the 256th feature flag corresponds to the Least Significant Bit
   (LSB) of the 32nd octet of the array.

   If no "DNS Features" flags are supported by the DNS client or server,
   this capability MUST be omitted from the DNS Capabilities option.
   Trailing zero octets in the "DNS Features" bitmap MUST be omitted.
   The minimum CAPABILITY LENGTH value for this capability is 1, and the
   maximum CAPABILITY LENGTH value for this capability is 32.









Edmonds                  Expires January 3, 2018                [Page 5]


Internet-Draft              DNS Capabilities                   July 2017


   +---------+------+----------------------------------+---------------+
   |     Bit | Flag |           Description            |   Reference   |
   +---------+------+----------------------------------+---------------+
   |   0-249 |      |            Unassigned            |               |
   | 250-254 |      | Reserved for Local/Experimental  | This document |
   |         |      |               Use                |               |
   |     255 |      |             Reserved             | This document |
   +---------+------+----------------------------------+---------------+

                           "DNS Features" flags.

   The "DNS Features" capability is a singleton capability.  It MUST NOT
   appear more than once in a DNS Capabilities option.

4.2.  The "EDNS0 Option Codes" Capability

   [RFC4034] (Section 4.1.2) defines the Type Bit Maps field of the NSEC
   RR using a sparse encoding of the 16-bit code points in the DNS
   Resource Record (RR) TYPEs registry.  This document reuses that
   "window block" bitmap encoding for the "DNS EDNS0 Option Codes (OPT)"
   registry, which is also a 16-bit code space.

   The "EDNS0 Option Codes" capability is a window block encoded bitmap
   indicating which EDNS0 Option Codes are supported by the DNS client
   or server.  If the "EDNS0 Option Codes" capability is included in the
   DNS Capability option in a DNS message, the EDNS0 Option Codes
   supported by the DNS client or server SHOULD be indicated using this
   capability.

   The EDNS0 Option Codes space is split into 256 window blocks, each
   representing the low-order 8 bits of the 16-bit code space.  Each
   block that has at least one indicated EDNS0 Option Code is encoded
   using a single octet window number (from 0 to 255), a single octet
   bitmap length (from 1 to 32) indicating the number of octets used for
   the window block's bitmap, and up to 32 octets (256 bits) of bitmap.

   Window blocks are present in the "EDNS0 Option Codes" capability in
   increasing numerical order.

   Each bitmap encodes the low-order 8 bits of EDNS0 Option Codes within
   the window block.  The first bit is bit 0.  For window block 0, bit 3
   corresponds to NSID [RFC5001], bit 8 corresponds to EDNS Client
   Subnet [RFC7871], and so forth.  If a bit is set, it indicates that
   the corresponding EDNS0 Option Code is supported by the DNS protocol
   implementation that sent the message containing the "EDNS0 Option
   Codes" capability.





Edmonds                  Expires January 3, 2018                [Page 6]


Internet-Draft              DNS Capabilities                   July 2017


   Window blocks with no EDNS0 Option Codes present MUST NOT be
   included.  Trailing zero octets in the bitmap MUST be omitted.  The
   length of each block's bitmap is determined by the option code with
   the largest numerical value, within that block, among the set of
   option codes indicated as supported.  Trailing zero octets not
   specified MUST be interpreted as zero octets.

   The "EDNS0 Option Codes" capability is a singleton capability.  It
   MUST NOT appear more than once in a DNS Capabilities option.

5.  Protocol Description

5.1.  Originating the Option

   A DNS client that implements this protocol SHOULD include the DNS
   Capabilities option in each EDNS(0) enabled query it sends.  If the
   DNS client supports any DNS Features (Section 4.1), it MUST include a
   DNS Features capability in the DNS Capabilities option advertising
   the supported features.  If the DNS client supports any EDNS0 Option
   Codes, it MAY include an EDNS0 Option Codes capability in the DNS
   Capabilities option advertising the supported option codes.

   DNS clients MUST set the OPTION-TTL-MINUTES field to zero.

5.2.  Generating a Response

   When a query containing the DNS Capabilities option is received, a
   DNS server supporting DNS Capabilities MAY use the information
   contained in the client's option to generate a response that utilizes
   the functionality that the client has advertised as supported.

   A DNS server that implements this protocol and receives a DNS
   Capabilities option MUST include a DNS Capabilities option in its
   response.  If the DNS server implements any DNS Features
   (Section 4.1), it MUST include a DNS Features capability in the DNS
   Capabilities option advertising the supported features.  If the DNS
   server supports any EDNS0 Option Codes, it MUST include an EDNS0
   Option Codes capability in the DNS Capabilities option advertising
   the supported option codes.

   If the DNS Capabilities option was not included in a query, a DNS
   server MUST NOT include one when generating a response.

5.3.  Caching the Option

   When a DNS client originates a query containing the DNS Capabilities
   option and receives a response containing the DNS Capabilities
   option, the data contained in the option SHOULD be cached so that



Edmonds                  Expires January 3, 2018                [Page 7]


Internet-Draft              DNS Capabilities                   July 2017


   future queries sent to the same DNS server can utilize functionality
   that the server has advertised as supported.  A query sent to "the
   same DNS server" means a query sent to a server identified by the
   same network address as a previous query.

   The amount of time that the DNS Capabilities option may be cached for
   is indicated in the OPTION-TTL-MINUTES field.  This allows a maximum
   cache entry lifetime of 45.5 days.  If a DNS Capabilities option for
   a given DNS server is already cached when a subsequent response
   containing a DNS Capabilities option is received, the cached option
   MAY be overwritten with the newer data, and the cache entry's
   lifetime MAY be extended or reduced.

   If a DNS client receives a response containing the DNS Capabilities
   option where the OPTION-TTL-MINUTES field is zero, the data contained
   in the option MUST be discarded, and the response MUST be treated as
   if it did not contain a DNS Capabilities option.

6.  IANA Considerations

   To be written.

7.  Implementation Status

   To be written.

8.  Security Considerations

   To be written.

9.  Acknowledgements

   To be written.

10.  TODO

   1.  There is a limited amount of space available in a UDP DNS query
       message (512 octets), and a query message with a maximum size
       query name (255 octets) and a plausible set of other EDNS0
       options could be as much as ~300 octets, leaving ~200 octets for
       the DNS Capabilities option.  What should happen if all of the
       desired DNS Capabilities data can't be serialized into a <= 512
       octet query message?








Edmonds                  Expires January 3, 2018                [Page 8]


Internet-Draft              DNS Capabilities                   July 2017


11.  References

11.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <http://www.rfc-editor.org/info/rfc1035>.

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

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <http://www.rfc-editor.org/info/rfc4034>.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891,
              DOI 10.17487/RFC6891, April 2013,
              <http://www.rfc-editor.org/info/rfc6891>.

11.2.  Informative References

   [RFC5001]  Austein, R., "DNS Name Server Identifier (NSID) Option",
              RFC 5001, DOI 10.17487/RFC5001, August 2007,
              <http://www.rfc-editor.org/info/rfc5001>.

   [RFC6895]  Eastlake 3rd, D., "Domain Name System (DNS) IANA
              Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
              April 2013, <http://www.rfc-editor.org/info/rfc6895>.

   [RFC7871]  Contavalli, C., van der Gaast, W., Lawrence, D., and W.
              Kumari, "Client Subnet in DNS Queries", RFC 7871,
              DOI 10.17487/RFC7871, May 2016,
              <http://www.rfc-editor.org/info/rfc7871>.

Author's Address

   Robert Edmonds
   Fastly
   Atlanta, Georgia
   United States of America

   Email: edmonds@mycre.ws





Edmonds                  Expires January 3, 2018                [Page 9]


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