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: 2019-Feb-13
Document File: 6 page(s) / 9K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

O. Gudmundsson: AUTHOR

Related Documents

10.17487/RFC3226: DOI

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. [STANDARDS-TRACK]

This text was extracted from a PDF 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...

Processing...
Loading...