452 lines
15 KiB
Plaintext
452 lines
15 KiB
Plaintext
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
records have been requested via the DO bit [RFC3225] and relevant SIG
|
|
records are returned.
|
|
|
|
2.1. Setting of AD bit by recursive servers
|
|
|
|
Section 6.1 of RFC 2535 says:
|
|
|
|
"The AD bit MUST NOT be set on a response unless all of the RRs in
|
|
the answer and authority sections of the response are either
|
|
Authenticated or Insecure."
|
|
|
|
The replacement text reads:
|
|
|
|
"The AD bit MUST NOT be set on a response unless all of the RRsets in
|
|
the answer and authority sections of the response are Authenticated."
|
|
|
|
"The AD bit SHOULD be set if and only if all RRs in the answer
|
|
section and any relevant negative response RRs in the authority
|
|
section are Authenticated."
|
|
|
|
A recursive DNS server following this modified specification will
|
|
only set the AD bit when it has cryptographically verified the data
|
|
in the answer.
|
|
|
|
2.2. Setting of AD bit by authoritative servers
|
|
|
|
A primary server for a secure zone MAY have the policy of treating
|
|
authoritative secure zones as Authenticated. Secondary servers MAY
|
|
have the same policy, but SHOULD NOT consider zone data Authenticated
|
|
unless the zone was transferred securely and/or the data was
|
|
verified. An authoritative server MUST only set the AD bit for
|
|
authoritative answers from a secure zone if it has been explicitly
|
|
configured to do so. The default for this behavior SHOULD be off.
|
|
|
|
Note that having the AD bit clear on an authoritative answer is
|
|
normal and expected behavior.
|
|
|
|
2.2.1. Justification for setting AD bit w/o verifying data
|
|
|
|
The setting of the AD bit by authoritative servers affects only the
|
|
small set of resolvers that are configured to directly query and
|
|
trust authoritative servers. This only affects servers that function
|
|
as both recursive and authoritative. Iterative resolvers SHOULD
|
|
ignore the AD bit.
|
|
|
|
The cost of verifying all signatures on load by an authoritative
|
|
server can be high and increases the delay before it can begin
|
|
|
|
|
|
|
|
Wellington & Gudmundsson Standards Track [Page 3]
|
|
|
|
RFC 3655 Redefinition of DNS AD bit November 2003
|
|
|
|
|
|
answering queries. Verifying signatures at query time is also
|
|
expensive and could lead to resolvers timing out on many queries
|
|
after the server reloads zones.
|
|
|
|
Organizations requiring 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.
|
|
|
|
3. Interpretation of the AD bit
|
|
|
|
A response containing data marked Insecure in the answer or authority
|
|
section MUST never have the AD bit set. In this case, the resolver
|
|
SHOULD treat the data as Insecure whether or not SIG records are
|
|
present.
|
|
|
|
A resolver MUST NOT blindly trust the AD bit unless it communicates
|
|
with a recursive nameserver over a secure transport mechanism or
|
|
using a message authentication such as TSIG [RFC2845] or SIG(0)
|
|
[RFC2931] and is explicitly configured to trust this recursive name
|
|
server.
|
|
|
|
4. Applicability statement
|
|
|
|
The AD bit is intended to allow the transmission of the indication
|
|
that a resolver has verified the DNSSEC signatures accompanying the
|
|
records in the Answer and Authority section. The AD bit MUST only be
|
|
trusted when the end consumer of the DNS data has confidence that the
|
|
intermediary resolver setting the AD bit is trustworthy. This can
|
|
only be accomplished via an out of band mechanism such as:
|
|
|
|
- Fiat: An organization that can dictate whether it is OK to trust
|
|
certain DNS servers.
|
|
|
|
- Personal: Because of a personal relationship or the reputation of
|
|
a recursive nameserver operator, a DNS consumer can decide to
|
|
trust that recursive nameserver.
|
|
|
|
- Knowledge: If a recursive nameserver operator posts the configured
|
|
policy of a recursive nameserver, a consumer can decide that
|
|
recursive nameserver is trustworthy.
|
|
|
|
In the absence of one or more of these factors AD bit from a
|
|
recursive name server SHOULD NOT be trusted. For example, home users
|
|
frequently depend on their ISP to provide recursive DNS service; it
|
|
|
|
|
|
|
|
|
|
|
|
Wellington & Gudmundsson Standards Track [Page 4]
|
|
|
|
RFC 3655 Redefinition of DNS AD bit November 2003
|
|
|
|
|
|
is not advisable to trust these recursive nameservers. A
|
|
roaming/traveling host SHOULD not use recursive DNS servers offered
|
|
by DHCP when looking up information where security status matters.
|
|
|
|
In the latter two cases, the end consumer must also completely trust
|
|
the path to the trusted recursive name servers, or a secure transport
|
|
must be employed to protect the traffic.
|
|
|
|
When faced with a situation where there are no satisfactory recursive
|
|
nameservers available, running one locally is RECOMMENDED. This has
|
|
the advantage that it can be trusted, and the AD bit can still be
|
|
used to allow applications to use stub resolvers.
|
|
|
|
5. Security Considerations
|
|
|
|
This document redefines a bit in the DNS header. If a resolver
|
|
trusts the value of the AD bit, it must be sure that the responder is
|
|
using the updated definition, which is any DNS server/resolver
|
|
supporting the DO bit [RFC3225].
|
|
|
|
Authoritative servers can be explicitly configured to set the AD bit
|
|
on answers without doing cryptographic checks. This behavior MUST be
|
|
off by default. The only affected resolvers are those that directly
|
|
query and trust the authoritative server, and this functionality
|
|
SHOULD only be used on servers that act both as authoritative and
|
|
recursive name servers.
|
|
|
|
Resolvers (full or stub) that blindly trust the AD bit without
|
|
knowing the security policy of the server generating the answer can
|
|
not be considered security aware.
|
|
|
|
A resolver MUST NOT blindly trust the AD bit unless it communicates
|
|
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 recursive name server.
|
|
|
|
6. IANA Considerations
|
|
|
|
None.
|
|
|
|
7. Internationalization Considerations
|
|
|
|
None. This document does not change any textual data in any
|
|
protocol.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Wellington & Gudmundsson Standards Track [Page 5]
|
|
|
|
RFC 3655 Redefinition of DNS AD bit November 2003
|
|
|
|
|
|
8. Intellectual Property Rights Notice
|
|
|
|
The IETF takes no position regarding the validity or scope of any
|
|
intellectual property or other rights that might be claimed to
|
|
pertain to the implementation or use of the technology described in
|
|
this document or the extent to which any license under such rights
|
|
might or might not be available; neither does it represent that it
|
|
has made any effort to identify any such rights. Information on the
|
|
IETF's procedures with respect to rights in standards-track and
|
|
standards-related documentation can be found in BCP-11. Copies of
|
|
claims of rights made available for publication and any assurances of
|
|
licenses to be made available, or the result of an attempt made to
|
|
obtain a general license or permission for the use of such
|
|
proprietary rights by implementors or users of this specification can
|
|
be obtained from the IETF Secretariat.
|
|
|
|
The IETF invites any interested party to bring to its attention any
|
|
copyrights, patents or patent applications, or other proprietary
|
|
rights which may cover technology that may be required to practice
|
|
this standard. Please address the information to the IETF Executive
|
|
Director.
|
|
|
|
9. Acknowledgments
|
|
|
|
The following people have provided input on this document: Robert
|
|
Elz, Andreas Gustafsson, Bob Halley, Steven Jacob, Erik Nordmark,
|
|
Edward Lewis, Jakob Schlyter, Roy Arends, Ted Lindgreen.
|
|
|
|
10. Normative References
|
|
|
|
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
|
|
Specification", STD 13, RFC 1035, November 1987.
|
|
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|
|
|
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
|
|
2535, March 1999.
|
|
|
|
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B.
|
|
Wellington, "Secret Key Transaction Authentication for DNS
|
|
(TSIG)", RFC 2845, May 2000.
|
|
|
|
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
|
|
(SIG(0))", RFC 2931, September 2000.
|
|
|
|
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
|
|
3225, December 2001.
|
|
|
|
|
|
|
|
Wellington & Gudmundsson Standards Track [Page 6]
|
|
|
|
RFC 3655 Redefinition of DNS AD bit November 2003
|
|
|
|
|
|
11. Authors' Addresses
|
|
|
|
Brian Wellington
|
|
Nominum Inc.
|
|
2385 Bay Road
|
|
Redwood City, CA, 94063
|
|
USA
|
|
|
|
EMail: Brian.Wellington@nominum.com
|
|
|
|
|
|
Olafur Gudmundsson
|
|
3821 Village Park Drive
|
|
Chevy Chase, MD, 20815
|
|
USA
|
|
|
|
EMail: ogud@ogud.com
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Wellington & Gudmundsson Standards Track [Page 7]
|
|
|
|
RFC 3655 Redefinition of DNS AD bit November 2003
|
|
|
|
|
|
12. Full Copyright Statement
|
|
|
|
Copyright (C) The Internet Society (2003). All Rights Reserved.
|
|
|
|
This document and translations of it may be copied and furnished to
|
|
others, and derivative works that comment on or otherwise explain it
|
|
or assist in its implementation may be prepared, copied, published
|
|
and distributed, in whole or in part, without restriction of any
|
|
kind, provided that the above copyright notice and this paragraph are
|
|
included on all such copies and derivative works. However, this
|
|
document itself may not be modified in any way, such as by removing
|
|
the copyright notice or references to the Internet Society or other
|
|
Internet organizations, except as needed for the purpose of
|
|
developing Internet standards in which case the procedures for
|
|
copyrights defined in the Internet Standards process must be
|
|
followed, or as required to translate it into languages other than
|
|
English.
|
|
|
|
The limited permissions granted above are perpetual and will not be
|
|
revoked by the Internet Society or its successors or assignees.
|
|
|
|
This document and the information contained herein is provided on an
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
|
|
Acknowledgement
|
|
|
|
Funding for the RFC Editor function is currently provided by the
|
|
Internet Society.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Wellington & Gudmundsson Standards Track [Page 8]
|
|
|