datatracker.ietf.org
Sign in
Version 5.6.1.p1, 2014-07-16
Report a bug

Redefinition of DNS Authenticated Data (AD) bit
RFC 3655

Document type: RFC - Proposed Standard (November 2003)
Obsoleted by RFC 4033, RFC 4035, RFC 4034
Updates RFC 2535
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 3655 (Proposed Standard)
Responsible AD: Erik Nordmark
IESG Note: published as RFC 3655
Send notices to: <ogud@ogud.com>, <okolkman@ripe.net>

Network Working Group                                      B. Wellington
Request for Comments: 3655                                O. Gudmundsson
Updates: 2535                                              November 2003
Category: Standards Track

            Redefinition of DNS Authenticated Data (AD) bit

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 (2003).  All Rights Reserved.

Abstract

   This document alters the specification defined in RFC 2535.  Based on
   implementation experience, the Authenticated Data (AD) bit in the DNS
   header is not useful.  This document redefines the AD bit such that
   it is only set if all answers or records proving that no answers
   exist in the response has been cryptographically verified or
   otherwise meets the server's local security policy.

1.  Introduction

   Familiarity with the DNS system [RFC1035] and DNS security extensions
   [RFC2535] is helpful but not necessary.

   As specified in RFC 2535 (section 6.1), the AD (Authenticated Data)
   bit indicates in a response that all data included in the answer and
   authority sections of the response have been authenticated by the
   server according to the policies of that server.  This is not
   especially useful in practice, since a conformant server SHOULD never
   reply with data that failed its security policy.

   This document redefines the AD bit such that it is only set if all
   data in the response has been cryptographically verified or otherwise
   meets the server's local security policy.  Thus, neither a response
   containing properly delegated insecure data, nor a server configured
   without DNSSEC keys, will have the AD set.  As before, data that
   failed to verify will not be returned.  An application running on a
   host that has a trust relationship with the server performing the

Wellington & Gudmundsson    Standards Track                     [Page 1]
RFC 3655               Redefinition of DNS AD bit          November 2003

   recursive query can now use the value of the AD bit to determine
   whether the data is secure.

1.1.  Motivation

   A full DNSSEC capable resolver called directly from an application
   can return to the application the security status of the RRsets in
   the answer.  However, most applications use a limited stub resolver
   that relies on an external recursive name server which incorporates a
   full resolver.  The recursive nameserver can use the AD bit in a
   response to indicate the security status of the data in the answer,
   and the local resolver can pass this information to the application.
   The application in this context can be either a human using a DNS
   tool or a software application.

   The AD bit SHOULD be used by the local resolver if and only if it has
   been explicitly configured to trust the remote resolver.  The AD bit
   SHOULD be ignored when the recursive name server is not trusted.

   An alternate solution would be to embed a full DNSSEC resolver into
   every application, but this has several disadvantages.

   -  DNSSEC validation is both CPU and network intensive, and caching
      SHOULD be used whenever possible.

   -  DNSSEC requires non-trivial configuration - the root key must be
      configured, as well as keys for any "islands of security" that
      will exist until DNSSEC is fully deployed.  The number of
      configuration points should be minimized.

1.2.  Requirements

   The key words "MAY", "MAY NOT" "MUST", "MUST NOT", "SHOULD", "SHOULD
   NOT", "RECOMMENDED", in this document are to be interpreted as
   described in BCP 14, RFC 2119 [RFC2119].

1.3.  Updated documents and sections

   The definition of the AD bit in RFC 2535, Section 6.1, is changed.

2.  Setting of AD bit

   The presence of the CD (Checking Disabled) bit in a query does not
   affect the setting of the AD bit in the response.  If the CD bit is
   set, the server will not perform checking, but SHOULD still set the
   AD bit if the data has already been cryptographically verified or

Wellington & Gudmundsson    Standards Track                     [Page 2]
RFC 3655               Redefinition of DNS AD bit          November 2003

   complies with local policy.  The AD bit MUST only be set if DNSSEC

[include full document text]