The EDNS(0) Padding Option
RFC 7830
Internet Engineering Task Force (IETF) A. Mayrhofer
Request for Comments: 7830 nic.at GmbH
Category: Standards Track May 2016
ISSN: 2070-1721
The EDNS(0) Padding Option
Abstract
This document specifies the EDNS(0) "Padding" option, which allows
DNS clients and servers to pad request and response messages by a
variable number of octets.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7830.
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.
Mayrhofer Standards Track [Page 1]
RFC 7830 EDNS(0) Padding May 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. The "Padding" Option . . . . . . . . . . . . . . . . . . . . 3
4. Usage Considerations . . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
The Domain Name System (DNS) [RFC1035] was specified to transport DNS
messages in cleartext form. Since this can expose significant
amounts of information about the Internet activities of an end user,
the IETF has undertaken work to provide confidentiality to DNS
transactions (see the DPRIVE working group). Encrypting the DNS
transport is considered one of the options to improve the situation.
However, even if both DNS query and response messages were encrypted,
metadata could still be used to correlate such messages with well-
known unencrypted messages, hence jeopardizing some of the
confidentiality gained by encryption. One such property is the
message size.
This document specifies the Extensions Mechanisms for DNS (EDNS(0))
"Padding" option, which allows DNS clients and servers to
artificially increase the size of a DNS message by a variable number
of bytes, hampering size-based correlation of the encrypted message.
2. Terminology
The terms "Requestor" and "Responder" are to be interpreted as
specified in [RFC6891].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
Mayrhofer Standards Track [Page 2]
RFC 7830 EDNS(0) Padding May 2016
3. The "Padding" Option
The EDNS(0) [RFC6891] specifies a mechanism to include new options in
DNS packets, contained in the RDATA of the OPT meta-RR. This
document specifies the "Padding" option in order to allow clients and
servers to pad DNS packets by a variable number of bytes. The
"Padding" option MUST occur at most, once per OPT meta-RR (and hence,
at most once per message).
The figure below specifies the structure of the option in the RDATA
of the OPT RR:
0 8 16
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| OPTION-CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| OPTION-LENGTH |
Show full document text