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]