Skip to main content

Redefinition of DNS Authenticated Data (AD) bit
RFC 3655

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: Internet Architecture Board <>,
    RFC Editor <>, 
    dnsext mailing list <>, 
    dnsext chair <>
Subject: Protocol Action: 'Redefinition of DNS AD bit' to 
         Proposed Standard 

The IESG has approved the following document:

- 'Redefinition of DNS AD bit '
   <draft-ietf-dnsext-ad-is-secure-07.txt> as a Proposed Standard

This document is the product of the DNS Extensions Working Group. 

The IESG contact persons are Erik Nordmark and Mark Townsley.

A URL of this Internet-Draft is:

Ballot Text

Technical Summary
Based on implementation experience, the current definition of the AD
bit in the DNS header is not useful. This draft changes the
specification so that the AD bit is only set on answers where
signatures have been cryptographically verified or the server is
authoritative for the data and is allowed to set the bit by policy.
Working Group Summary
There was some dissent expressed by one person whether the AD bit 
carries any semantics which can not be inferred from the replies 
which the stub resolver receives.
Protocol Quality
The specification has been reviewed for the IESG by Erik Nordmark.

RFC-editor notes:
Please add the standard IPR section to the document.

Before the last paragraph in section 4 add this paragraph:

      In the latter two cases, the end consumer must also completely
      trust the network path to the trusted resolvers or a secure
      transport is employed to protect the traffic.

Add this paragraph to the end of section 2.2:

	Note that having the AD bit clear on an authoritative answer is
	normal and expected behavior.

The draft also has an odd "MUST" in section 2.2.1:
  Organisations that require that all DNS responses contain
  cryptographically verified data MUST separate the functions of
  authoritative and recursive servers, as authoritative servers are not
  required to validate local secure data.
This introduces a new concept "local secure data", w/o defining it.

Replace that paragraph with:
  Organisations which require that all DNS responses contain
  cryptographically verified data will need to separate the
  authoritative name server and signature verification functions, since
  name servers are not required to validate signatures of data for which
  they are authoritative.

Add this paragraph at the end of the security considerations section:
   A resolver MUST NOT blindly trust the AD bit unless it communicates
   with the full function resolver over a secure transport mechanism, such as IPsec, or
   using message authentication such as TSIG [RFC2845] or SIG(0)
   [RFC2931]. In addition, the resolver must have been explicitly configured to trust this resolver.

RFC Editor Note