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