datatracker.ietf.org
Sign in
Version 5.9.0, 2014-12-18
Report a bug

Indicating Resolver Support of DNSSEC
RFC 3225

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

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

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

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 (typically five packets for a single query/response instead
   of two), increased latency resulting from the additional round trip
   times, increased incidences of queries failing due to timeouts, and
   significantly increased load on nameservers.

   In addition, in preliminary and experimental deployment of DNSSEC,
   there have been reports of non-DNSSEC aware resolvers being unable to
   handle responses which contain DNSSEC security RRs, resulting in the
   resolver failing (in the worst case) or entire responses being
   ignored (in the better case).

   Given these operational implications, explicitly notifying the
   nameserver that the client is prepared to receive (if not understand)
   DNSSEC security RRs would be prudent.

   Client-side support of DNSSEC is assumed to be binary -- either the
   client is willing to receive all DNSSEC security RRs or it is not
   willing to accept any.  As such, a single bit is sufficient to
   indicate client-side DNSSEC support.  As effective use of DNSSEC
   implies the need of EDNS0 [RFC2671], bits in the "classic" (non-EDNS
   enhanced DNS header) are scarce, and there may be situations in which
   non-compliant caching or forwarding servers inappropriately copy data
   from classic headers as queries are passed on to authoritative
   servers, the use of a bit from the EDNS0 header is proposed.

[include full document text]