DNS Message Compression
draft-vavrusa-dnscompr-00

Abstract

This document describes an application of data compression algorithms on DNS messages with the goal of reducing message size of frequent responses. The client proposes compression protocol which the server may use to compress an arbitrary part of the response.

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 September 24, 2015.

Copyright Notice

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

Table of Contents

• 1. Introduction
• 1.1. Requirements
• 1.2. Terminology
• 1.3. Rationale
• 2. How the remainder compression works
• 3. The COMPRESS OPT option
• 3.1. Algorithms
• 4. The remainder compression indicator
• 5. Examples
• 6. Client: declaring compression support
• 7. Server: compressing message part
• 8. Backward Compatibility
• 9. Client considerations
• 10. Performance considerations
• 11. Security considerations
• 12. Acknowledgements
• 13. References
• 13.1. Normative References
• 13.2. Informative References
• Appendix A. Appendix A. Evaluation on selected responses
• Author's Address

1. Introduction

1.1. Requirements

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

1.2. Terminology

The reader is assumed to be familiar with the basic DNS and DNSSEC concepts described in [RFC1034], [RFC1035] and [RFC6891]. The terms "compression", "decompression" are used as in [RFC1951].

1.3. Rationale

The domain name compression was introduced in Section 4.1.4 of [RFC1035] with the intent of reducing message length by avoiding repetitive sequences of domain name labels. This has proven useful especially for the the UDP-carried messages, so the Section 6.1.2.4 of [RFC1123] mandated the use of compression in responses.

A domain name is represented by a sequence of labels, where the first octet denotes the label length, excluding itself. Each domain name is required to be terminated by a zero-length label representing the root domain name. [RFC1035] declares that a label length MUST be 63 bytes or less. This requires the least significant 6 bits from the first octet for the label length, and leaves the 2 most significant bits reserved for second meaning.

If both most significant bits have a value of '1', the following 14 bits represent a compression pointer, which denotes a position in the message where the next label continues. This position may also be a compression pointer, as it points backwards and the final name doesn't exceed the size limits defined in section 2.3.4 of [RFC1035]. The method implies only the repetitive domain name labels may be compressed.

Later, Section 5 of [RFC6891] defined an extended label type, where the most significant two bits have a value of '01', and the remaining 6 bits are used for extended label type. Section 3 of [RFC3363] has shown that the extended label types are rejected as malformed by unaware DNS implementations.

The proposed compression method introduces an extended label type to indicate that the remainder of the message is compressed, and an OPT RR option COMPRESS to negotiate compression support. To ensure compatibility with existing infrastructure, the new label type MUST NOT be used in a DNS query, and it MAY be used in DNS response only after the support is indicated by the presence of the COMPRESS option in the query.

2. How the remainder compression works

The client proposes a compression algorithm via the COMPRESS OPT option, this mandates that the both client and the server support [RFC6891] EDNS. If the server doesn't support EDNS, no OPT RR is returned in the response and no compression occurs. A COMPRESS-aware server MAY place a compression indicator at any start of the label in the message, followed by the compressed remainder of the message. The server SHOULD use the client-proposed algorithm if it supports it, but it MAY use the mandatory algorithm as well.

If a client recognizes compression indicator, it decompresses the remainder of the message in its place. If the server uses mandatory algorithm instead of negotiated, client SHOULD assume that the server doesn't support the negotiated algorithm, and SHOULD try different algorithm next time. If the response isn't compressed, the client MUST NOT presume that the server doesn't support it.

3. The COMPRESS OPT option

COMPRESS is an OPT RR [RFC6891] option, that can be included once in the RDATA of an OPT RR in DNS messages.

The option is encoded in 5 bytes as shown below.

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       OPTION-CODE TBD         |     OPTION-LENGTH = 1         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Algorithm   |
+-+-+-+-+-+-+-+-+

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 0  1| 0  0  0  0  0  1|       ALGORITHM       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+