DNS Extensions S. Krishnaswamy
Internet-Draft A. Hayatnagarkar
Expires: November 28, 2008 SPARTA, Inc.
May 27, 2008
DNSSEC Validator API
draft-hayatnagarkar-dnsext-validator-api-06
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 November 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
The DNS Security Extensions (DNSSEC) provide origin authentication
and integrity of DNS data. However, the current resolver Application
Programming Interface (API) does not specify how a validating stub
resolver should communicate detailed results of DNSSEC processing
back to the application. This document describes an API between
applications and a validating stub resolver that allows applications
to control the DNSSEC validation process and obtain results of DNSSEC
processing.
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 1]
Internet-Draft DNSSEC Validator API May 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. High-level DNSSEC Validator API . . . . . . . . . . . . . . . 4
3.1. val_gethostbyname, val_gethostbyaddr . . . . . . . . . . . 5
3.2. val_getaddrinfo, val_getnameinfo, val_freeaddrinfo . . . . 7
3.3. val_res_query . . . . . . . . . . . . . . . . . . . . . . 9
3.4. val_get_rrset . . . . . . . . . . . . . . . . . . . . . . 10
4. Low-level DNSSEC Validator API . . . . . . . . . . . . . . . . 11
4.1. val_resolve_and_check, val_free_result_chain . . . . . . . 12
4.2. ns_name_pton and ns_name_ntop . . . . . . . . . . . . . . 15
4.3. Authentication Chain Status Codes and p_ac_status() . . . 16
5. DNSSEC Validator Context API . . . . . . . . . . . . . . . . . 19
5.1. val_create_context, val_free_context . . . . . . . . . . . 19
5.2. val_add_valpolicy, val_remove_valpolicy . . . . . . . . . 20
6. Function Return Codes and p_val_err() . . . . . . . . . . . . 21
7. Evaluating Response Validity . . . . . . . . . . . . . . . . . 22
7.1. DNSSEC Validation Status Codes and p_val_status() . . . . 22
7.2. High-Level Routines for Evaluating Validity . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Configuring DNSSEC Validator Policy . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 30
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 2]
Internet-Draft DNSSEC Validator API May 2008
1. Introduction
The DNS Security Extensions (RFC 4033 [7], RFC 4034 [3], RFC 4035
[4]) enable DNS resolvers to test the origin authenticity and
integrity of data returned by the DNS. A DNSSEC validator, or more
formally, a validating stub resolver, is a piece of software that
performs these tests by constructing an authentication chain [7] from
a locally configured DNSSEC trust anchor [7] to a cryptographic
signature that covers the DNS information in question. This document
presents an API between an application and a DNSSEC validator, which
enables applications to control the DNSSEC validation process and
enables applications to obtain detailed DNSSEC validation results
upon which to base program behavior.
The API can be broadly divided into three groups: the high-Level
DNSSEC validator API, the low-Level DNSSEC validator API and the
DNSSEC validator-context API. Section 3, Section 4, and Section 5
describe these interfaces in greater detail.
The high-level DNSSEC validator API is designed for ease of use and
mirrors existing DNS-related functions. This API is best suited for
existing applications that use legacy resolver functions such as
gethostbyname() and getaddrinfo() [1] and have no requirement for
detailed DNSSEC validation status information.
The low-level DNSSEC validator API enables applications to examine
the DNSSEC validation details for each element of the DNSSEC
authentication chain
The DNSSEC validator-context API enables applications to control the
DNSSEC policies that are used for validating DNS responses.
The range of functions provided in this API support different classes
of applications, ranging from those that are only interested in basic
DNSSEC results such as "validated" or "not-validated", to more
sophisticated applications that can look for specific errors in an
authentication chain as a sign of some abnormality or attack.
2. Terminology
Some of the terms used in this specification are defined below:
DNS Legacy Functions: functions, such as gethostbyname() and
getaddrinfo(), that are not capable of returning DNSSEC validation
status codes for DNS responses.
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 3]
Internet-Draft DNSSEC Validator API May 2008
DNSSEC Validator Policy: a set of configuration parameters for the
DNSSEC validator, which can influence the eventual outcome of the
DNSSEC validation process.
DNSSEC Validator Policy Attribute: one of the DNSSEC validator's
configurable parameters that, when combined with other policy
attributes, forms the validator policy.
DNSSEC Validator Context: the application's run-time handle to the
DNSSEC validator policy.
Active or Effective DNSSEC Validator Policy: the DNSSEC validator
policy associated with a DNSSEC validator context.
Default DNSSEC Validator Policy: the DNSSEC validator policy that is
associated with a DNSSEC validator context in the absence of any
application preferences during context creation.
3. High-level DNSSEC Validator API
The high-level DNSSEC validator API defines DNSSEC-aware substitutes
for commonly used DNS legacy functions. It provides an easy path for
applications already using DNS legacy functions to transition towards
becoming DNSSEC-aware. The high-level API also defines the
val_get_rrset() function, which enables applications to obtain data
for an arbitrary DNS name, class and type, and inspect the
corresponding DNSSEC validation status values.
A number of resolver API functions exist; however, some of these
functions (such as gethostbyname_r and gethostbyname2) are only
available on a subset of Operating Systems and are not part of any
official standard. Also, some functions are defined only as minor
extensions of other well-known resolver API functions. For example,
gethostbyname2 differs from gethostbyname_r only by virue of having
the extra argument to explictly specify the address family. Further,
some functions differ from others only by virtue of being able to
support a re-entrant and thread-safe implementation. Instead of
providing an exhaustive list of DNSSEC-capable replacement functions
for all known resolver function calls, the high-level DNSSEC
validator API in this document only describes DNSSEC extensions for
the canonical set of function calls specified in [1].
The ctx parameter in the functions described in this API points to a
DNSSEC validator context object (Section 5). Applications MUST
either supply a reference to a valid DNSSEC validator context object
created using the functions specified in Section 5 or supply a NULL
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 4]
Internet-Draft DNSSEC Validator API May 2008
value for this parameter. Libraries that implement the DNSSEC
Validator API MUST internally use a default DNSSEC validator context
when the application supplies a NULL value for ctx.
3.1. val_gethostbyname, val_gethostbyaddr
#include <validator.h>
struct hostent *val_gethostbyname( const val_context_t *ctx,
const char *name,
val_status_t *val_status );
struct hostent *val_gethostbyaddr( const val_context_t *ctx,
const char *addr,
int len,
int type,
val_status_t *val_status );
The val_gethostbyname() and val_gethostbyaddr() functions are DNSSEC-
aware versions of the gethostbyname() and gethostbyaddr() DNS legacy
functions. The new functions have an additional parameter,
val_status, which enables applications to check the DNSSEC validation
status codes for the address-to-name and name-to-address
translations. The other arguments to these functions have identical
semantics to the corresponding DNS legacy functions as described in
[1]. The val_gethostbyname() and val_gethostbyaddr() functions
SHOULD only be used when retrofitting DNSSEC in existing applications
that use the gethostbyname() and gethostbyaddr() functions. For new
applications that need to perform these translations, the functions
described in Section 3.2 and Section 3.4 SHOULD be used instead.
The DNSSEC validation status is returned in the val_status parameter.
When evaluating the validity of a DNS response, applications SHOULD
use the functions described in Section 7.2 instead of directly
inspecting the DNSSEC validation status code returned in val_status.
The status code returned in val_status is determined by the following
rules.
o A DNSSEC validation status of VAL_LOCAL_ANSWER SHOULD be returned
if the complete answer is returned from a local configuration
store (for example, /etc/hosts or its equivalent) without any
DNSSEC validation being performed. However, if local DNSSEC
validator policy defines locally obtained answers to be
trustworthy, a DNSSEC validation status of VAL_TRUSTED_ANSWER
SHOULD be returned instead.
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 5]
Internet-Draft DNSSEC Validator API May 2008
o A DNSSEC validation status of VAL_VALIDATED_ANSWER MUST be
returned if all the address and canonical name(s) within the
hostent structure, if present, are validated successfully.
o A DNSSEC validation status of VAL_TRUSTED_ANSWER MUST be returned
if at least one of the address and canonical name(s) within the
hostent structure, if present, is not validated by the DNSSEC
validation process, but all answers returned are still considered
trustworthy (Section 5) by way of the configured local DNSSEC
validator policy.
o A DNSSEC validation status of VAL_UNTRUSTED_ANSWER MUST be
returned if at least one answer in the set of address and
canonical name(s) within the hostent structure is neither
validated through the DNSSEC validation process nor considered to
be trusted according to the configured local DNSSEC validator
policy.
o A DNSSEC validation status of VAL_NONEXISTENT_NAME or
VAL_NONEXISTENT_TYPE MUST be returned if the DNSSEC validation
process is able to prove non-existence for the name or type being
queried for. A DNSSEC validation status of
VAL_NONEXISTENT_NAME_NOCHAIN or VAL_NONEXISTENT_TYPE_NOCHAIN MUST
be returned if a DNS response with an RCODE reflecting type or
name non-existence is returned, and local DNSSEC validator policy
is configured to treat such answers as trustworthy. If the
previous two conditions for non-existence are not satisfied,
val_status MUST be set to VAL_UNTRUSTED_ANSWER.
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 6]
Internet-Draft DNSSEC Validator API May 2008
3.2. val_getaddrinfo, val_getnameinfo, val_freeaddrinfo
#include <validator.h>
int val_getaddrinfo( const val_context_t *ctx,
const char *nodename,
const char *servname,
const struct addrinfo *hints,
struct addrinfo **res ,
val_status_t *val_status);
int val_getnameinfo( const val_context_t *ctx,
const struct sockaddr *sa,
socklen_t salen,
char *host,
size_t hostlen,
char *serv,
size_t servlen,
int flags,
val_status_t *val_status );
These functions are DNSSEC-aware versions of the getaddrinfo() and
getnameinfo() legacy DNS functions ([2]) respectively. The
val_getaddrinfo() function returns the address and service
information for the specified domain name and service. The
val_getnameinfo() function performs an address-to-name translation in
a protocol independent manner.
The results from the val_getaddrinfo() function is returned in the
res parameter. The value of res MUST point to a valid addrinfo
structure ([2]) on success or NULL in case of error. Any library
that implements the val_getaddrinfo() function MUST internally
allocate sufficient memory to hold the linked list pointed to by res.
The caller MUST release this memory after use by invoking the
freeaddrinfo() function ([2]).
The DNSSEC validation status is returned in the val_status parameter.
For val_getaddrinfo(), this MUST represent the effective DNSSEC
validation status code for all answers returned in the addrinfo
linked list. When evaluating the validity of a DNS response,
pplications SHOULD use the functions described in Section 7.2 instead
of directly inspecting the DNSSEC validation status code returned in
val_status. The syntax and semantics of other parameters in
val_getaddrinfo() and val_getnameinfo() are identical to those
specified for getaddrinfo() and getnameinfo() in [2].
The status code returned in val_status is determined by the following
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 7]
Internet-Draft DNSSEC Validator API May 2008
rules.
o A DNSSEC validation status of VAL_LOCAL_ANSWER SHOULD be returned
in val_status if the complete answer is returned from a local
configuration store (for example, /etc/hosts or its equivalent)
without any DNSSEC validation being performed. However, if local
DNSSEC validator policy defines locally obtained answers to be
trustworthy, a DNSSEC validation status of VAL_TRUSTED_ANSWER
SHOULD be returned instead.
o For val_getnameinfo(), a DNSSEC validation status of
VAL_VALIDATED_ANSWER or VAL_TRUSTED_ANSWER MUST be returned in
val_status if the returned response for the hostname is validated
by the DNSSEC process or is considered to be trustworthy through
the local DNSSEC validator policy respectively.
o For val_getaddrinfo(), a DNSSEC validation status of
VAL_VALIDATED_ANSWER MUST be returned in val_status if all address
and canonical name(s) within the given addrinfo structure, if
present, are validated through the DNSSEC process.
o For val_getaddrinfo(), a DNSSEC validation status of
VAL_TRUSTED_ANSWER MUST be returned in val_status if at least one
of the address and canonical name(s) within the given addrinfo
structure, if present, is not validated by the DNSSEC validation
process, but all answers returned are still considered to be
trustworthy through the local DNSSEC validator policy (Section 5).
o A DNSSEC validation status of VAL_UNTRUSTED_ANSWER MUST be
returned if at least one answer in the set of address and
canonical name(s) within the addrinfo structure is neither
validated through the DNSSEC process nor considered to be
trustworthy according to the local DNSSEC validator policy.
o A DNSSEC validation status of VAL_NONEXISTENT_NAME or
VAL_NONEXISTENT_TYPE MUST be returned in val_status if the DNSSEC
validation process is able to prove non-existence for the name or
type being queried for. A DNSSEC validation status of
VAL_NONEXISTENT_NAME_NOCHAIN or VAL_NONEXISTENT_TYPE_NOCHAIN MUST
be returned if a DNS response with an RCODE reflecting type or
name non-existence is returned, and local DNSSEC validator policy
is configured to treat such answers as trustworthy (Section 5).
If the previous two conditions for non-existence are not
satisfied, val_status MUST be set to VAL_UNTRUSTED_ANSWER.
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 8]
Internet-Draft DNSSEC Validator API May 2008
3.3. val_res_query
#include <validator.h>
int val_res_query(const val_context_t *ctx,
const char *domain_name,
int class,
int type,
u_char *answer,
int anslen,
val_status_t *val_status);
The val_res_query() function is a DNSSEC-aware replacement for the
res_query() function (currently not documented in any standard
reference). The val_res_query() function queries the DNS for the
data associated with the given domain name, class and type, and
returns the result as a DNS-style response.
The val_res_query() function returns the actual size of the response
packet on success and -1 on failure. On success, the response from
the DNS MUST be copied to the user-allocated buffer in answer and
MUST NOT exceed the buffer size specified in anslen. The caller MUST
check that the returned packet size is not greater than the length of
the buffer provided in anslen. If the returned size is greater, the
caller SHOULD allocate a larger buffer in answer and call
val_res_query() again.
The DNSSEC validation status is returned in the val_status parameter.
When evaluating the validity of a DNS response, applications SHOULD
use the functions described in Section 7.2 instead of directly
inspecting the DNSSEC validation status code returned in val_status.
The validation status MUST correspond to the combined DNSSEC
validation status code for all resource record sets returned in the
response, and is determined by the following rules.
o A DNSSEC validation status of VAL_VALIDATED_ANSWER MUST be
returned if all resource record sets returned in the answer are
validated by the DNSSEC validation process.
o A DNSSEC validation status of VAL_TRUSTED_ANSWER MUST be returned
if at least one resource record set returned in the answer is not
validated by the DNSSEC validation process, but all resource
record sets are still considered to be trustworthy according to
the configured local DNSSEC validator policy (Section 5).
o A DNSSEC validation status of VAL_UNTRUSTED_ANSWER MUST be
returned if at least one resource record set in the answer is
neither validated through the DNSSEC validation process nor
considered to be trustworthy according to the local DNSSEC
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 9]
Internet-Draft DNSSEC Validator API May 2008
validator policy.
o A DNSSEC validation status of VAL_NONEXISTENT_NAME or
VAL_NONEXISTENT_TYPE MUST be returned if the DNSSEC validation
process is able to prove non-existence for the name or type being
queried for. A DNSSEC validation status of
VAL_NONEXISTENT_NAME_NOCHAIN or VAL_NONEXISTENT_TYPE_NOCHAIN MUST
be returned if a DNS response with an RCODE reflecting type or
name non-existence is returned, and local DNSSEC validator policy
is configured to treat such answers as trustworthy. If the
previous two conditions for non-existence are not satisfied,
val_status MUST be set to VAL_UNTRUSTED_ANSWER.
3.4. val_get_rrset
#include <validator.h>
int val_get_rrset(val_context_t *ctx,
const char *name,
u_int16_t class,
u_int16_t type,
u_int32_t flags,
struct val_answer_chain **answers);
void val_free_answer_chain(struct val_answer_chain *answers);
The val_get_rrset() function queries the DNS for the data associated
with the given domain name, class and type. The flags argument is
currently unused and SHOULD be set to 0.
val_get_rrset() returns 0 on success and an error code from Section 6
on failure. val_get_rrset() returns its results in the
val_answer_chain structure. Memory for the val_answer_chain
structure MUST be allocated internally by the function. The user
MUST release this memory after use using the val_free_answer_chain()
function.
The val_answer_chain structure is defined below.
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 10]
Internet-Draft DNSSEC Validator API May 2008
struct val_answer_chain {
val_status_t val_ans_status;
char *val_ans_name;
u_int16_t val_ans_class;
u_int16_t val_ans_type;
struct rr_rec *val_ans;
struct val_answer_chain *val_ans_next;
};
struct rr_rec {
u_int16_t rr_length;
u_int8_t *rr_data;
struct rr_rec *rr_next;
};
val_ans_name MUST contain the DNS name of the actual resource record
set returned. This value may differ from the value passed as the
argument to val_get_rrset() if the resource record is returned after
following a CNAME ([5]) or DNAME ([6]) alias. val_ans_class and
val_ans_type MUST contain the actual class and type for the returned
resource record. These values may differ from the values passed as
arguments to val_get_rrset() if the query type or class has the value
255 (ANY). The resource record sets are returned as a linked list of
rr_rec structures, with each element containing the rr_length and
rr_data tuple for a resource record in the resource record set.
The DNSSEC validation status code is returned in the val_ans_status
field. This value MUST correspond to the consolidated validation
status value for a resource record set, based on the individual
status codes for all components in an authentication chain. Possible
codes for val_ans_status are listed in Section 7.1. When evaluating
the validity of a DNS response, applications SHOULD use the functions
described in Section 7.2 instead of directly inspecting the DNSSEC
validation status code returned in val_ans_status.
4. Low-level DNSSEC Validator API
The low-level DNSSEC validator API provides applications with greater
control and visibility into the DNSSEC validation process. The
functions and data structures defined in the low-level DNSSEC
validator API are summarized below.
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 11]
Internet-Draft DNSSEC Validator API May 2008
4.1. val_resolve_and_check, val_free_result_chain
#include <validator.h>
int val_resolve_and_check( const val_context_t *ctx,
u_char *domain_name,
const u_int16_t class,
const u_int16_t type,
const u_int32_t flags,
struct val_result_chain **results);
void val_free_result_chain( struct val_result_chain *results);
The val_resolve_and_check() function queries the DNS for the
<domain_name, class, type> tuple and then performs the DNSSEC
validation operation for the responses received.
The flags argument specifies a list of options to the validation
process, logically OR'd to each other. Only one flag is currently
defined:
#define VAL_QUERY_NO_AC_DETAIL 0x00000001
If this flag is specified, details of the authentication chain SHOULD
NOT be returned in the returned results.
The domain name specified in domain_name MUST be in the DNS wire
format [5]. Names can be converted from a string representation [5]
to the DNS wire format and vice-versa using the ns_name_pton() and
ns_name_ntop() functions respectively, as described in Section 4.2.
val_resolve_and_check() returns 0 on success and an error code from
Section 6 on failure. Answers to the query is returned in results,
which is a linked-list of val_result_chain structures as defined
below. The memory for results MUST be allocated by
val_resolve_and_check(). Applications MUST release the memory
allocated in results after use using the val_free_result_chain()
function.
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 12]
Internet-Draft DNSSEC Validator API May 2008
#define MAX_PROOFS 4
struct val_result_chain {
val_status_t val_rc_status;
u_int8_t *val_rc_alias;
struct val_rrset_rec *val_rc_rrset;
struct val_authentication_chain *val_rc_answer;
int val_rc_proof_count;
struct val_authentication_chain *val_rc_proofs[MAX_PROOFS];
struct val_result_chain *val_rc_next;
};
Each element in the val_rc_answer linked-list MUST point to a
distinct resource record set returned in the answer section along
with any associated proofs of non-existence in val_rc_proofs.
val_rc_proof_count MUST be set to the number of proof elements that
are available. Multiple resource record sets can be returned in a
response when the query is for the type code of 255 (ANY) or 46
(RRSIG). If val_rc_answer is not NULL, val_rc_rrset MUST point to
the val_rrset_rec structure within the first element of the
authentication chain pointed to by val_rc_answer. For all
val_result_chain elements that represent a name alias, val_rc_alias
MUST point to the target name referenced by that alias. The
val_rc_next field enables an application to iterate through the list
of all results returned by the DNSSEC validator.
The DNSSEC validation status code is returned in the val_rc_status
field. This value MUST correspond to the consolidated validation
status value for a resource record set, based on the individual
status codes for all components in an authentication chain. Possible
codes for val_rc_status are listed in Section 7.1. When evaluating
the validity of a DNS response, applications SHOULD use the functions
described in Section 7.2 instead of directly inspecting the DNSSEC
validation status code returned in val_rc_status.
The resource record sets for answers and proofs of non-existence are
returned in val_rc_answer and val_rc_proofs. Their values MUST point
to NULL if the VAL_QUERY_NO_AC_DETAIL flag is specified in the flags
argument for val_resolve_and_check(). The val_authentication_chain
structure represents another linked-list whose elements comprise the
DNSSEC authentication chain for an answer or proof of non-existence
resource record set, and is further described below.
struct val_authentication_chain {
val_astatus_t val_ac_status;
struct val_rrset_rec *val_ac_rrset;
struct val_authentication_chain *val_ac_trust;
};
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 13]
Internet-Draft DNSSEC Validator API May 2008
The val_ac_status field contains the DNSSEC validation status for the
specified resource record set. Possible codes for this field are
defined in Section 4.3. The p_ac_status() function defined in
Section 4.3 enables an application to translate this code into a more
user-friendly string representation. The val_ac_trust field points
to the next element in the authentication chain proceeding from the
signed record towards a DNSSEC trust anchor. For an element with
type DNSKEY, the next element MUST correspond to a DS record in the
parent zone and for a DS record the next element MUST correspond to
the DNSKEY in the same zone as the DS record. The value of
val_ac_trust MUST be set to NULL when the current element in the
linked list points to a valid DNSSEC trust anchor or when an error
condition is encountered. The validation status code stored in the
val_ac_status field can be used to differentiate between these two
cases.
The val_ac_rrset field in the val_authentication_chain structure
points to a val_rrset_rec structure, which holds the actual resource
record set fields ([5]) as described below.
struct val_rrset_rec {
u_int8_t *val_msg_header;
u_int16_t val_msg_headerlen;
u_int8_t *val_rrset_name;
u_int16_t val_rrset_class;
u_int16_t val_rrset_type;
u_int32_t val_rrset_ttl;
u_int8_t val_rrset_section;
struct sockaddr *val_rrset_server;
struct val_rr_rec *val_rrset_data;
struct val_rr_rec *val_rrset_sig;
};
The information stored in the val_rrset_rec structure includes the
DNS response header in the val_msg_header field with length given by
val_msg_headerlen, and the DNS response "envelope" comprising of the
name, class, type and time-to-live tuple in the val_rrset_name,
val_rrset_class, val_rrset_type and val_rrset_ttl fields
respectively. val_rrset_name MUST be stored in the DNS wire format.
The name server from where these resource record sets are received is
stored in the sockaddr data structure ([1]) pointed to by the
val_rrset_server field. The section where the resource record set
appeared in the DNS response is saved in the val_rrset_section field
within the val_rrset_rec structure, and MUST contain one of the
following values:
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 14]
Internet-Draft DNSSEC Validator API May 2008
#define VAL_FROM_ANSWER 1 /* if the resource record set was present
in the answer section of the DNS response. */
#define VAL_FROM_AUTHORITY 2 /* if the resource record set was
present in the authority section of the DNS response. */
#define VAL_FROM_ADDITIONAL 3 /* if the resource record set was
present in the additional section of the DNS response. */
The data returned for the resource record set MUST be queued to
val_rrset_data. Any associated RRSIGs MUST be queued to
val_rrset_sig. Both of these variables point to lists of struct
val_rr_rec elements, which specify the resource record data and the
DNSSEC validation status for each resource-record within the resource
record set as defined below.
struct val_rr_rec {
u_int16_t rr_rdata_length;
u_int8_t *rr_rdata;
struct val_rr_rec *rr_next;
val_astatus rr_status;
};
The rr_status member in val_rr_rec is only relevant for the
signatures present in val_rrset_sig or when val_rrset_data points to
DNSKEY or DS resource records. This field takes on a subset of all
status codes possible for val_astatus_t and is further described in
Section 4.3.
4.2. ns_name_pton and ns_name_ntop
These functions are helper functions that assist in translating
domain names from a string representation to the DNS wire format and
vice-versa.
int ns_name_pton(const char *src,
u_char *dst,
int dstsize);
int ns_name_ntop(const u_char *src,
char *dst,
int dstsize);
src contains the data to be converted and dst contains the converted
value. dstsize MUST be large enough to hold the converted value. The
ns_name_pton() and ns_name_ntop() functions return the number of
bytes written to dst on success or -1 on failure.
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 15]
Internet-Draft DNSSEC Validator API May 2008
4.3. Authentication Chain Status Codes and p_ac_status()
The status code stored in the val_ac_status member of the
val_authentication_chain structure can be used for determining the
DNSSEC validity of the resource record and the reason for
verification failure, if any. val_ac_status can contain one of the
following codes:
VAL_AC_UNSET: DNSSEC validation for the given resource record set
could not be attempted due to an error condition observed
elsewhere in the authentication chain.
VAL_AC_IGNORE_VALIDATION: DNSSEC validation for the given resource
record set was ignored on the basis of some configured DNSSEC
validator policy.
VAL_AC_TRUSTED_ZONE: The resource record set belonged to a zone that
the DNSSEC validator considered to be trusted, with no further
DNSSEC validation being deemed necessary.
VAL_AC_UNTRUSTED_ZONE: The resource record set belonged to a zone
that the DNSSEC validator considered to be un-trusted, with no
further DNSSEC validation being deemed necessary.
VAL_AC_PROVABLY_INSECURE: The resource record set belonged to a zone
for which the DS record was provably absent.
VAL_AC_BARE_RRSIG: The resource record set contained only RRSIGs (in
response to a query of type RRSIG). RRSIGs contain the
cryptographic signatures for other DNS data and cannot themselves
be validated.
VAL_AC_NO_TRUST_ANCHOR: No DNSSEC trust anchor was configured at or
above the level of the zone for the given resource record set,
therefore no validation could be performed.
VAL_AC_TRUST: At least one of the signatures covering the given
resource record set was directly verified using a key that was
configured as a DNSSEC trust anchor.
VAL_AC_RRSIG_MISSING: RRSIG data for the given resource record set
could not be located.
VAL_AC_DNSKEY_MISSING: The DNSKEY data that generated signatures for
the given resource record set could not be located.
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 16]
Internet-Draft DNSSEC Validator API May 2008
VAL_AC_DS_MISSING: The DS data for the DNSKEY resource record set in
question could not be located.
VAL_AC_DATA_MISSING: The returned resource record set was empty.
VAL_AC_DNS_ERROR: A DNS error was encountered during the query
resolution process.
VAL_AC_NOT_VERIFIED: None of the RRSIGs covering the given resource
record set could be verified.
VAL_AC_VERIFIED: At least one RRSIG covering the resource record set
verified successfully.
For each signature val_rr_rec member within an authentication chain
pointed to by val_ac_rrset, the DNSSEC validation status stored in
the variable rr_status can contain one of the following codes:
VAL_AC_RRSIG_VERIFIED: the RRSIG verified successfully.
VAL_AC_WCARD_VERIFIED: the RRSIG covering a resource record proved
that the record was wildcard expanded.
VAL_AC_RRSIG_VERIFIED_SKEW: the RRSIG verified successfully only
after clock skew was taken into consideration.
VAL_AC_WCARD_VERIFIED_SKEW: the RRSIG covering a resource record
proved that the record was wildcard expanded, but only after clock
skew was taken into consideration.
VAL_AC_WRONG_LABEL_COUNT: the number of labels on the signature was
greater than the count given in the RRSIG resource record data.
VAL_AC_INVALID_RRSIG: the RRSIG could not be parsed.
VAL_AC_RRSIG_NOTYETACTIVE: the RRSIG's inception time was in the
future.
VAL_AC_RRSIG_EXPIRED: the RRSIG's expiration time was in the past.
VAL_AC_ALGORITHM_NOT_SUPPORTED: the RRSIG algorithm was not
supported.
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 17]
Internet-Draft DNSSEC Validator API May 2008
VAL_AC_RRSIG_VERIFY_FAILED: the RRSIG could not be verified.
VAL_AC_RRSIG_ALGORITHM_MISMATCH: the keytag referenced in the RRSIG
matched a DNSKEY but the algorithms were different.
VAL_AC_DNSKEY_NOMATCH: the DNSKEY that created the given signature
could not be found in the zone DNSKEY resource record set.
For each val_rr_rec member of type DNSKEY (or DS where indicated)
within an authentication chain structure pointed to by val_ac_rrset,
the DNSSEC validation status stored in the variable rr_status can
contain one of the following codes:
VAL_AC_TRUST_POINT: the given DNSKEY or DS record was configured as
a DNSSEC trust anchor.
VAL_AC_SIGNING_KEY: the given DNSKEY was used for generating an
RRSIG for a resource record in the authentication chain.
VAL_AC_VERIFIED_LINK: the given DNSKEY or DS resource record
provided the link in the authentication chain from a DNSSEC trust
anchor to the signed record.
VAL_AC_UNKNOWN_ALGORITHM_LINK: the DNSKEY chained up to a DS record
but the DNSKEY algorithm was unknown.
VAL_AC_UNKNOWN_DNSKEY_PROTOCOL: the DNSKEY protocol number was
unknown.
VAL_AC_ALGORITHM_NOT_SUPPORTED: the DNSKEY or DS algorithm was not
supported.
VAL_AC_DS_NOMATCH: the given DNSKEY did not chain up to any DS
record in the parent zone.
VAL_AC_INVALID_KEY: the given DNSKEY was invalid.
The numerical values for the codes listed above are implementation-
specific. The DNSSEC validation status code stored in struct
val_authentication_chain can be converted to a string representation
using the p_ac_status() function.
#include <validator.h>
char *p_ac_status(val_astatus_t status);
The value returned SHOULD be the string conversion for the
corresponding val_astatus_t identifier. For example,
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 18]
Internet-Draft DNSSEC Validator API May 2008
p_ac_status(VAL_AC_VERIFIED) SHOULD return "VAL_AC_VERIFIED".
5. DNSSEC Validator Context API
DNSSEC validator policy can be used to influence the DNSSEC
validation outcome. Examples of DNSSEC validator policy include
DNSSEC trust anchors for different zones and acceptable clock-skew
values for checking inception and expiration times on signatures from
different zones. DNSSEC validator policy MAY be configured
differently for different applications and operating scenarios.
DNSSEC validator policy is stored in the local system configuration
(for example, the configuration file /etc/dnsval.conf). Policies are
identified by simple text strings called labels, which MUST be unique
within the system configuration. As an example, "browser" could be
used as the label that defines the DNSSEC validator policy for all
web-browsers in a system. A label value of ":" for a DNSSEC
validator policy in the system configuration identifies the default
DNSSEC validator policy. The label for the validation policy that is
to be used for an application MAY be supplied during application-
startup through the environment variable, VAL_CONTEXT_LABEL.
The ":" DNSSEC policy label, as with other DNSSEC policy labels in
the system configuration, MUST be unique within the system
configuration. Furthermore, the ':' character MUST only be present
in the default DNSSEC validator policy label. The system
configuration MUST flag an error if some other DNSSEC policy label
contains the ':' character.
DNSSEC validator policy definitions in the system configuration are
implementation-specific. A possible definition is described in
Appendix A.
5.1. val_create_context, val_free_context
#include <validator.h>
int val_create_context( const char *scope,
val_context_t **newcontext );
void val_free_context( val_context_t *context );
An application maintains a run-time handle to its validator policy
through the validator context.
val_create_context() creates a new DNSSEC validator context. The
scope parameter identifies the DNSSEC validator policy to be used by
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 19]
Internet-Draft DNSSEC Validator API May 2008
the application for DNSSEC validation. The string specified in scope
has a hierarchical organization, with each element in the hierarchy
identifying a different DNSSEC validator policy label in the system
configuration. DNSSEC validator policy labels specified within scope
are separated by the ':' character. The DNSSEC validator MUST create
an effective DNSSEC validator policy by cumulatively applying the
policies for each label specified in the scope parameter. The DNSSEC
validator policy identified by the ":" label MUST always be applied
first. For example, for the DNSSEC validator policy scope "mozilla:
browser", the effective DNSSEC validator policy is computed by
applying policies for the ":", "browser" and "mozilla" policies, in
that order. Any library that implements this API MUST internally
create a DNSSEC validator context with the default DNSSEC validator
policy if scope is NULL.
The val_create_context() function returns 0 on success, and an error
code from Section 6 on failure. The newly created DNSSEC validator
context is returned in the newcontext field. A NULL DNSSEC validator
context MUST be returned if an error is encountered. The memory
allocated for the DNSSEC validator context after a successful call to
val_create_context() MUST be released after use by the application
using the val_free_context() function.
5.2. val_add_valpolicy, val_remove_valpolicy
#include <validator.h>
int val_add_valpolicy( val_context_t *context,
const char *keyword,
char *zone,
char *value,
long ttl,
val_policy_entry_t **pol);
int val_remove_valpolicy(val_context_t *context,
val_policy_entry_t *pol);
The val_add_valpolicy() function allows an application to add a new
DNSSEC validator policy definition to an existing DNSSEC validator
context. The newly added policy SHOULD only be associated with the
current DNSSEC validator context and SHOULD NOT be stored
persistently in the system configuration. The keyword and value
fields refer to a DNSSEC validator policy attribute and its value
respectively. A timeout MAY be attached to the DNSSEC validator
policy definition, with -1 specifying an indefinite timeout interval.
After the timeout interval, the effects of the newly added DNSSEC
validator policy MUST be ignored. A handle to the newly added DNSSEC
validator policy MUST be returned in *pol, which is a pointer to the
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 20]
Internet-Draft DNSSEC Validator API May 2008
val_policy_entry_t structure. This structure is opaque to
applications; applications MUST NOT modify the contents of the
val_policy_entry_t structure.
Applications can revoke the effects of a newly added DNSSEC validator
policy before the expiry of its timeout interval using the
val_remove_valpolicy() function. The DNSSEC validator policy that is
to be removed from the DNSSEC validator context is identified by its
handle, pol.
The above functions return 0 on success and an error code from
Section 6 on failure.
6. Function Return Codes and p_val_err()
The following codes can be returned by functions defined in the low-
level API, DNSSEC validator-context API, and by the val_get_rrset()
function defined in the high-level API. Other high-level API
functions mirror existing legacy DNS-related functions, so the return
codes from these functions are identical to their predecessors. The
numerical values for the return codes listed below are
implementation-specific.
VAL_NO_ERROR: the function call was successful.
VAL_NOT_IMPLEMENTED: the implementation did not support a particular
feature.
VAL_RESOURCE_UNAVAILABLE: some resource necessary for an operation
(such as memory) was unavailable.
VAL_BAD_ARGUMENT: an unexpected value was passed as an argument to a
function.
VAL_INTERNAL_ERROR: an internal error was encountered by the DNSSEC
validator.
VAL_CONF_PARSE_ERROR: the DNSSEC validator configuration was
improperly specified in the system configuration.
VAL_CONF_NOT_FOUND: the DNSSEC validator configuration could not be
located in the system configuration.
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 21]
Internet-Draft DNSSEC Validator API May 2008
VAL_NO_POLICY: the DNSSEC validator policy identifier being
referenced was invalid.
The error codes listed above can be converted to a string
representation using the p_val_err() function.
#include <validator.h>
const char *p_val_err(int err);
The returned value from p_val_err() SHOULD be the string conversion
for the corresponding error code identifier. For example,
p_val_err(VAL_NO_ERROR) SHOULD return "VAL_NO_ERROR".
7. Evaluating Response Validity
The result of DNSSEC validation for a resource record set, based on
the individual status code of each element in an authentication
chain, is returned in a variable of type val_status_t. val_status_t
can contain one of possible codes listed in Section 7.1. The
functions provided in Section 7.2 simplify the task of evaluating
validity of an answer by wrapping around the different status codes
possible for each type of answer.
7.1. DNSSEC Validation Status Codes and p_val_status()
A variable of type val_status_t can contain one of the following
codes (the numerical values for these codes are implementation-
specific):
VAL_VALIDATED_ANSWER: returned if the combined DNSSEC validation
status for a set of resource record set responses represents a
validated state.
VAL_TRUSTED_ANSWER: returned if the combined DNSSEC validation
status for a set of resource record set responses represents a
trusted (but non-validated) state.
VAL_UNTRUSTED_ANSWER: returned if the combined DNSSEC validation
status for a set of resource record set responses represents an
untrusted state.
VAL_SUCCESS: the response for the given resource record set was
successfully validated through the DNSSEC validation process.
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 22]
Internet-Draft DNSSEC Validator API May 2008
VAL_NONEXISTENT_NAME: the proof for denial of existence for a domain
name validated successfully.
VAL_NONEXISTENT_TYPE: the proof for denial of existence for the
resource record type for the given name was validated
successfully.
VAL_NONEXISTENT_NAME_NOCHAIN: the proof for non-existence of a
domain name was considered valid through local DNSSEC validator
configuration; the authentication chain(s) for the different
components of the proof were not validated.
VAL_NONEXISTENT_TYPE_NOCHAIN: the proof for non-existence of the
resource record type for the name queried was considered valid
through local DNSSEC validator configuration; the authentication
chain(s) for the different components of the proof were not
validated.
VAL_PROVABLY_INSECURE: the record or some ancestor of the record in
the authentication chain towards a DNSSEC trust anchor was known
to be provably insecure and DNSSEC validator policy is configured
to trust provably insecure answers.
VAL_BAD_PROVABLY_INSECURE: the record or some ancestor of the record
in the authentication chain towards a DNSSEC trust anchor was
known to be provably insecure, but DNSSEC validator policy is
configured to not trust provably insecure answers.
VAL_BARE_RRSIG: the response was for a query of type RRSIG. RRSIGs
contain the cryptographic signatures for other DNS data and cannot
themselves be validated.
VAL_IGNORE_VALIDATION: DNSSEC validator policy was configured to
ignore DNSSEC validation for the zone from where this data was
received.
VAL_TRUSTED_ZONE: DNSSEC validator policy was configured to trust
all responses from the zone that this data was received from.
VAL_UNTRUSTED_ZONE: DNSSEC validator policy was configured to not
trust any response from the zone that this data was received from.
VAL_LOCAL_ANSWER: the response was obtained from a local
configuration store (for example, a file such as /etc/hosts).
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 23]
Internet-Draft DNSSEC Validator API May 2008
VAL_BOGUS: the response could not be validated due to signature
verification failures or the inability to verify proofs of non-
existence for one or more components in the authentication chain.
VAL_DNS_ERROR: returned if a DNS error was encountered during the
query resolution process.
VAL_NOTRUST: the authentication chain does not lead up to a
configured DNSSEC trust anchor.
The DNSSEC validation status code stored in a variable of type
val_status_t can be converted to a string representation using the
p_val_status() function.
#include <validator.h>
char *p_val_status(val_status_t err);
The value returned SHOULD be the string conversion for the
corresponding val_status_t identifier. For example,
p_val_status(VAL_SUCCESS) SHOULD return "VAL_SUCCESS".
7.2. High-Level Routines for Evaluating Validity
#include <validator.h>
int val_istrusted(val_status_t status);
int val_isvalidated(val_status_t status);
int val_does_not_exist(val_status_t status);
Most applications will be interested in a single value that
represents the validity of DNS data. In some instances an
application may also need to distinguish between cases where the
answer was cryptographically validated and cases where the answer was
locally trusted. The val_istrusted() and val_isvalidated() functions
allow an application to evaluate, at a high level, the validity of a
response without having to inspect the exact status code returned.
The val_istrusted() function returns a single integer value
representing the validity of information returned by the DNSSEC
validator. The return value MUST be greater than 0 if status is one
of VAL_SUCCESS, VAL_NONEXISTENT_NAME, VAL_NONEXISTENT_TYPE,
VAL_NONEXISTENT_NAME_NOCHAIN, VAL_NONEXISTENT_TYPE_NOCHAIN,
VAL_PROVABLY_INSECURE, VAL_IGNORE_VALIDATION, VAL_TRUSTED_ZONE,
VAL_TRUSTED_ANSWER, or VAL_VALIDATED_ANSWER and MUST be equal to 0
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 24]
Internet-Draft DNSSEC Validator API May 2008
for other status codes.
The val_isvalidated() function returns a single integer value that
indicates if the answer cryptographically chains down from a
configured DNSSEC trust anchor. The return value MUST be greater
than 0 if status is one of VAL_SUCCESS, VAL_NONEXISTENT_NAME,
VAL_NONEXISTENT_TYPE, or VAL_VALIDATED_ANSWER and MUST be equal to 0
for other status codes.
The val_does_not_exist() function allows an application to determine
from the DNSSEC validation status value if the answer was provably
non-existent. In combination with the val_istrusted() and
val_isvalidated() functions, it can give an indication about the
manner in which validity was determined (cryptographically verified
or locally trusted by the DNSSEC validator). The return value from
val_does_not_exist() MUST be greater than 0 if status is one of
VAL_NONEXISTENT_TYPE, VAL_NONEXISTENT_NAME,
VAL_NONEXISTENT_NAME_NOCHAIN, or VAL_NONEXISTENT_TYPE_NOCHAIN and
MUST be equal to 0 for other status codes.
8. IANA Considerations
This document has no actions for IANA.
9. Security Considerations
In certain cases DNS responses may be returned from the local system
configuration (for example, from the /etc/hosts file on some
systems). The application cannot assume that these answers are
valid, unless the application is certain that the local configuration
store contains valid data. If this information is modified during a
DHCP lookup, for example, the client system should ensure that the
DHCP server is a trusted source, and that the communication path
between the DHCP server and the client system is secured. If these
conditions are not satisfied and if the application chooses to trust
a locally available answer, an attaker may be able to poison the
system configuration and cause an application to use invalid answers.
Applications can choose to trust data from provably insecure zones.
Not performing DNSSEC validation and having a zone that has DNSSEC
intentionally turned off is no worse than the current situation of
DNSSEC-unaware applications not being able to detect the integrity of
DNS data.
The DNS search path may affect the result of DNSSEC validation,
especially in the current Internet environment where not all DNS name
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 25]
Internet-Draft DNSSEC Validator API May 2008
servers are expected to be DNSSEC-aware. If the name server pointed
to by the system configuration is not DNSSEC-aware (i.e. it does not
return DNSSEC records), DNSSEC validation will not be performed.
The DNSSEC validator configuration information needs to be protected
so that it cannot be overwritten by unauthorized users or processes.
The system administrator must ensure that the list of DNSSEC trust
anchors is kept accurate and up-to-date. If the DNSSEC trust anchors
are outdated (in the event of key-rollovers), the DNSSEC validator
may either not be able to perform DNSSEC validation or may operate
with the false belief of having validated a response when the
response should really have been flagged as bogus. Any subversion of
the DNSSEC policy configuration (including definition of new trust
anchors) can similarly completely undermine the value of DNSSEC.
10. Acknowledgements
A number of individuals have provided valuable feedback and
suggestions for improving this document including the following:
Lindy Foster, Wayne Morrison, Russ Mundy, Bill Sommerfeld, Robert
Story, Wes Hardaker, Giovanni Marzot and Alfred Hines. The list of
authentication status codes in Section 4.3 was generated through
multiple brainstorming sessions at various IETF meetings; this draft
draws on the results from that effort.
11. References
11.1. Normative References
[1] IEEE and The Open Group, http://www.opengroup.org, "IEEE Std
1003.1-2004 Standard for Information Technology -- Portable
Operating System Interface (POSIX). Open Group Technical
Standard: Base Specifications, Issue 6", ISO/IEC 9945:2003,
February 2004.
[2] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493,
February 2003.
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 26]
Internet-Draft DNSSEC Validator API May 2008
11.2. Informative References
[5] Mockapetris, P., "Domain Names - Concepts and Facilities",
RFC 1034, November 1987.
[6] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672,
August 1999.
[7] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
Appendix A. Configuring DNSSEC Validator Policy
DNSSEC validator policy definitions in the system configuration are
implementation-specific but they MAY have the following structure.
<label> <attribute> <additional-data>;
Sample values for <attribute> are "trust-anchor", "zone-security-
expectation", "provably-insecure-status", "clock-skew". The value
for <additional-data> will depend on the type of attribute specified.
o For the "trust-anchor" attribute additional-data SHOULD be a
sequence of ordered pairs, each consisting of the zone name and a
quoted string containing the resource record data for the trust
anchor's DNSKEY. An example is given below.
browser trust-anchor
example.com "257 3 5 AQO8XS4y9r77X 9SHBmrx MoJf1Pf9\
AT9Mr/L5BBGtO9/e9f/zl4FFgM2l B6M2 XEm6mp6 mit4tzp\
B/sAEQw1McYz6bJdKkTiqtuWTCfDmgQhI6 /Ha0 Ef GPNSqn\
Y 99FmbSeWNIRaa4fgSCVFhvbrYq1nXkNVy QPeEVHk oDNCA\
lr qOA3lw=="
example.org "257 3 5 AQO8XS4y9r77X 9SHBmrx MoJf1Pf9\
AT9Mr/L5BBGtO9/e9f/zl4FFgM2l B6M2 XEm6mp6 mit4tzp\
B/sAEQw1McYz6bJdKkTiqtuWTCfDmgQhI6 /Ha0 Ef GPNSqn\
Y 99FmbSeWNIRaa4fgSCVFhvbrYq1nXkNVy QPeEVHk oDNCA\
lr qOA3lw=="
;
o For the "zone-security-expectation" attribute additional-data
SHOULD be a sequence of <domain name,value> tuples representing
the security expectation for names in that domain, where value can
be one of the following:
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 27]
Internet-Draft DNSSEC Validator API May 2008
ignore: Ignore DNSSEC validation for names under this domain.
trusted: Trust all answers received for names under this domain
regardless of their DNSSEC verification status.
validate: Perform DNSSEC validation of answers received for names
under this domain.
untrusted: Reject all answers received for names under this
domain.
This zone-security-expectation DNSSEC validator policy construct
makes it possible to define various islands of trust for DNSSEC-
enabled zones and to ignore or trust data from selected zones.
The default zone security expectation for a domain SHOULD be
"validate". In the following example, for DNSSEC validator
contexts created with a DNSSEC validator policy label of
"browser", the DNSSEC validation is only performed for names under
the example.com domain; names under the somebogusdomain.org domain
are always considered to be untrusted and DNSSEC validation for
all other domain names is ignored.
browser zone-security-expectation
example.com validate
somebogusdomain.org untrusted
. ignore
;
o For the "provably-insecure-status" attribute additional-data
SHOULD be a sequence of <domain name,value> tuples representing
the validity of the provably insecure condition, where value
SHOULD be one of the following:
trusted: Treat the provably insecure condition as valid.
untrusted: Treat the provably insecure condition as invalid.
The default value for the provably insecure status for a domain
SHOULD be "trusted". In the following example, for DNSSEC
validator contexts created with the default label, the provably
insecure condition is treated as trustworthy for all domains
except the net domain, where this condition is treated as invalid.
: provably-insecure-status
. trusted
net untrusted
;
o For the "clock-skew" attribute additional-data SHOULD be a
sequence of the domain name and the number of seconds of clock-
skew acceptable for signatures on names in that domain. A clock
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 28]
Internet-Draft DNSSEC Validator API May 2008
skew value of -1 SHOULD have the effect of turning off inception
and expiration time checks on signatures from that domain. The
default clock skew SHOULD be 0. In the following example, for
DNSSEC validator contexts created with the "mta" label, signature
inception and expiration checks are disabled for all names under
the example.com domain.
mta clock-skew
example.com -1
;
Authors' Addresses
Suresh Krishnaswamy
SPARTA, Inc.
7110 Samuel Morse Dr.
Columbia, MD 21046
US
Email: suresh AT sparta.com
Abhijit Hayatnagarkar
SPARTA, Inc.
7110 Samuel Morse Dr.
Columbia, MD 21046
US
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 29]
Internet-Draft DNSSEC Validator API May 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Krishnaswamy & Hayatnagarkar Expires November 28, 2008 [Page 30]