datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

DNSSEC and IPv6 A6 aware server/resolver message size requirements
RFC 3226

Document type: RFC - Proposed Standard (December 2001; Errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 3226 (Proposed Standard)
Responsible AD: (None)
Send notices to: No addresses provided

Network Working Group                                     O. Gudmundsson
Request for Comments: 3226                                 December 2001
Updates: 2874, 2535
Category: Standards Track

   DNSSEC and IPv6 A6 aware server/resolver message size requirements

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document mandates support for EDNS0 (Extension Mechanisms for
   DNS) in DNS entities claiming to support either DNS Security
   Extensions or A6 records.  This requirement is necessary because
   these new features increase the size of DNS messages.  If EDNS0 is
   not supported fall back to TCP will happen, having a detrimental
   impact on query latency and DNS server load.  This document updates
   RFC 2535 and RFC 2874, by adding new requirements.

1.  Introduction

   Familiarity with the DNS [RFC1034, RFC1035], DNS Security Extensions
   [RFC2535], EDNS0 [RFC2671] and A6 [RFC2874] is helpful.

   STD 13, RFC 1035 Section 2.3.4 requires that DNS messages over UDP
   have a data payload of 512 octets or less.  Most DNS software today
   will not accept larger UDP datagrams.  Any answer that requires more
   than 512 octets, results in a partial and sometimes useless reply
   with the Truncation Bit set; in most cases the requester will then
   retry using TCP.  Furthermore, server delivery of truncated responses
   varies widely and resolver handling of these responses also varies,
   leading to additional inefficiencies in handling truncation.

   Compared to UDP, TCP is an expensive protocol to use for a simple
   transaction like DNS: a TCP connection requires 5 packets for setup
   and tear down, excluding data packets, thus requiring at least 3
   round trips on top of the one for the original UDP query.  The DNS

Gudmundsson                 Standards Track                     [Page 1]
RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001

   server also needs to keep a state of the connection during this
   transaction.  Many DNS servers answer thousands of queries per
   second, requiring them to use TCP will cause significant overhead and
   delays.

1.1.  Requirements

   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
   in this document are to be interpreted as described in RFC 2119.

2.  Motivating factors

2.1.  DNSSEC motivations

   DNSSEC [RFC2535] secures DNS by adding a Public Key signature on each
   RR set.  These signatures range in size from about 80 octets to 800
   octets, most are going to be in the range of 80 to 200 octets.  The
   addition of signatures on each or most RR sets in an answer
   significantly increases the size of DNS answers from secure zones.

   For performance reasons and to reduce load on DNS servers, it is
   important that security aware servers and resolvers get all the data
   in Answer and Authority section in one query without truncation.
   Sending Additional Data in the same query is helpful when the server
   is authoritative for the data, and this reduces round trips.

   DNSSEC OK[OK] specifies how a client can, using EDNS0, indicate that
   it is interested in receiving DNSSEC records.  The OK bit does not
   eliminate the need for large answers for DNSSEC capable clients.

2.1.1.  Message authentication or TSIG motivation

   TSIG [RFC2845] allows for the light weight authentication of DNS
   messages, but increases the size of the messages by at least 70
   octets.  DNSSEC specifies for computationally expensive message
   authentication SIG(0) using a standard public key signature.  As only
   one TSIG or SIG(0) can be attached to each DNS answer the size
   increase of message authentication is not significant, but may still
   lead to a truncation.

2.2.  IPv6 Motivations

   IPv6 addresses [RFC2874] are 128 bits and can be represented in the
   DNS by multiple A6 records, each consisting of a domain name and a
   bit field.  The domain name refers to an address prefix that may
   require additional A6 RRs to be included in the answer.  Answers
   where the queried name has multiple A6 addresses may overflow a 512-
   octet UDP packet size.

Gudmundsson                 Standards Track                     [Page 2]

[include full document text]