Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

DNSSEC and IPv6 A6 aware server/resolver message size requirements (RFC3226)

IP.com Disclosure Number: IPCOM000006346D
Original Publication Date: 2001-Dec-01
Included in the Prior Art Database: 2001-Dec-27
Document File: 7 page(s) / 12K

Publishing Venue

Internet Society Requests For Comment (RFCs)

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.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 28% of the total text.

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