Internet DRAFT - draft-gieben-resolver-application-interface
draft-gieben-resolver-application-interface
Network Working Group R. Gieben
Internet-Draft NLnet Labs
Expires: October 19, 2004 G. Guette
IRISA / INRIA
O. Courtay
ENST-Bretagne
April 20, 2004
DNSSEC Resolver Interface to Applications
draft-gieben-resolver-application-interface-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 19, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes an interface between a DNSSEC aware resolver
and an application. This interface will define which kind of
information a DNSSEC aware resolver is able to send back to an
application. The basic question we want to answer is: "What does an
application want to know from a secure aware resolver?".
In Section 4 we define an error bit array. The secure aware resolver
will set specific bits in the array. With the added information in
the error array, the application can have extra control on what to do
Gieben, et al. Expires October 19, 2004 [Page 1]
Internet-Draft DNSSEC Resolver Interface to Applications April 2004
with bogus data.
When something goes wrong during the secure resolving process the
application may also want to know where in the DNS tree this
happened. With a simple error array one can not convey this
information. A possibility might be to give the application the owner
name of the DNS node where the validation failed.
This document is written in the hope that it will lead to a
discussion within the IETF on the resolver-application
interaction(s).
Table of Contents
1. Introduction and Rational . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. What Causes Data to be Bogus? . . . . . . . . . . . . . . . . 4
4. Resolver Interface to Applications . . . . . . . . . . . . . . 5
5. What is Local Policy To an Application? . . . . . . . . . . . 6
6. Interface to the Resolver . . . . . . . . . . . . . . . . . . 7
7. Resolver Interface on The Network . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 7
9.2 Informative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
A. Document Details and Changes . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 9
Gieben, et al. Expires October 19, 2004 [Page 2]
Internet-Draft DNSSEC Resolver Interface to Applications April 2004
1. Introduction and Rational
The server side of DNSSEC is currently well understood. What is
lacking is a precise definition on how resolvers and applications
interact in a DNSSEC world.
This document intends to kick start a discussion about how a possible
interface between application and resolver might look like and if it
is desirable.
We are not going to talk about caching, nor are we detailing an
interface protocol for over the network, ie. no protocol
modifications are proposed in this document (yet). See Section 7 for
details.
With DNSSEC we can distinguish between verified, unsecured and bogus
data (See [1]). However, if data is bogus it could still be useful
depending on why it is bogus and what the intentions of the end-user
are.
For example, an end-user is browsing a site called
banking.example.com. This URL is considered bogus by the local
resolver. If the end-user just wants to browse the site the
bogus-ness could be considered harmless. If on the other hand the
end-user wants to engage in online banking it would be better to
postpone that. To make this a reality the browser should be able to
show the end-user a pop-up and explain what the problem is. For the
browser to do that it would have to know the exact reason on why the
data is bogus.
The current model (SERVFAIL when data is bogus) is not sufficient for
an application to make this decision. In essence the decision is
already made (SERVFAIL). Without some standard way of getting this
information to an application, different applications will follow
different paths to try to get this information somehow. This could
lead to the (undesirable) situation where every networked application
has its own secure resolver.
2. Definitions
[Editors Note: the abbreviations here are given to try to standardize
those as well in one swoop. If there is a lot of discussion about it,
the will be removed.]
o fully DNSSEC Aware Resolver (DAR):
Gieben, et al. Expires October 19, 2004 [Page 3]
Internet-Draft DNSSEC Resolver Interface to Applications April 2004
A resolver that is fully DNSSEC aware. It implements all DNSSEC
mechanism and is capable of querying the DNS (recursively). It
has no (permanent) cache.
o Application:
In this document an application is an entity that sits between
an end-user and the resolver.
o Cache:
An entity that stores Resource Records for the duration of
their TTL.
We could go as far to merge a resolver (DAR) and a cache and which
case you get a "fully DNSSEC Aware Caching Resolver", that would
yield DACR, which is unpronounceable, so may be DARC is better
(DNSSEC Aware Resolver and Cacher).
3. What Causes Data to be Bogus?
There are many ways in DNSSEC for data to become bogus. In this
section we classify the different reasons why a resource record set
(RR set) can become bogus.
Data in DNSSEC is considered bogus when there is no valid chain of
trust up to a trusted DNSKEY. As explained above, the exact reason
for data becoming bogus could be of importance to an application.
We can distinguish between the following causes: bogus due to an
attack, bogus due to mis-configuration, bogus due to a timing issue
or bogus due to local policy.
o Attacks
In the case of an attack it is important that a resolver
detects this (and reports it to the user). There are many
attacks possible. We list some of them below.
Some resource records are missing in the answer received by the
resolver, possibly because these records are spoofed away by an
attacker.
Introduction of extra records. An attacker can add wrong RRSIG
records. These records can be added in messages from secure
zones, but also in messages from otherwise unsecured zones.
Another avenue of attacks might be tricking the resolver into
believing it is resolving in the unsecure tree, while in fact
the tree is secured.
o Mis-configuration
[Editors Note: What kind of things can we expect here? Missing
KEY records....Important thing here: it that it would be nice
if we could distinguish between a misconfiguration and an
attack. If you know it is missing, it is an attack. Otherwise a
misconfiguration is also a possibility.]
Gieben, et al. Expires October 19, 2004 [Page 4]
Internet-Draft DNSSEC Resolver Interface to Applications April 2004
o Timing issue
When a RRset together with its RRSIG is validated by a resolver
the first thing checked is the RRSIG expiration and inception
time. If the current time does not fall in the interval set by
those two times a RRSIG is invalid and the data bogus. It could
be conceivable that RRSIG's older than a few minutes are still
useful for validation.
o Local Policy Decisions
Don't accept certain key sizes. Only accept some algorithms.
Etc. [Editors Note: Not accepting certain (i.e.) algorithms
will thus lead to bogus data, while the DNSSEC crypto may be
completely valid.]
o Others?
[Editors Note: are there more?]
4. Resolver Interface to Applications
To signal the resolving status to an application we propose to use an
array of bits. This error array will have specific bits set to 1
which correspond to specific errors. After a query multiple bits
maybe set to 1.
The bit array has a length of 32 bits. [Editors Note: If 32 bits is
too little we use 64.] The left most bit is numbered 0 and the right
most if numbered 31. The left most two bits of these array have a
slightly different meaning. Bit 0 will tell an application if the
entire answer is validated (1) or not (0). Bit 1 is used to signal if
the data was gathered with one or more (unsecure) DNS query (0) or
was done by utilizing DNSSEC (1). If a resolver has a trusted anchor
for the current lookup the bit must be set.
The definition of the bits is as follows: If the definition is true
the bit is set to 1, otherwise the bit is 0.
Gieben, et al. Expires October 19, 2004 [Page 5]
Internet-Draft DNSSEC Resolver Interface to Applications April 2004
Bit # | Definition Bit # | Definition
0 Unsecure answer 16 AD bit set
1 Validated answer 17 CD bit set
2 Indeterminate 18
3 Missing record 19
4 Delegation problem 20
5 Policy error 21
6 22
7 DS involved 23 Through secure channel
8 NSEC involved 24 Signature timing problem
9 NS involved 25 Bad algorithm
10 RRSIG involved 26 Key size not accepted
11 DNSKEY involved 27
12 28
13 29
14 30
15 31
There are 4 blocks defined in the array, these are: block 1 (bit 0 -
bit 5); general indication of any error. Block 2 (bit 7 - bit 11);
indicate which RRs are involved in the error. Block 3 (bit 16 - bit
17); what bits are set on the packet and block 4 (bit 23 - bit 26);
local policy disapproved the answer.
As said, bits 0 and 1 indicate the general failure mode. If bit 0 and
bit 1 are both set to 0 an error has occurred. If bit 2 is set, the
resolver could not determine the actual cause of the error.
When bit 0 and 1 are 0 the other bits in the array should now
indicate what the error is. If bit 3 is set, the meaning of the other
bits in the array is undefined.
Bits 6 up to 10 indicate which RR(s) are involved in the error. Bits
3,4 and 5 indicate what the error is. Bit 3 indicates some records
are missing, bit 4 tells the application there was a delegation error
and bit 5 says local policy was the culprit.
Bit 18 means that the response was obtained though a secure channel.
This means the resolver is configured to securely communicate with a
forwarder.
5. What is Local Policy To an Application?
Local policy is a set of rules which define which bits from the error
array can/should be overruled by the application.
Local policy defines all the rules that the application must respect,
and thus defines the behavior of the application when it receives
Gieben, et al. Expires October 19, 2004 [Page 6]
Internet-Draft DNSSEC Resolver Interface to Applications April 2004
bogus data or when the verification of the RRset generates an error.
6. Interface to the Resolver
In the same way as an application is able to overrule the error
array, the user or system administrator can overrule the resolver and
thereby influence all applications on a host.
This kind of behavior can best be summarized as: "Don't tell the
application X", or "Always tell the application X". Where 'X' is the
appropriate bit in the error array.
7. Resolver Interface on The Network
To send this feedback information over the network would require a
protocol extension. We, the authors, think such a extension does not
belong in this document. However, for the sake of symmetry such an
interface should be defined. Right now we only describe
resolver-application behavior on a single host.
8. Acknowledgments
The authors would like to thanks the following persons for their
contributions to this document (in no particular order): Jelte
Jansen, Scott Rose, Suresh Krishnaswamy.
9. References
9.1 Normative References
9.2 Informative References
[1] Arends, R., "Protocol Modifications for the DNS Security
Extensions", draft-ietf-dnsext-dnssec-protocol-05 (work in
progress), March 2003.
Authors' Addresses
Miek Gieben
NLnet Labs
Kruislaan 419
Amsterdam 1098 VA
NL
EMail: miek@nlnetlabs.nl
URI: http://www.nlnetlabs.nl
Gieben, et al. Expires October 19, 2004 [Page 7]
Internet-Draft DNSSEC Resolver Interface to Applications April 2004
Gilles Guette
IRISA / INRIA
Campus de Beaulieu
Rennes 35042
FR
EMail: gilles.guette@irisa.fr
URI: http://www.irisa.fr
Olivier Courtay
ENST-Bretagne
2, rue de la chataigneraie
Cesson Sevigne 35512
FR
EMail: olivier.courtay@enst-bretagne.fr
URI: http://www.enst-bretagne.fr
Appendix A. Document Details and Changes
Gieben, et al. Expires October 19, 2004 [Page 8]
Internet-Draft DNSSEC Resolver Interface to Applications April 2004
Intellectual Property Statement
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.
Full Copyright Statement
Copyright (C) The Internet Society (2004). 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
Gieben, et al. Expires October 19, 2004 [Page 9]
Internet-Draft DNSSEC Resolver Interface to Applications April 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gieben, et al. Expires October 19, 2004 [Page 10]
