Browse Prior Art Database

Indicating Resolver Support of DNSSEC (RFC3225)

IP.com Disclosure Number: IPCOM000006345D
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

In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification.

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

Network Working Group                                          D. Conrad

Request for Comments: 3225                                 Nominum, Inc.

Category: Standards Track                                  December 2001

                 Indicating Resolver Support of DNSSEC

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

   In order to deploy DNSSEC (Domain Name System Security Extensions)

   operationally, DNSSEC aware servers should only perform automatic

   inclusion of DNSSEC RRs when there is an explicit indication that the

   resolver can understand those RRs.  This document proposes the use of

   a bit in the EDNS0 header to provide that explicit indication and

   describes the necessary protocol changes to implement that

   notification.

1. Introduction

   DNSSEC [RFC2535] has been specified to provide data integrity and

   authentication to security aware resolvers and applications through

   the use of cryptographic digital signatures.  However, as DNSSEC is

   deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware

   servers.  In such situations, the DNSSEC-aware server (responding to

   a request for data in a signed zone) will respond with SIG, KEY,

   and/or NXT records.  For reasons described in the subsequent section,

   such responses can have significant negative operational impacts for

   the DNS infrastructure.

   This document discusses a method to avoid these negative impacts,

   namely DNSSEC-aware servers should only respond with SIG, KEY, and/or

   NXT RRs when there is an explicit indication from the resolver that

   it can understand those RRs.

   For the purposes of this document, "DNSSEC security RRs" are

   considered RRs of type SIG, KEY, or NXT.

Conrad                      Standards Track                     [Page 1]

RFC 3225         Indicating Resolver Support of DNSSEC     December 2001

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

2. Rationale

   Initially, as DNSSEC is deployed, the vast majority of queries will

   be from resolvers that are not DNSSEC aware and thus do not

   understand or support the DNSSEC security RRs.  When a query from

   such a resolver is received for a DNSSEC signed zone, the DNSSEC

   specification indicates the nameserver must respond with the

   appropriate DNSSEC security RRs.  As DNS UDP datagrams are limited to

   512 bytes [RFC1035], responses including DNSSEC security RRs have a

   high probability of resulting in a truncated response being returned

   and the resolver retrying the query using TCP.

   TCP DNS queries result in significant overhead due to connection

   setup and teardown.  Operationally, the impact of these TCP queries

   will likely be quite detrimental in terms of increased network

   traffic...