d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

This commit was manufactured by cvs2svn to create branch 'RELENG_6'.

Browse Source
This commit is contained in:
cvs2svn 2005-12-30 16:45:32 +00:00
parent 1937d32dc3
commit 30ca7bc8d2
66 changed files with 50858 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1007
contrib/bind9/FAQ.xml Normal file
View File

File diff suppressed because it is too large Load Diff

44
contrib/bind9/bin/named/include/named/ns_smf_globals.h Normal file
View File

@ -0,0 +1,44 @@
/*
* Copyright (C) 2005 Internet Systems Consortium, Inc. ("ISC")
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
* REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
* AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
* INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
* LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
* OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: ns_smf_globals.h,v 1.2.4.4 2005/05/13 01:22:33 marka Exp $ */
#ifndef NS_SMF_GLOBALS_H
#define NS_SMF_GLOBALS_H 1
#include <libscf.h>
#undef EXTERN
#undef INIT
#ifdef NS_MAIN
#define EXTERN
#define INIT(v) = (v)
#else
#define EXTERN extern
#define INIT(v)
#endif
EXTERN unsigned int ns_smf_got_instance INIT(0);
EXTERN unsigned int ns_smf_chroot INIT(0);
EXTERN unsigned int ns_smf_want_disable INIT(0);
isc_result_t ns_smf_add_message(isc_buffer_t *text);
isc_result_t ns_smf_get_instance(char **name, int debug, isc_mem_t *mctx);
#undef EXTERN
#undef INIT
#endif /* NS_SMF_GLOBALS_H */

152
contrib/bind9/config.threads.in Normal file
View File

@ -0,0 +1,152 @@
#
# Begin pthreads checking.
#
# First, decide whether to use multithreading or not.
#
# Enable multithreading by default on systems where it is known
# to work well, and where debugging of multithreaded programs
# is supported.
#
AC_MSG_CHECKING(whether to build with thread support)
case $host in
*-dec-osf*)
use_threads=true ;;
[*-solaris2.[0-6]])
# Thread signals are broken on Solaris 2.6; they are sometimes
# delivered to the wrong thread.
use_threads=false ;;
*-solaris*)
use_threads=true ;;
*-ibm-aix*)
use_threads=true ;;
*-hp-hpux10*)
use_threads=false ;;
*-hp-hpux11*)
use_threads=true ;;
*-sgi-irix*)
use_threads=true ;;
*-sco-sysv*uw*|*-*-sysv*UnixWare*)
# UnixWare
use_threads=false ;;
*-*-sysv*OpenUNIX*)
# UnixWare
use_threads=true ;;
*-netbsd*)
if test -r /usr/lib/libpthread.so ; then
use_threads=true
else
# Socket I/O optimizations introduced in 9.2 expose a
# bug in unproven-pthreads; see PR #12650
use_threads=false
fi
;;
*-openbsd*)
# OpenBSD users have reported that named dumps core on
# startup when built with threads.
use_threads=false ;;
*-freebsd*)
use_threads=false ;;
*-bsdi[234]*)
# Thread signals do not work reliably on some versions of BSD/OS.
use_threads=false ;;
*-bsdi5*)
use_threads=true ;;
*-linux*)
# Threads are disabled on Linux by default because most
# Linux kernels produce unusable core dumps from multithreaded
# programs, and because of limitations in setuid().
use_threads=false ;;
*)
use_threads=false ;;
esac
AC_ARG_ENABLE(threads,
[ --enable-threads enable multithreading])
case "$enable_threads" in
yes)
use_threads=true
;;
no)
use_threads=false
;;
'')
# Use system-dependent default
;;
*)
AC_MSG_ERROR([--enable-threads takes yes or no])
;;
esac
if $use_threads
then
AC_MSG_RESULT(yes)
else
AC_MSG_RESULT(no)
fi
if $use_threads
then
#
# Search for / configure pthreads in a system-dependent fashion.
#
case "$host" in
*-netbsd*)
# NetBSD has multiple pthreads implementations. The
# recommended one to use is "unproven-pthreads". The
# older "mit-pthreads" may also work on some NetBSD
# versions. The PTL2 thread library does not
# currently work with bind9, but can be chosen with
# the --with-ptl2 option for those who wish to
# experiment with it.
CC="gcc"
AC_MSG_CHECKING(which NetBSD thread library to use)
AC_ARG_WITH(ptl2,
[ --with-ptl2 on NetBSD, use the ptl2 thread library (experimental)],
use_ptl2="$withval", use_ptl2="no")
: ${LOCALBASE:=/usr/pkg}
if test "X$use_ptl2" = "Xyes"
then
AC_MSG_RESULT(PTL2)
AC_MSG_WARN(
[linking with PTL2 is highly experimental and not expected to work])
CC=ptlgcc
else
if test -r /usr/lib/libpthread.so
then
AC_MSG_RESULT(native)
LIBS="-lpthread $LIBS"
else
if test ! -d $LOCALBASE/pthreads
then
AC_MSG_RESULT(none)
AC_MSG_ERROR("could not find thread libraries")
fi
if $use_threads
then
AC_MSG_RESULT(mit-pthreads/unproven-pthreads)
pkg="$LOCALBASE/pthreads"
lib1="-L$pkg/lib -Wl,-R$pkg/lib"
lib2="-lpthread -lm -lgcc -lpthread"
LIBS="$lib1 $lib2 $LIBS"
CPPFLAGS="$CPPFLAGS -I$pkg/include"
STD_CINCLUDES="$STD_CINCLUDES -I$pkg/include"
fi
fi
fi
;;
*)
AC_CHECK_LIB(pthread, pthread_create,,
AC_CHECK_LIB(pthread, __pthread_create,,
AC_CHECK_LIB(pthread, __pthread_create_system,,
AC_CHECK_LIB(c_r, pthread_create,,
AC_CHECK_LIB(c, pthread_create,,
AC_MSG_ERROR("could not find thread libraries"))))))
;;
esac
fi

8964
contrib/bind9/doc/arm/Bv9ARM.pdf Executable file
View File

File diff suppressed because one or more lines are too long

928
contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt Normal file
View File

@ -0,0 +1,928 @@
INTERNET-DRAFT Donald E. Eastlake 3rd
Obsoletes RFC 2929, Updates RFC 1183 Motorola Laboratories
Expires: February 2006 August 2005
Domain Name System (DNS) IANA Considerations
------ ---- ------ ----- ---- --------------
<draft-ietf-dnsext-2929bis-01.txt>
Status of This Document
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.
Distribution of this draft is unlimited. It is intended to become
the new BCP 42 obsoleting RFC 2929. Comments should be sent to the
DNS Working Group mailing list <namedroppers@ops.ietf.org>.
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 a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
Internet Assigned Number Authority (IANA) parameter assignment
considerations are given for the allocation of Domain Name System
(DNS) classes, RR types, operation codes, error codes, RR header
bits, and AFSDB subtypes.
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT DNS IANA Considerations August 2005
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................3
2. DNS Query/Response Headers..............................3
2.1 One Spare Bit?.........................................4
2.2 Opcode Assignment......................................4
2.3 RCODE Assignment.......................................5
3. DNS Resource Records....................................6
3.1 RR TYPE IANA Considerations............................7
3.1.1 DNS TYPE Allocation Policy...........................8
3.1.2 Special Note on the OPT RR...........................9
3.1.3 The AFSDB RR Subtype Field...........................9
3.2 RR CLASS IANA Considerations...........................9
3.3 RR NAME Considerations................................11
4. Security Considerations................................11
Appendix: Changes from RFC 2929...........................12
Copyright and Disclaimer..................................13
Normative References......................................13
Informative References....................................14
Authors Addresses.........................................16
Expiration and File Name..................................16
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT DNS IANA Considerations August 2005
1. Introduction
The Domain Name System (DNS) provides replicated distributed secure
hierarchical databases which hierarchically store "resource records"
(RRs) under domain names. DNS data is structured into CLASSes and
zones which can be independently maintained. See [RFC 1034, 1035,
2136, 2181, 4033] familiarity with which is assumed.
This document provides, either directly or by reference, general IANA
parameter assignment considerations applying across DNS query and
response headers and all RRs. There may be additional IANA
considerations that apply to only a particular RR type or
query/response opcode. See the specific RFC defining that RR type or
query/response opcode for such considerations if they have been
defined, except for AFSDB RR considerations [RFC 1183] which are
included herein. This RFC obsoletes [RFC 2929].
IANA currently maintains a web page of DNS parameters. See
<http://www.iana.org/numbers.htm>.
"IETF Standards Action", "IETF Consensus", "Specification Required",
and "Private Use" are as defined in [RFC 2434].
2. DNS Query/Response Headers
The header for DNS queries and responses contains field/bits in the
following diagram taken from [RFC 2136, 2929]:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The ID field identifies the query and is echoed in the response so
they can be matched.
The QR bit indicates whether the header is for a query or a response.
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT DNS IANA Considerations August 2005
The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
only in queries or only in responses, depending on the bit. However,
many DNS implementations copy the query header as the initial value
of the response header without clearing bits. Thus any attempt to
use a "query" bit with a different meaning in a response or to define
a query meaning for a "response" bit is dangerous given existing
implementation. Such meanings may only be assigned by an IETF
Standards Action.
The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
authority count (NSCOUNT), and additional information count (ARCOUNT)
express the number of records in each section for all opcodes except
Update. These fields have the same structure and data type for
Update but are instead the counts for the zone (ZOCOUNT),
prerequisite (PRCOUNT), update (UPCOUNT), and additional information
(ARCOUNT) sections.
2.1 One Spare Bit?
There have been ancient DNS implementations for which the Z bit being
on in a query meant that only a response from the primary server for
a zone is acceptable. It is believed that current DNS
implementations ignore this bit.
Assigning a meaning to the Z bit requires an IETF Standards Action.
2.2 Opcode Assignment
Currently DNS OpCodes are assigned as follows:
OpCode Name Reference
0 Query [RFC 1035]
1 IQuery (Inverse Query, Obsolete) [RFC 3425]
2 Status [RFC 1035]
3 available for assignment
4 Notify [RFC 1996]
5 Update [RFC 2136]
6-15 available for assignment
New OpCode assignments require an IETF Standards Action as modified
by [RFC 4020].
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT DNS IANA Considerations August 2005
2.3 RCODE Assignment
It would appear from the DNS header above that only four bits of
RCODE, or response/error code are available. However, RCODEs can
appear not only at the top level of a DNS response but also inside
OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
The OPT RR provides an eight bit extension resulting in a 12 bit
RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
Error codes appearing in the DNS header and in these three RR types
all refer to the same error code space with the single exception of
error code 16 which has a different meaning in the OPT RR from its
meaning in other contexts. See table below.
RCODE Name Description Reference
Decimal
Hexadecimal
0 NoError No Error [RFC 1035]
1 FormErr Format Error [RFC 1035]
2 ServFail Server Failure [RFC 1035]
3 NXDomain Non-Existent Domain [RFC 1035]
4 NotImp Not Implemented [RFC 1035]
5 Refused Query Refused [RFC 1035]
6 YXDomain Name Exists when it should not [RFC 2136]
7 YXRRSet RR Set Exists when it should not [RFC 2136]
8 NXRRSet RR Set that should exist does not [RFC 2136]
9 NotAuth Server Not Authoritative for zone [RFC 2136]
10 NotZone Name not contained in zone [RFC 2136]
11 - 15 Available for assignment
16 BADVERS Bad OPT Version [RFC 2671]
16 BADSIG TSIG Signature Failure [RFC 2845]
17 BADKEY Key not recognized [RFC 2845]
18 BADTIME Signature out of time window [RFC 2845]
19 BADMODE Bad TKEY Mode [RPC 2930]
20 BADNAME Duplicate key name [RPF 2930]
21 BADALG Algorithm not supported [RPF 2930]
22 - 3,840
0x0016 - 0x0F00 Available for assignment
3,841 - 4,095
0x0F01 - 0x0FFF Private Use
4,096 - 65,534
0x1000 - 0xFFFE Available for assignment
65,535
0xFFFF Reserved, can only be allocated by an IETF
Standards Action.
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT DNS IANA Considerations August 2005
Since it is important that RCODEs be understood for interoperability,
assignment of new RCODE listed above as "available for assignment"
requires an IETF Consensus.
3. DNS Resource Records
All RRs have the same top level format shown in the figure below
taken from [RFC 1035]:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NAME is an owner name, i.e., the name of the node to which this
resource record pertains. NAMEs are specific to a CLASS as described
in section 3.2. NAMEs consist of an ordered sequence of one or more
labels each of which has a label type [RFC 1035, 2671].
TYPE is a two octet unsigned integer containing one of the RR TYPE
codes. See section 3.1.
CLASS is a two octet unsigned integer containing one of the RR CLASS
codes. See section 3.2.
TTL is a four octet (32 bit) bit unsigned integer that specifies the
number of seconds that the resource record may be cached before the
source of the information should again be consulted. Zero is
interpreted to mean that the RR can only be used for the transaction
in progress.
RDLENGTH is an unsigned 16 bit integer that specifies the length in
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT DNS IANA Considerations August 2005
octets of the RDATA field.
RDATA is a variable length string of octets that constitutes the
resource. The format of this information varies according to the TYPE
and in some cases the CLASS of the resource record.
3.1 RR TYPE IANA Considerations
There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
and MetaTYPEs.
Data TYPEs are the primary means of storing data. QTYPES can only be
used in queries. Meta-TYPEs designate transient data associated with
an particular DNS message and in some cases can also be used in
queries. Thus far, data TYPEs have been assigned from 1 upwards plus
the block from 100 through 103 while Q and Meta Types have been
assigned from 255 downwards except for the OPT Meta-RR which is
assigned TYPE 41. There have been DNS implementations which made
caching decisions based on the top bit of the bottom byte of the RR
TYPE.
There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
[RFC 2845], and TKEY [RFC 2930].
There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
AXFR, and IXFR.
Considerations for the allocation of new RR TYPEs are as follows:
Decimal
Hexadecimal
0
0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
2535] and in other circumstances and must never be allocated
for ordinary use.
1 - 127
0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
TYPEs by the DNS TYPE Allocation Policy as specified in
section 3.1.1.
128 - 255
0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
Meta TYPEs by the DNS TYPE Allocation Policy as specified in
section 3.1.1.
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT DNS IANA Considerations August 2005
256 - 32,767
0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS
TYPE Allocation Policy as specified in section 3.1.1.
32,768 - 65,279
0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
65,280 - 65534
0xFF00 - 0xFFFE - Private Use.
65,535
0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
3.1.1 DNS TYPE Allocation Policy
Parameter values specified above as assigned based on DNS TYPE
Allocation Policy. That is, Expert Review with the additional
requirement that the review be based on a complete template as
specified below which has been posted for three weeks to the
namedroppers@ops.ietf.org mailing list.
Partial or draft templates may be posted with the intend of
soliciting feedback.
DNS RR TYPE PARAMETER ALLOCATION TEMPLATE
Date:
Name and email of originator:
Pointer to internet-draft or other document giving a detailed
description of the protocol use of the new RR Type:
What need is the new RR TYPE intended to fix?
What existing RR TYPE(s) come closest to filling that need and why are
they unsatisfactory?
Does the proposed RR TYPR require special handling within the DNS
different from an Unknown RR TYPE?
Comments:
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT DNS IANA Considerations August 2005
3.1.2 Special Note on the OPT RR
The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its
primary purpose is to extend the effective field size of various DNS
fields including RCODE, label type, OpCode, flag bits, and RDATA
size. In particular, for resolvers and servers that recognize it, it
extends the RCODE field from 4 to 12 bits.
3.1.3 The AFSDB RR Subtype Field
The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same
RDATA field structure as the MX RR but the 16 bit unsigned integer
field at the beginning of the RDATA is interpreted as a subtype as
follows:
Decimal
Hexadecimal
0
0x0000 - Allocation requires IETF Standards Action.
1
0x0001 - Andrews File Service v3.0 Location Service [RFC 1183].
2
0x0002 - DCE/NCA root cell directory node [RFC 1183].
3 - 65,279
0x0003 - 0xFEFF - Allocation by IETF Consensus.
65,280 - 65,534
0xFF00 - 0xFFFE - Private Use.
65,535
0xFFFF - Reserved, allocation requires IETF Standards Action.
3.2 RR CLASS IANA Considerations
DNS CLASSes have been little used but constitute another dimension of
the DNS distributed database. In particular, there is no necessary
relationship between the name space or root servers for one CLASS and
those for another CLASS. The same name can have completely different
meanings in different CLASSes; however, the label types are the same
and the null label is usable only as root in every CLASS. However,
as global networking and DNS have evolved, the IN, or Internet, CLASS
has dominated DNS use.
D. Eastlake 3rd [Page 9]
INTERNET-DRAFT DNS IANA Considerations August 2005
There are two subcategories of DNS CLASSes: normal data containing
classes and QCLASSes that are only meaningful in queries or updates.
The current CLASS assignments and considerations for future
assignments are as follows:
Decimal
Hexadecimal
0
0x0000 - Reserved, assignment requires an IETF Standards Action.
1
0x0001 - Internet (IN).
2
0x0002 - Available for assignment by IETF Consensus as a data CLASS.
3
0x0003 - Chaos (CH) [Moon 1981].
4
0x0004 - Hesiod (HS) [Dyer 1987].
5 - 127
0x0005 - 0x007F - available for assignment by IETF Consensus for data
CLASSes only.
128 - 253
0x0080 - 0x00FD - available for assignment by IETF Consensus for
QCLASSes only.
254
0x00FE - QCLASS None [RFC 2136].
255
0x00FF - QCLASS Any [RFC 1035].
256 - 32,767
0x0100 - 0x7FFF - Assigned by IETF Consensus.
32,768 - 65,279
0x8000 - 0xFEFF - Assigned based on Specification Required as defined
in [RFC 2434].
65,280 - 65,534
0xFF00 - 0xFFFE - Private Use.
65,535
0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
D. Eastlake 3rd [Page 10]
INTERNET-DRAFT DNS IANA Considerations August 2005
3.3 RR NAME Considerations
DNS NAMEs are sequences of labels [RFC 1035]. The last label in each
NAME is "ROOT" which is the zero length label. By definition, the
null or ROOT label can not be used for any other NAME purpose.
At the present time, there are two categories of label types, data
labels and compression labels. Compression labels are pointers to
data labels elsewhere within an RR or DNS message and are intended to
shorten the wire encoding of NAMEs. The two existing data label
types are sometimes referred to as Text and Binary. Text labels can,
in fact, include any octet value including zero value octets but most
current uses involve only [US-ASCII]. For retrieval, Text labels are
defined to treat ASCII upper and lower case letter codes as matching
[insensitive]. Binary labels are bit sequences [RFC 2673]. The
Binary label type is Experimental [RFC 3363].
IANA considerations for label types are given in [RFC 2671].
NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon
1981] CLASSes are essentially for local use. The IN or Internet
CLASS is thus the only DNS CLASS in global use on the Internet at
this time.
A somewhat out-of-date description of name allocation in the IN Class
is given in [RFC 1591]. Some information on reserved top level
domain names is in BCP 32 [RFC 2606].
4. Security Considerations
This document addresses IANA considerations in the allocation of
general DNS parameters, not security. See [RFC 4033, 4034, 4035] for
secure DNS considerations.
D. Eastlake 3rd [Page 11]
INTERNET-DRAFT DNS IANA Considerations August 2005
Appendix: Changes from RFC 2929
RFC Editor: This Appendix should be deleted for publication.
Changes from RFC 2929 to this draft:
1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE
Allocation Policy" and add the specification of that policy. Change
some remaining "IETF Standards Action" allocation requirements to say
"as modified by [RFC 4020]".
2. Updated various RFC references.
3. Mentioned that the Binary label type is now Experimental and
IQuery is Obsolete.
4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be
IETF Standards Action required.
5. Add an IANA allocation policy for the AFSDB RR Subtype field.
6. Addition of reference to case insensitive draft.
D. Eastlake 3rd [Page 12]
INTERNET-DRAFT DNS IANA Considerations August 2005
Copyright and Disclaimer
Copyright (C) The Internet Society (2005). 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 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.
Normative References
[RFC 1034] - Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[RFC 1035] - Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987.
[RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P.
Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
[RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System",
RFC 2673, August 1999.
[RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B.
Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, May 2000.
D. Eastlake 3rd [Page 13]
INTERNET-DRAFT DNS IANA Considerations August 2005
[RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", September 2000.
[RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
the Domain Name System (DNS)", RFC 3363, August 2002.
[RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
2002.
[RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of
Standards Track Code Points", BCP 100, RFC 4020, February 2005.
[RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC 4033, March
2005.
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Extensions", RFC
4035, March 2005.
[US-ASCII] - ANSI, "USA Standard Code for Information Interchange",
X3.4, American National Standards Institute: New York, 1968.
Informative References
[Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena
Technical Plan - Name Service, April 1987,
[Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
Institute of Technology Artificial Intelligence Laboratory, June
1981.
[RFC 1591] - Postel, J., "Domain Name System Structure and
Delegation", RFC 1591, March 1994.
[RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
"Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
September 2000.
[RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", RFC 2606, June 1999.
[insensitive] - Eastlake, D., "Domain Name System (DNS) Case
D. Eastlake 3rd [Page 14]
INTERNET-DRAFT DNS IANA Considerations August 2005
Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt,
work in progress.
D. Eastlake 3rd [Page 15]
INTERNET-DRAFT DNS IANA Considerations August 2005
Authors Addresses
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1-508-786-7554 (w)
email: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires February 2006.
Its file name is draft-ietf-dnsext-2929bis-01.txt.
D. Eastlake 3rd [Page 16]

562
contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt Normal file
View File

@ -0,0 +1,562 @@
DNSEXT M. Stapp
Internet-Draft Cisco Systems, Inc.
Expires: August 13, 2005 T. Lemon
A. Gustafsson
Nominum, Inc.
February 9, 2005
A DNS RR for Encoding DHCP Information (DHCID RR)
<draft-ietf-dnsext-dhcid-rr-09.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 13, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
It is possible for multiple DHCP clients to attempt to update the
same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or
the clients themselves perform the DNS updates, conflicts can arise.
To resolve such conflicts, "Resolution of DNS Name Conflicts" [1]
Stapp, et al. Expires August 13, 2005 [Page 1]
Internet-Draft The DHCID RR February 2005
proposes storing client identifiers in the DNS to unambiguously
associate domain names with the DHCP clients to which they refer.
This memo defines a distinct RR type for this purpose for use by DHCP
clients and servers, the "DHCID" RR.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 DHCID RDATA format . . . . . . . . . . . . . . . . . . . . 4
3.2 DHCID Presentation Format . . . . . . . . . . . . . . . . 4
3.3 The DHCID RR Type Codes . . . . . . . . . . . . . . . . . 4
3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . 4
3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . 6
3.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . 6
4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 6
5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1 Normative References . . . . . . . . . . . . . . . . . . . 8
9.2 Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
Stapp, et al. Expires August 13, 2005 [Page 2]
Internet-Draft The DHCID RR February 2005
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
2. Introduction
A set of procedures to allow DHCP [7] clients and servers to
automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed
in "Resolution of DNS Name Conflicts" [1].
Conflicts can arise if multiple DHCP clients wish to use the same DNS
name. To resolve such conflicts, "Resolution of DNS Name Conflicts"
[1] proposes storing client identifiers in the DNS to unambiguously
associate domain names with the DHCP clients using them. In the
interest of clarity, it is preferable for this DHCP information to
use a distinct RR type. This memo defines a distinct RR for this
purpose for use by DHCP clients or servers, the "DHCID" RR.
In order to avoid exposing potentially sensitive identifying
information, the data stored is the result of a one-way MD5 [5] hash
computation. The hash includes information from the DHCP client's
REQUEST message as well as the domain name itself, so that the data
stored in the DHCID RR will be dependent on both the client
identification used in the DHCP protocol interaction and the domain
name. This means that the DHCID RDATA will vary if a single client
is associated over time with more than one name. This makes it
difficult to 'track' a client as it is associated with various domain
names.
The MD5 hash algorithm has been shown to be weaker than the SHA-1
algorithm; it could therefore be argued that SHA-1 is a better
choice. However, SHA-1 is significantly slower than MD5. A
successful attack of MD5's weakness does not reveal the original data
that was used to generate the signature, but rather provides a new
set of input data that will produce the same signature. Because we
are using the MD5 hash to conceal the original data, the fact that an
attacker could produce a different plaintext resulting in the same
MD5 output is not significant concern.
3. The DHCID RR
The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The
DHCID RR is only defined in the IN class. DHCID RRs cause no
additional section processing. The DHCID RR is not a singleton type.
Stapp, et al. Expires August 13, 2005 [Page 3]
Internet-Draft The DHCID RR February 2005
3.1 DHCID RDATA format
The RDATA section of a DHCID RR in transmission contains RDLENGTH
bytes of binary data. The format of this data and its interpretation
by DHCP servers and clients are described below.
DNS software should consider the RDATA section to be opaque. DHCP
clients or servers use the DHCID RR to associate a DHCP client's
identity with a DNS name, so that multiple DHCP clients and servers
may deterministically perform dynamic DNS updates to the same zone.
From the updater's perspective, the DHCID resource record RDATA
consists of a 16-bit identifier type, in network byte order, followed
by one or more bytes representing the actual identifier:
< 16 bits > DHCP identifier used
< n bytes > MD5 digest
3.2 DHCID Presentation Format
In DNS master files, the RDATA is represented as a single block in
base 64 encoding identical to that used for representing binary data
in RFC 2535 [8]. The data may be divided up into any number of white
space separated substrings, down to single base 64 digits, which are
concatenated to form the complete RDATA. These substrings can span
lines using the standard parentheses.
3.3 The DHCID RR Type Codes
The DHCID RR Type Code specifies what data from the DHCP client's
request was used as input into the hash function. The type codes are
defined in a registry maintained by IANA, as specified in Section 7.
The initial list of assigned values for the type code is:
0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7].
0x0001 = The data portion from a DHCPv4 client's Client Identifier
option [9].
0x0002 = The client's DUID (i.e., the data portion of a DHCPv6
client's Client Identifier option [10] or the DUID field from a
DHCPv4 client's Client Identifier option [12]).
0x0003 - 0xfffe = Available to be assigned by IANA.
0xffff = RESERVED
3.4 Computation of the RDATA
The DHCID RDATA is formed by concatenating the two type bytes with
Stapp, et al. Expires August 13, 2005 [Page 4]
Internet-Draft The DHCID RR February 2005
some variable-length identifying data.
< type > < data >
The RDATA for all type codes other than 0xffff, which is reserved for
future expansion, is formed by concatenating the two type bytes and a
16-byte MD5 hash value. The input to the hash function is defined to
be:
data = MD5(< identifier > < FQDN >)
The FQDN is represented in the buffer in unambiguous canonical form
as described in RFC 2535 [8], section 8.1. The type code and the
identifier are related as specified in Section 3.3: the type code
describes the source of the identifier.
When the updater is using the client's link-layer address as the
identifier, the first two bytes of the DHCID RDATA MUST be zero. To
generate the rest of the resource record, the updater computes a
one-way hash using the MD5 algorithm across a buffer containing the
client's network hardware type, link-layer address, and the FQDN
data. Specifically, the first byte of the buffer contains the
network hardware type as it appeared in the DHCP 'htype' field of the
client's DHCPREQUEST message. All of the significant bytes of the
chaddr field in the client's DHCPREQUEST message follow, in the same
order in which the bytes appear in the DHCPREQUEST message. The
number of significant bytes in the 'chaddr' field is specified in the
'hlen' field of the DHCPREQUEST message. The FQDN data, as specified
above, follows.
When the updater is using the DHCPv4 Client Identifier option sent by
the client in its DHCPREQUEST message, the first two bytes of the
DHCID RR MUST be 0x0001, in network byte order. The rest of the
DHCID RR MUST contain the results of computing an MD5 hash across the
payload of the option, followed by the FQDN. The payload of the
option consists of the bytes of the option following the option code
and length.
When the updater is using the DHCPv6 DUID sent by the client in its
REQUEST message, the first two bytes of the DHCID RR MUST be 0x0002,
in network byte order. The rest of the DHCID RR MUST contain the
results of computing an MD5 hash across the payload of the option,
followed by the FQDN. The payload of the option consists of the
bytes of the option following the option code and length.
3.5 Examples
Stapp, et al. Expires August 13, 2005 [Page 5]
Internet-Draft The DHCID RR February 2005
3.5.1 Example 1
A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
Ethernet MAC address 01:02:03:04:05:06 using domain name
"client.example.com" uses the client's link-layer address to identify
the client. The DHCID RDATA is composed by setting the two type
bytes to zero, and performing an MD5 hash computation across a buffer
containing the Ethernet MAC type byte, 0x01, the six bytes of MAC
address, and the domain name (represented as specified in
Section 3.4).
client.example.com. A 10.0.0.1
client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU
3.5.2 Example 2
A DHCP server allocates the IPv4 address 10.0.12.99 to a client which
included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c
in its DHCP request. The server updates the name "chi.example.com"
on the client's behalf, and uses the DHCP client identifier option
data as input in forming a DHCID RR. The DHCID RDATA is formed by
setting the two type bytes to the value 0x0001, and performing an MD5
hash computation across a buffer containing the seven bytes from the
client-id option and the FQDN (represented as specified in
Section 3.4).
chi.example.com. A 10.0.12.99
chi.example.com. DHCID AAHdd5jiQ3kEjANDm82cbObk\012
4. Use of the DHCID RR
This RR MUST NOT be used for any purpose other than that detailed in
"Resolution of DNS Name Conflicts" [1]. Although this RR contains
data that is opaque to DNS servers, the data must be consistent
across all entities that update and interpret this record.
Therefore, new data formats may only be defined through actions of
the DHC Working Group, as a result of revising [1].
5. Updater Behavior
The data in the DHCID RR allows updaters to determine whether more
than one DHCP client desires to use a particular FQDN. This allows
site administrators to establish policy about DNS updates. The DHCID
RR does not establish any policy itself.
Updaters use data from a DHCP client's request and the domain name
Stapp, et al. Expires August 13, 2005 [Page 6]
Internet-Draft The DHCID RR February 2005
that the client desires to use to compute a client identity hash, and
then compare that hash to the data in any DHCID RRs on the name that
they wish to associate with the client's IP address. If an updater
discovers DHCID RRs whose RDATA does not match the client identity
that they have computed, the updater SHOULD conclude that a different
client is currently associated with the name in question. The
updater SHOULD then proceed according to the site's administrative
policy. That policy might dictate that a different name be selected,
or it might permit the updater to continue.
6. Security Considerations
The DHCID record as such does not introduce any new security problems
into the DNS. In order to avoid exposing private information about
DHCP clients to public scrutiny, a one-way hash is used to obscure
all client information. In order to make it difficult to 'track' a
client by examining the names associated with a particular hash
value, the FQDN is included in the hash computation. Thus, the RDATA
is dependent on both the DHCP client identification data and on each
FQDN associated with the client.
Administrators should be wary of permitting unsecured DNS updates to
zones which are exposed to the global Internet. Both DHCP clients
and servers SHOULD use some form of update authentication (e.g., TSIG
[11]) when performing DNS updates.
7. IANA Considerations
IANA is requested to allocate an RR type number for the DHCID record
type.
This specification defines a new number-space for the 16-bit type
codes associated with the DHCID RR. IANA is requested to establish a
registry of the values for this number-space.
Three initial values are assigned in Section 3.3, and the value
0xFFFF is reserved for future use. New DHCID RR type codes are
tentatively assigned after the specification for the associated type
code, published as an Internet Draft, has received expert review by a
designated expert. The final assignment of DHCID RR type codes is
through Standards Action, as defined in RFC 2434 [6].
8. Acknowledgements
Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz, and
Ralph Droms for their review and suggestions.
Stapp, et al. Expires August 13, 2005 [Page 7]
Internet-Draft The DHCID RR February 2005
9. References
9.1 Normative References
[1] Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among
DHCP Clients (draft-ietf-dhc-dns-resolution-*)", July 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[4] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
9.2 Informative References
[7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[8] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, May 2000.
[12] Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers
for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*)", February 2004.
Stapp, et al. Expires August 13, 2005 [Page 8]
Internet-Draft The DHCID RR February 2005
Authors' Addresses
Mark Stapp
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
Phone: 978.936.1535
Email: mjs@cisco.com
Ted Lemon
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
USA
Email: mellon@nominum.com
Andreas Gustafsson
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
USA
Email: gson@nominum.com
Stapp, et al. Expires August 13, 2005 [Page 9]
Internet-Draft The DHCID RR February 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Stapp, et al. Expires August 13, 2005 [Page 10]

1397
contrib/bind9/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt Normal file
View File

File diff suppressed because it is too large Load Diff

616
contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt Normal file
View File

@ -0,0 +1,616 @@
Network Working Group S. Weiler
Internet-Draft SPARTA, Inc
Updates: 4034, 4035 (if approved) May 23, 2005
Expires: November 24, 2005
Clarifications and Implementation Notes for DNSSECbis
draft-ietf-dnsext-dnssec-bis-updates-01
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 24, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document is a collection of minor technical clarifications to
the DNSSECbis document set. It is meant to serve as a resource to
implementors as well as an interim repository of possible DNSSECbis
errata.
Weiler Expires November 24, 2005 [Page 1]
Internet-Draft DNSSECbis Implementation Notes May 2005
Proposed additions in future versions
An index sorted by the section of DNSSECbis being clarified.
A list of proposed protocol changes being made in other documents,
such as NSEC3 and Epsilon. This document would not make those
changes, merely provide an index into the documents that are making
changes.
Changes between -00 and -01
Document significantly restructured.
Added section on QTYPE=ANY.
Changes between personal submission and first WG draft
Added Section 2.1 based on namedroppers discussions from March 9-10,
2005.
Added Section 3.4, Section 3.3, Section 4.3, and Section 2.2.
Added the DNSSECbis RFC numbers.
Figured out the confusion in Section 4.1.
Weiler Expires November 24, 2005 [Page 2]
Internet-Draft DNSSECbis Implementation Notes May 2005
Table of Contents
1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4
1.1 Structure of this Document . . . . . . . . . . . . . . . . 4
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Significant Concerns . . . . . . . . . . . . . . . . . . . . . 4
2.1 Clarifications on Non-Existence Proofs . . . . . . . . . . 4
2.2 Empty Non-Terminal Proofs . . . . . . . . . . . . . . . . 5
2.3 Validating Responses to an ANY Query . . . . . . . . . . . 5
3. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5
3.1 Unknown DS Message Digest Algorithms . . . . . . . . . . . 5
3.2 Private Algorithms . . . . . . . . . . . . . . . . . . . . 6
3.3 Caution About Local Policy and Multiple RRSIGs . . . . . . 6
3.4 Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7
4. Minor Corrections and Clarifications . . . . . . . . . . . . . 7
4.1 Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 7
4.2 Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 7
4.3 Errors in Examples . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1 Normative References . . . . . . . . . . . . . . . . . . . 8
7.2 Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 11
Weiler Expires November 24, 2005 [Page 3]
Internet-Draft DNSSECbis Implementation Notes May 2005
1. Introduction and Terminology
This document lists some minor clarifications and corrections to
DNSSECbis, as described in [1], [2], and [3].
It is intended to serve as a resource for implementors and as a
repository of items that need to be addressed when advancing the
DNSSECbis documents from Proposed Standard to Draft Standard.
In this version (-01 of the WG document), feedback is particularly
solicited on the structure of the document and whether the text in
the recently added sections is correct and sufficient.
Proposed substantive additions to this document should be sent to the
namedroppers mailing list as well as to the editor of this document.
The editor would greatly prefer text suitable for direct inclusion in
this document.
1.1 Structure of this Document
The clarifications to DNSSECbis are sorted according to the editor's
impression of their importance, starting with ones which could, if
ignored, lead to security and stability problems and progressing down
to clarifications that are likely to have little operational impact.
Mere typos and awkward phrasings are not addressed unless they could
lead to misinterpretation of the DNSSECbis documents.
1.2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
2. Significant Concerns
This section provides clarifications that, if overlooked, could lead
to security issues or major interoperability problems.
2.1 Clarifications on Non-Existence Proofs
RFC4035 Section 5.4 slightly underspecifies the algorithm for
checking non-existence proofs. In particular, the algorithm there
might incorrectly allow the NSEC from the parent side of a zone cut
to prove the non-existence of either other RRs at that name in the
child zone or other names in the child zone. It might also allow a
NSEC at the same name as a DNAME to prove the non-existence of names
beneath that DNAME.
Weiler Expires November 24, 2005 [Page 4]
Internet-Draft DNSSECbis Implementation Notes May 2005
A parent-side delegation NSEC (one with the NS bit set, but no SOA
bit set, and with a singer field that's shorter than the owner name)
must not be used to assume non-existence of any RRs below that zone
cut (both RRs at that ownername and at ownernames with more leading
labels, no matter their content). Similarly, an NSEC with the DNAME
bit set must not be used to assume the non-existence of any
descendant of that NSEC's owner name.
2.2 Empty Non-Terminal Proofs
To be written, based on Roy Arends' May 11th message to namedroppers.
2.3 Validating Responses to an ANY Query
RFC4035 does not address now to validate responses when QTYPE=*. As
described in Section 6.2.2 of RFC1034, a proper response to QTYPE=*
may include a subset of the RRsets at a given name -- it is not
necessary to include all RRsets at the QNAME in the response.
When validating a response to QTYPE=*, validate all received RRsets
that match QNAME and QCLASS. If any of those RRsets fail validation,
treat the answer as Bogus. If there are no RRsets matching QNAME and
QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as
clarified in this document). To be clear, a validator must not
insist on receiving all records at the QNAME in response to QTYPE=*.
3. Interoperability Concerns
3.1 Unknown DS Message Digest Algorithms
Section 5.2 of RFC4035 includes rules for how to handle delegations
to zones that are signed with entirely unsupported algorithms, as
indicated by the algorithms shown in those zone's DS RRsets. It does
not explicitly address how to handle DS records that use unsupported
message digest algorithms. In brief, DS records using unknown or
unsupported message digest algorithms MUST be treated the same way as
DS records referring to DNSKEY RRs of unknown or unsupported
algorithms.
The existing text says:
If the validator does not support any of the algorithms listed
in an authenticated DS RRset, then the resolver has no supported
authentication path leading from the parent to the child. The
resolver should treat this case as it would the case of an
authenticated NSEC RRset proving that no DS RRset exists, as
described above.
Weiler Expires November 24, 2005 [Page 5]
Internet-Draft DNSSECbis Implementation Notes May 2005
To paraphrase the above, when determining the security status of a
zone, a validator discards (for this purpose only) any DS records
listing unknown or unsupported algorithms. If none are left, the
zone is treated as if it were unsigned.
Modified to consider DS message digest algorithms, a validator also
discards any DS records using unknown or unsupported message digest
algorithms.
3.2 Private Algorithms
As discussed above, section 5.2 of RFC4035 requires that validators
make decisions about the security status of zones based on the public
key algorithms shown in the DS records for those zones. In the case
of private algorithms, as described in RFC4034 Appendix A.1.1, the
eight-bit algorithm field in the DS RR is not conclusive about what
algorithm(s) is actually in use.
If no private algorithms appear in the DS set or if any supported
algorithm appears in the DS set, no special processing will be
needed. In the remaining cases, the security status of the zone
depends on whether or not the resolver supports any of the private
algorithms in use (provided that these DS records use supported hash
functions, as discussed in Section 3.1). In these cases, the
resolver MUST retrieve the corresponding DNSKEY for each private
algorithm DS record and examine the public key field to determine the
algorithm in use. The security-aware resolver MUST ensure that the
hash of the DNSKEY RR's owner name and RDATA matches the digest in
the DS RR. If they do not match, and no other DS establishes that
the zone is secure, the referral should be considered BAD data, as
discussed in RFC4035.
This clarification facilitates the broader use of private algorithms,
as suggested by [5].
3.3 Caution About Local Policy and Multiple RRSIGs
When multiple RRSIGs cover a given RRset, RFC4035 Section 5.3.3
suggests that "the local resolver security policy determines whether
the resolver also has to test these RRSIG RRs and how to resolve
conflicts if these RRSIG RRs lead to differing results." In most
cases, a resolver would be well advised to accept any valid RRSIG as
sufficient. If the first RRSIG tested fails validation, a resolver
would be well advised to try others, giving a successful validation
result if any can be validated and giving a failure only if all
RRSIGs fail validation.
If a resolver adopts a more restrictive policy, there's a danger that
Weiler Expires November 24, 2005 [Page 6]
Internet-Draft DNSSECbis Implementation Notes May 2005
properly-signed data might unnecessarily fail validation, perhaps
because of cache timing issues. Furthermore, certain zone management
techniques, like the Double Signature Zone-signing Key Rollover
method described in section 4.2.1.2 of [6] might not work reliably.
3.4 Key Tag Calculation
RFC4034 Appendix B.1 incorrectly defines the Key Tag field
calculation for algorithm 1. It correctly says that the Key Tag is
the most significant 16 of the least significant 24 bits of the
public key modulus. However, RFC4034 then goes on to incorrectly say
that this is 4th to last and 3rd to last octets of the public key
modulus. It is, in fact, the 3rd to last and 2nd to last octets.
4. Minor Corrections and Clarifications
4.1 Finding Zone Cuts
Appendix C.8 of RFC4035 discusses sending DS queries to the servers
for a parent zone. To do that, a resolver may first need to apply
special rules to discover what those servers are.
As explained in Section 3.1.4.1 of RFC4035, security-aware name
servers need to apply special processing rules to handle the DS RR,
and in some situations the resolver may also need to apply special
rules to locate the name servers for the parent zone if the resolver
does not already have the parent's NS RRset. Section 4.2 of RFC4035
specifies a mechanism for doing that.
4.2 Clarifications on DNSKEY Usage
Questions of the form "can I use a different DNSKEY for signing the
X" have occasionally arisen.
The short answer is "yes, absolutely". You can even use a different
DNSKEY for each RRset in a zone, subject only to practical limits on
the size of the DNSKEY RRset. However, be aware that there is no way
to tell resolvers what a particularly DNSKEY is supposed to be used
for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to
authenticate any RRset in the zone. For example, if a weaker or less
trusted DNSKEY is being used to authenticate NSEC RRsets or all
dynamically updated records, that same DNSKEY can also be used to
sign any other RRsets from the zone.
Furthermore, note that the SEP bit setting has no effect on how a
DNSKEY may be used -- the validation process is specifically
prohibited from using that bit by RFC4034 section 2.1.2. It possible
to use a DNSKEY without the SEP bit set as the sole secure entry
Weiler Expires November 24, 2005 [Page 7]
Internet-Draft DNSSECbis Implementation Notes May 2005
point to the zone, yet use a DNSKEY with the SEP bit set to sign all
RRsets in the zone (other than the DNSKEY RRset). It's also possible
to use a single DNSKEY, with or without the SEP bit set, to sign the
entire zone, including the DNSKEY RRset itself.
4.3 Errors in Examples
The text in RFC4035 Section C.1 refers to the examples in B.1 as
"x.w.example.com" while B.1 uses "x.w.example". This is painfully
obvious in the second paragraph where it states that the RRSIG labels
field value of 3 indicates that the answer was not the result of
wildcard expansion. This is true for "x.w.example" but not for
"x.w.example.com", which of course has a label count of 4
(antithetically, a label count of 3 would imply the answer was the
result of a wildcard expansion).
The first paragraph of RFC4035 Section C.6 also has a minor error:
the reference to "a.z.w.w.example" should instead be "a.z.w.example",
as in the previous line.
5. IANA Considerations
This document specifies no IANA Actions.
6. Security Considerations
This document does not make fundamental changes to the DNSSEC
protocol, as it was generally understood when DNSSECbis was
published. It does, however, address some ambiguities and omissions
in those documents that, if not recognized and addressed in
implementations, could lead to security failures. In particular, the
validation algorithm clarifications in Section 2 are critical for
preserving the security properties DNSSEC offers. Furthermore,
failure to address some of the interoperability concerns in Section 3
could limit the ability to later change or expand DNSSEC, including
by adding new algorithms.
7. References
7.1 Normative References
[1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
Weiler Expires November 24, 2005 [Page 8]
Internet-Draft DNSSECbis Implementation Notes May 2005
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
7.2 Informative References
[5] Blacka, D., "DNSSEC Experiments",
draft-blacka-dnssec-experiments-00 (work in progress),
December 2004.
[6] Gieben, R. and O. Kolkman, "DNSSEC Operational Practices",
draft-ietf-dnsop-dnssec-operational-practices-04 (work in
progress), May 2005.
Author's Address
Samuel Weiler
SPARTA, Inc
7075 Samuel Morse Drive
Columbia, Maryland 21046
US
Email: weiler@tislabs.com
Appendix A. Acknowledgments
The editor is extremely grateful to those who, in addition to finding
errors and omissions in the DNSSECbis document set, have provided
text suitable for inclusion in this document.
The lack of specificity about handling private algorithms, as
described in Section 3.2, and the lack of specificity in handling ANY
queries, as described in Section 2.3, were discovered by David
Blacka.
The error in algorithm 1 key tag calculation, as described in
Section 3.4, was found by Abhijit Hayatnagarkar. Donald Eastlake
contributed text for Section 3.4.
The bug relating to delegation NSEC RR's in Section 2.1 was found by
Roy Badami. Roy Arends found the related problem with DNAME.
The errors in the RFC4035 examples were found by Roy Arends, who also
contributed text for Section 4.3 of this document.
Weiler Expires November 24, 2005 [Page 9]
Internet-Draft DNSSECbis Implementation Notes May 2005
The editor would like to thank Olafur Gudmundsson and Scott Rose for
their substantive comments on the text of this document.
Weiler Expires November 24, 2005 [Page 10]
Internet-Draft DNSSECbis Implementation Notes May 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Weiler Expires November 24, 2005 [Page 11]

784
contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt Normal file
View File

@ -0,0 +1,784 @@
DNSEXT D. Blacka
Internet-Draft Verisign, Inc.
Expires: January 19, 2006 July 18, 2005
DNSSEC Experiments
draft-ietf-dnsext-dnssec-experiments-01
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 January 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
In the long history of the development of the DNS security extensions
[1] (DNSSEC), a number of alternate methodologies and modifications
have been proposed and rejected for practical, rather than strictly
technical, reasons. There is a desire to be able to experiment with
these alternate methods in the public DNS. This document describes a
methodology for deploying alternate, non-backwards-compatible, DNSSEC
methodologies in an experimental fashion without disrupting the
deployment of standard DNSSEC.
Blacka Expires January 19, 2006 [Page 1]
Internet-Draft DNSSEC Experiments July 2005
Table of Contents
1. Definitions and Terminology . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Defining an Experiment . . . . . . . . . . . . . . . . . . . 8
6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 9
7. Transitions . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1 Normative References . . . . . . . . . . . . . . . . . . 13
10.2 Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . 14
Blacka Expires January 19, 2006 [Page 2]
Internet-Draft DNSSEC Experiments July 2005
1. Definitions and Terminology
Throughout this document, familiarity with the DNS system (RFC 1035
[4]) and the DNS security extensions ([1], [2], and [3].
The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [5].
Blacka Expires January 19, 2006 [Page 3]
Internet-Draft DNSSEC Experiments July 2005
2. Overview
Historically, experimentation with DNSSEC alternatives has been a
problematic endeavor. There has typically been a desire to both
introduce non-backwards-compatible changes to DNSSEC, and to try
these changes on real zones in the public DNS. This creates a
problem when the change to DNSSEC would make all or part of the zone
using those changes appear bogus (bad) or otherwise broken to
existing DNSSEC-aware resolvers.
This document describes a standard methodology for setting up public
DNSSEC experiments. This methodology addresses the issue of co-
existence with standard DNSSEC and DNS by using unknown algorithm
identifiers to hide the experimental DNSSEC protocol modifications
from standard DNSSEC-aware resolvers.
Blacka Expires January 19, 2006 [Page 4]
Internet-Draft DNSSEC Experiments July 2005
3. Experiments
When discussing DNSSEC experiments, it is necessary to classify these
experiments into two broad categories:
Backwards-Compatible: describes experimental changes that, while not
strictly adhering to the DNSSEC standard, are nonetheless
interoperable with clients and server that do implement the DNSSEC
standard.
Non-Backwards-Compatible: describes experiments that would cause a
standard DNSSEC-aware resolver to (incorrectly) determine that all
or part of a zone is bogus, or to otherwise not interoperable with
standard DNSSEC clients and servers.
Not included in these terms are experiments with the core DNS
protocol itself.
The methodology described in this document is not necessary for
backwards-compatible experiments, although it certainly could be used
if desired.
Note that, in essence, this metholodolgy would also be used to
introduce a new DNSSEC algorithm, independently from any DNSSEC
experimental protocol change.
Blacka Expires January 19, 2006 [Page 5]
Internet-Draft DNSSEC Experiments July 2005
4. Method
The core of the methodology is the use of strictly "unknown"
algorithms to sign the experimental zone, and more importantly,
having only unknown algorithm DS records for the delegation to the
zone at the parent.
This technique works because of the way DNSSEC-compliant validators
are expected to work in the presence of a DS set with only unknown
algorithms. From [3], Section 5.2:
If the validator does not support any of the algorithms listed in
an authenticated DS RRset, then the resolver has no supported
authentication path leading from the parent to the child. The
resolver should treat this case as it would the case of an
authenticated NSEC RRset proving that no DS RRset exists, as
described above.
And further:
If the resolver does not support any of the algorithms listed in
an authenticated DS RRset, then the resolver will not be able to
verify the authentication path to the child zone. In this case,
the resolver SHOULD treat the child zone as if it were unsigned.
While this behavior isn't strictly mandatory (as marked by MUST), it
is unlikely that a validator would not implement the behavior, or,
more to the point, it will not violate this behavior in an unsafe way
(see below (Section 6).)
Because we are talking about experiments, it is RECOMMENDED that
private algorithm numbers be used (see [2], appendix A.1.1. Note
that secure handling of private algorithms requires special handing
by the validator logic. See [6] for futher details.) Normally,
instead of actually inventing new signing algorithms, the recommended
path is to create alternate algorithm identifiers that are aliases
for the existing, known algorithms. While, strictly speaking, it is
only necessary to create an alternate identifier for the mandatory
algorithms, it is RECOMMENDED that all OPTIONAL defined algorithms be
aliased as well.
It is RECOMMENDED that for a particular DNSSEC experiment, a
particular domain name base is chosen for all new algorithms, then
the algorithm number (or name) is prepended to it. For example, for
experiment A, the base name of "dnssec-experiment-a.example.com" is
chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
defined to be "3.dnssec-experiment-a.example.com" and "5.dnssec-
experiment-a.example.com". However, any unique identifier will
Blacka Expires January 19, 2006 [Page 6]
Internet-Draft DNSSEC Experiments July 2005
suffice.
Using this method, resolvers (or, more specificially, DNSSEC
validators) essentially indicate their ability to understand the
DNSSEC experiment's semantics by understanding what the new algorithm
identifiers signify.
This method creates two classes of DNSSEC-aware servers and
resolvers: servers and resolvers that are aware of the experiment
(and thus recognize the experiments algorithm identifiers and
experimental semantics), and servers and resolvers that are unware of
the experiment.
This method also precludes any zone from being both in an experiment
and in a classic DNSSEC island of security. That is, a zone is
either in an experiment and only experimentally validatable, or it
isn't.
Blacka Expires January 19, 2006 [Page 7]
Internet-Draft DNSSEC Experiments July 2005
5. Defining an Experiment
The DNSSEC experiment must define the particular set of (previously
unknown) algorithms that identify the experiment, and define what
each unknown algorithm identifier means. Typically, unless the
experiment is actually experimenting with a new DNSSEC algorithm,
this will be a mapping of private algorithm identifiers to existing,
known algorithms.
Normally the experiment will choose a DNS name as the algorithm
identifier base. This DNS name SHOULD be under the control of the
authors of the experiment. Then the experiment will define a mapping
between known mandatory and optional algorithms into this private
algorithm identifier space. Alternately, the experiment MAY use the
OID private algorithm space instead (using algorithm number 254), or
may choose non-private algorithm numbers, although this would require
an IANA allocation (see below (Section 9).)
For example, an experiment might specify in its description the DNS
name "dnssec-experiment-a.example.com" as the base name, and provide
the mapping of "3.dnssec-experiment-a.example.com" is an alias of
DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is
an alias of DNSSEC algorithm 5 (RSASHA1).
Resolvers MUST then only recognize the experiment's semantics when
present in a zone signed by one or more of these private algorithms.
In general, however, resolvers involved in the experiment are
expected to understand both standard DNSSEC and the defined
experimental DNSSEC protocol, although this isn't required.
Blacka Expires January 19, 2006 [Page 8]
Internet-Draft DNSSEC Experiments July 2005
6. Considerations
There are a number of considerations with using this methodology.
1. Under some circumstances, it may be that the experiment will not
be sufficiently masked by this technique and may cause resolution
problem for resolvers not aware of the experiment. For instance,
the resolver may look at the not validatable response and
conclude that the response is bogus, either due to local policy
or implementation details. This is not expected to be the common
case, however.
2. In general, it will not be possible for DNSSEC-aware resolvers
not aware of the experiment to build a chain of trust through an
experimental zone.
Blacka Expires January 19, 2006 [Page 9]
Internet-Draft DNSSEC Experiments July 2005
7. Transitions
If an experiment is successful, there may be a desire to move the
experiment to a standards-track extension. One way to do so would be
to move from private algorithm numbers to IANA allocated algorithm
numbers, with otherwise the same meaning. This would still leave a
divide between resolvers that understood the extension versus
resolvers that did not. It would, in essence, create an additional
version of DNSSEC.
An alternate technique might be to do a typecode rollover, thus
actually creating a definitive new version of DNSSEC. There may be
other transition techniques available, as well.
Blacka Expires January 19, 2006 [Page 10]
Internet-Draft DNSSEC Experiments July 2005
8. Security Considerations
Zones using this methodology will be considered insecure by all
resolvers except those aware of the experiment. It is not generally
possible to create a secure delegation from an experimental zone that
will be followed by resolvers unaware of the experiment.
Blacka Expires January 19, 2006 [Page 11]
Internet-Draft DNSSEC Experiments July 2005
9. IANA Considerations
IANA may need to allocate new DNSSEC algorithm numbers if that
transition approach is taken, or the experiment decides to use
allocated numbers to begin with. No IANA action is required to
deploy an experiment using private algorithm identifiers.
Blacka Expires January 19, 2006 [Page 12]
Internet-Draft DNSSEC Experiments July 2005
10. References
10.1 Normative References
[1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
10.2 Informative References
[4] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] Weiler, S., "Clarifications and Implementation Notes for
DNSSECbis", draft-weiler-dnsext-dnssec-bis-updates-00 (work in
progress), March 2005.
Author's Address
David Blacka
Verisign, Inc.
21355 Ridgetop Circle
Dulles, VA 20166
US
Phone: +1 703 948 3200
Email: davidb@verisign.com
URI: http://www.verisignlabs.com
Blacka Expires January 19, 2006 [Page 13]
Internet-Draft DNSSEC Experiments July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Blacka Expires January 19, 2006 [Page 14]

560
contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-00.txt Normal file
View File

@ -0,0 +1,560 @@
Network Working Group S. Weiler
Internet-Draft SPARTA, Inc
Updates: 4034, 4035 (if approved) J. Ihren
Expires: November 13, 2005 Autonomica AB
May 12, 2005
Minimally Covering NSEC Records and DNSSEC On-line Signing
draft-ietf-dnsext-dnssec-online-signing-00
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 13, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes how to construct DNSSEC NSEC resource records
that cover a smaller range of names than called for by RFC4034. By
generating and signing these records on demand, authoritative name
servers can effectively stop the disclosure of zone contents
otherwise made possible by walking the chain of NSEC records in a
signed zone.
Weiler & Ihren Expires November 13, 2005 [Page 1]
Internet-Draft NSEC Epsilon May 2005
Changes from weiler-01 to ietf-00
Inserted RFC numbers for 4033, 4034, and 4035.
Specified contents of bitmap field in synthesized NSEC RR's, pointing
out that this relaxes a constraint in 4035. Added 4035 to the
Updates header.
Changes from weiler-00 to weiler-01
Clarified that this updates RFC4034 by relaxing requirements on the
next name field.
Added examples covering wildcard names.
In the 'better functions' section, reiterated that perfect functions
aren't needed.
Added a reference to RFC 2119.
Weiler & Ihren Expires November 13, 2005 [Page 2]
Internet-Draft NSEC Epsilon May 2005
Table of Contents
1. Introduction and Terminology . . . . . . . . . . . . . . . . 4
2. Minimally Covering NSEC Records . . . . . . . . . . . . . . 4
3. Better Increment & Decrement Functions . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . 10
Weiler & Ihren Expires November 13, 2005 [Page 3]
Internet-Draft NSEC Epsilon May 2005
1. Introduction and Terminology
With DNSSEC [1], an NSEC record lists the next instantiated name in
its zone, proving that no names exist in the "span" between the
NSEC's owner name and the name in the "next name" field. In this
document, an NSEC record is said to "cover" the names between its
owner name and next name.
Through repeated queries that return NSEC records, it is possible to
retrieve all of the names in the zone, a process commonly called
"walking" the zone. Some zone owners have policies forbidding zone
transfers by arbitrary clients; this side-effect of the NSEC
architecture subverts those policies.
This document presents a way to prevent zone walking by constructing
NSEC records that cover fewer names. These records can make zone
walking take approximately as many queries as simply asking for all
possible names in a zone, making zone walking impractical. Some of
these records must be created and signed on demand, which requires
on-line private keys. Anyone contemplating use of this technique is
strongly encouraged to review the discussion of the risks of on-line
signing in Section 5.
The technique presented here may be useful to a zone owner that wants
to use DNSSEC, is concerned about exposure of its zone contents via
zone walking, and is willing to bear the costs of on-line signing.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
2. Minimally Covering NSEC Records
This mechanism involves changes to NSEC records for instantiated
names, which can still be generated and signed in advance, as well as
the on-demand generation and signing of new NSEC records whenever a
name must be proven not to exist.
In the 'next name' field of instantiated names' NSEC records, rather
than list the next instantiated name in the zone, list any name that
falls lexically after the NSEC's owner name and before the next
instantiated name in the zone, according to the ordering function in
RFC4034 [2] section 6.2. This relaxes the requirement in section
4.1.1 of RFC4034 that the 'next name' field contains the next owner
name in the zone. This change is expected to be fully compatible
with all existing DNSSEC validators. These NSEC records are returned
whenever proving something specifically about the owner name (e.g.
that no resource records of a given type appear at that name).
Weiler & Ihren Expires November 13, 2005 [Page 4]
Internet-Draft NSEC Epsilon May 2005
Whenever an NSEC record is needed to prove the non-existence of a
name, a new NSEC record is dynamically produced and signed. The new
NSEC record has an owner name lexically before the QNAME but
lexically following any existing name and a 'next name' lexically
following the QNAME but before any existing name.
The generated NSEC record's type bitmap SHOULD have the RRSIG and
NSEC bits set and SHOULD NOT have any other bits set. This relaxes
the requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
names that did not exist before the zone wsa signed.
The functions to generate the lexically following and proceeding
names need not be perfect nor consistent, but the generated NSEC
records must not cover any existing names. Furthermore, this
technique works best when the generated NSEC records cover as few
names as possible.
An NSEC record denying the existence of a wildcard may be generated
in the same way. Since the NSEC record covering a non-existent
wildcard is likely to be used in response to many queries,
authoritative name servers using the techniques described here may
want to pregenerate or cache that record and its corresponding RRSIG.
For example, a query for an A record at the non-instantiated name
example.com might produce the following two NSEC records, the first
denying the existence of the name example.com and the second denying
the existence of a wildcard:
exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
).com 3600 IN NSEC +.com ( RRSIG NSEC )
Before answering a query with these records, an authoritative server
must test for the existence of names between these endpoints. If the
generated NSEC would cover existing names (e.g. exampldd.com or
*bizarre.example.com), a better increment or decrement function may
be used or the covered name closest to the QNAME could be used as the
NSEC owner name or next name, as appropriate. If an existing name is
used as the NSEC owner name, that name's real NSEC record MUST be
returned. Using the same example, assuming an exampldd.com
delegation exists, this record might be returned from the parent:
exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
Like every authoritative record in the zone, each generated NSEC
record MUST have corresponding RRSIGs generated using each algorithm
(but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
described in RFC4035 [3] section 2.2. To minimize the number of
Weiler & Ihren Expires November 13, 2005 [Page 5]
Internet-Draft NSEC Epsilon May 2005
signatures that must be generated, a zone may wish to limit the
number of algorithms in its DNSKEY RRset.
3. Better Increment & Decrement Functions
Section 6.2 of RFC4034 defines a strict ordering of DNS names.
Working backwards from that definition, it should be possible to
define increment and decrement functions that generate the
immediately following and preceding names, respectively. This
document does not define such functions. Instead, this section
presents functions that come reasonably close to the perfect ones.
As described above, an authoritative server should still ensure than
no generated NSEC covers any existing name.
To increment a name, add a leading label with a single null (zero-
value) octet.
To decrement a name, decrement the last character of the leftmost
label, then fill that label to a length of 63 octets with octets of
value 255. To decrement a null (zero-value) octet, remove the octet
-- if an empty label is left, remove the label. Defining this
function numerically: fill the left-most label to its maximum length
with zeros (numeric, not ASCII zeros) and subtract one.
In response to a query for the non-existent name foo.example.com,
these functions produce NSEC records of:
fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
The first of these NSEC RRs proves that no exact match for
foo.example.com exists, and the second proves that there is no
wildcard in example.com.
Both of these functions are imperfect: they don't take into account
constraints on number of labels in a name nor total length of a name.
As noted in the previous section, though, this technique does not
depend on the use of perfect increment or decrement functions: it is
sufficient to test whether any instantiated names fall into the span
Weiler & Ihren Expires November 13, 2005 [Page 6]
Internet-Draft NSEC Epsilon May 2005
covered by the generated NSEC and, if so, substitute those
instantiated owner names for the NSEC owner name or next name, as
appropriate.
4. IANA Considerations
Per RFC4041, IANA should think carefully about the protection of
their immortal souls.
5. Security Considerations
This approach requires on-demand generation of RRSIG records. This
creates several new vulnerabilities.
First, on-demand signing requires that a zone's authoritative servers
have access to its private keys. Storing private keys on well-known
internet-accessible servers may make them more vulnerable to
unintended disclosure.
Second, since generation of public key signatures tends to be
computationally demanding, the requirement for on-demand signing
makes authoritative servers vulnerable to a denial of service attack.
Lastly, if the increment and decrement functions are predictable, on-
demand signing may enable a chosen-plaintext attack on a zone's
private keys. Zones using this approach should attempt to use
cryptographic algorithms that are resistant to chosen-plaintext
attacks. It's worth noting that while DNSSEC has a "mandatory to
implement" algorithm, that is a requirement on resolvers and
validators -- there is no requirement that a zone be signed with any
given algorithm.
The success of using minimally covering NSEC record to prevent zone
walking depends greatly on the quality of the increment and decrement
functions chosen. An increment function that chooses a name
obviously derived from the next instantiated name may be easily
reverse engineered, destroying the value of this technique. An
increment function that always returns a name close to the next
instantiated name is likewise a poor choice. Good choices of
increment and decrement functions are the ones that produce the
immediately following and preceding names, respectively, though zone
administrators may wish to use less perfect functions that return
more human-friendly names than the functions described in Section 3
above.
Another obvious but misguided concern is the danger from synthesized
NSEC records being replayed. It's possible for an attacker to replay
an old but still validly signed NSEC record after a new name has been
Weiler & Ihren Expires November 13, 2005 [Page 7]
Internet-Draft NSEC Epsilon May 2005
added in the span covered by that NSEC, incorrectly proving that
there is no record at that name. This danger exists with DNSSEC as
defined in [-bis]. The techniques described here actually decrease
the danger, since the span covered by any NSEC record is smaller than
before. Choosing better increment and decrement functions will
further reduce this danger.
6. Normative References
[1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Samuel Weiler
SPARTA, Inc
7075 Samuel Morse Drive
Columbia, Maryland 21046
US
Email: weiler@tislabs.com
Johan Ihren
Autonomica AB
Bellmansgatan 30
Stockholm SE-118 47
Sweden
Email: johani@autonomica.se
Appendix A. Acknowledgments
Many individuals contributed to this design. They include, in
addition to the authors of this document, Olaf Kolkman, Ed Lewis,
Weiler & Ihren Expires November 13, 2005 [Page 8]
Internet-Draft NSEC Epsilon May 2005
Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
Jakob Schlyter, Bill Manning, and Joao Damas.
The key innovation of this document, namely that perfect increment
and decrement functions are not necessary, arose during a discussion
among the above-listed people at the RIPE49 meeting in September
2004.
Weiler & Ihren Expires November 13, 2005 [Page 9]
Internet-Draft NSEC Epsilon May 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Weiler & Ihren Expires November 13, 2005 [Page 10]

896
contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt Normal file
View File

@ -0,0 +1,896 @@
DNSEXT R. Arends
Internet-Draft Telematica Instituut
Expires: January 19, 2006 M. Kosters
D. Blacka
Verisign, Inc.
July 18, 2005
DNSSEC Opt-In
draft-ietf-dnsext-dnssec-opt-in-07
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 January 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
In the DNS security extensions (DNSSEC, defined in RFC 4033 [3], RFC
4034 [4], and RFC 4035 [5]), delegations to unsigned subzones are
cryptographically secured. Maintaining this cryptography is not
practical or necessary. This document describes an experimental
"Opt-In" model that allows administrators to omit this cryptography
and manage the cost of adopting DNSSEC with large zones.
Arends, et al. Expires January 19, 2006 [Page 1]
Internet-Draft DNSSEC Opt-In July 2005
Table of Contents
1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Experimental Status . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 4
4.1 Server Considerations . . . . . . . . . . . . . . . . . . 5
4.1.1 Delegations Only . . . . . . . . . . . . . . . . . . . 5
4.1.2 Insecure Delegation Responses . . . . . . . . . . . . 6
4.1.3 Wildcards and Opt-In . . . . . . . . . . . . . . . . . 6
4.1.4 Dynamic Update . . . . . . . . . . . . . . . . . . . . 7
4.2 Client Considerations . . . . . . . . . . . . . . . . . . 7
4.2.1 Delegations Only . . . . . . . . . . . . . . . . . . . 7
4.2.2 Validation Process Changes . . . . . . . . . . . . . . 7
4.2.3 NSEC Record Caching . . . . . . . . . . . . . . . . . 8
4.2.4 Use of the AD bit . . . . . . . . . . . . . . . . . . 8
5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1 Normative References . . . . . . . . . . . . . . . . . . . 13
11.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
A. Implementing Opt-In using "Views" . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 16
Arends, et al. Expires January 19, 2006 [Page 2]
Internet-Draft DNSSEC Opt-In July 2005
1. Definitions and Terminology
Throughout this document, familiarity with the DNS system (RFC 1035
[1]), DNS security extensions ([3], [4], and [5], referred to in this
document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090
[10]) is assumed.
The following abbreviations and terms are used in this document:
RR: is used to refer to a DNS resource record.
RRset: refers to a Resource Record Set, as defined by [8]. In this
document, the RRset is also defined to include the covering RRSIG
records, if any exist.
signed name: refers to a DNS name that has, at minimum, a (signed)
NSEC record.
unsigned name: refers to a DNS name that does not (at least) have a
NSEC record.
covering NSEC record/RRset: is the NSEC record used to prove
(non)existence of a particular name or RRset. This means that for
a RRset or name 'N', the covering NSEC record has the name 'N', or
has an owner name less than 'N' and "next" name greater than 'N'.
delegation: refers to a NS RRset with a name different from the
current zone apex (non-zone-apex), signifying a delegation to a
subzone.
secure delegation: refers to a signed name containing a delegation
(NS RRset), and a signed DS RRset, signifying a delegation to a
signed subzone.
insecure delegation: refers to a signed name containing a delegation
(NS RRset), but lacking a DS RRset, signifying a delegation to an
unsigned subzone.
Opt-In insecure delegation: refers to an unsigned name containing
only a delegation NS RRset. The covering NSEC record uses the
Opt-In methodology described in this document.
The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [7].
2. Overview
The cost to cryptographically secure delegations to unsigned zones is
high for large delegation-centric zones and zones where insecure
delegations will be updated rapidly. For these zones, the costs of
maintaining the NSEC record chain may be extremely high relative to
the gain of cryptographically authenticating existence of unsecured
zones.
This document describes an experimental method of eliminating the
Arends, et al. Expires January 19, 2006 [Page 3]
Internet-Draft DNSSEC Opt-In July 2005
superfluous cryptography present in secure delegations to unsigned
zones. Using "Opt-In", a zone administrator can choose to remove
insecure delegations from the NSEC chain. This is accomplished by
extending the semantics of the NSEC record by using a redundant bit
in the type map.
3. Experimental Status
This document describes an EXPERIMENTAL extension to DNSSEC. It
interoperates with non-experimental DNSSEC using the technique
described in [6]. This experiment is identified with the following
private algorithms (using algorithm 253):
"3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA,
and
"5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5,
RSASHA1.
Servers wishing to sign and serve zones that utilize Opt-In MUST sign
the zone with only one or more of these private algorithms. This
requires the signing tools and servers to support private algorithms,
as well as Opt-In.
Resolvers wishing to validate Opt-In zones MUST only do so when the
zone is only signed using one or more of these private algorithms.
The remainder of this document assumes that the servers and resolvers
involved are aware of and are involved in this experiment.
4. Protocol Additions
In DNSSEC, delegation NS RRsets are not signed, but are instead
accompanied by a NSEC RRset of the same name and (possibly) a DS
record. The security status of the subzone is determined by the
presence or absence of the DS RRset, cryptographically proven by the
NSEC record. Opt-In expands this definition by allowing insecure
delegations to exist within an otherwise signed zone without the
corresponding NSEC record at the delegation's owner name. These
insecure delegations are proven insecure by using a covering NSEC
record.
Since this represents a change of the interpretation of NSEC records,
resolvers must be able to distinguish between RFC standard DNSSEC
NSEC records and Opt-In NSEC records. This is accomplished by
"tagging" the NSEC records that cover (or potentially cover) insecure
delegation nodes. This tag is indicated by the absence of the NSEC
bit in the type map. Since the NSEC bit in the type map merely
indicates the existence of the record itself, this bit is redundant
Arends, et al. Expires January 19, 2006 [Page 4]
Internet-Draft DNSSEC Opt-In July 2005
and safe for use as a tag.
An Opt-In tagged NSEC record does not assert the (non)existence of
the delegations that it covers (except for a delegation with the same
name). This allows for the addition or removal of these delegations
without recalculating or resigning records in the NSEC chain.
However, Opt-In tagged NSEC records do assert the (non)existence of
other RRsets.
An Opt-In NSEC record MAY have the same name as an insecure
delegation. In this case, the delegation is proven insecure by the
lack of a DS bit in type map and the signed NSEC record does assert
the existence of the delegation.
Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC
records and standard DNSSEC NSEC records. If a NSEC record is not
Opt-In, there MUST NOT be any insecure delegations (or any other
records) between it and the RRsets indicated by the 'next domain
name' in the NSEC RDATA. If it is Opt-In, there MUST only be
insecure delegations between it and the next node indicated by the
'next domain name' in the NSEC RDATA.
In summary,
o An Opt-In NSEC type is identified by a zero-valued (or not-
specified) NSEC bit in the type bit map of the NSEC record.
o A RFC2535bis NSEC type is identified by a one-valued NSEC bit in
the type bit map of the NSEC record.
and,
o An Opt-In NSEC record does not assert the non-existence of a name
between its owner name and "next" name, although it does assert
that any name in this span MUST be an insecure delegation.
o An Opt-In NSEC record does assert the (non)existence of RRsets
with the same owner name.
4.1 Server Considerations
Opt-In imposes some new requirements on authoritative DNS servers.
4.1.1 Delegations Only
This specification dictates that only insecure delegations may exist
between the owner and "next" names of an Opt-In tagged NSEC record.
Signing tools SHOULD NOT generate signed zones that violate this
restriction. Servers SHOULD refuse to load and/or serve zones that
violate this restriction. Servers also SHOULD reject AXFR or IXFR
Arends, et al. Expires January 19, 2006 [Page 5]
Internet-Draft DNSSEC Opt-In July 2005
responses that violate this restriction.
4.1.2 Insecure Delegation Responses
When returning an Opt-In insecure delegation, the server MUST return
the covering NSEC RRset in the Authority section.
In standard DNSSEC, NSEC records already must be returned along with
the insecure delegation. The primary difference that this proposal
introduces is that the Opt-In tagged NSEC record will have a
different owner name from the delegation RRset. This may require
implementations to search for the covering NSEC RRset.
4.1.3 Wildcards and Opt-In
Standard DNSSEC describes the practice of returning NSEC records to
prove the non-existence of an applicable wildcard in non-existent
name responses. This NSEC record can be described as a "negative
wildcard proof". The use of Opt-In NSEC records changes the
necessity for this practice. For non-existent name responses when
the query name (qname) is covered by an Opt-In tagged NSEC record,
servers MAY choose to omit the wildcard proof record, and clients
MUST NOT treat the absence of this NSEC record as a validation error.
The intent of the standard DNSSEC negative wildcard proof requirement
is to prevent malicious users from undetectably removing valid
wildcard responses. In order for this cryptographic proof to work,
the resolver must be able to prove:
1. The exact qname does not exist. This is done by the "normal"
NSEC record.
2. No applicable wildcard exists. This is done by returning a NSEC
record proving that the wildcard does not exist (this is the
negative wildcard proof).
However, if the NSEC record covering the exact qname is an Opt-In
NSEC record, the resolver will not be able to prove the first part of
this equation, as the qname might exist as an insecure delegation.
Thus, since the total proof cannot be completed, the negative
wildcard proof NSEC record is not useful.
The negative wildcard proof is also not useful when returned as part
of an Opt-In insecure delegation response for a similar reason: the
resolver cannot prove that the qname does or does not exist, and
therefore cannot prove that a wildcard expansion is valid.
The presence of an Opt-In tagged NSEC record does not change the
practice of returning a NSEC along with a wildcard expansion. Even
Arends, et al. Expires January 19, 2006 [Page 6]
Internet-Draft DNSSEC Opt-In July 2005
though the Opt-In NSEC will not be able to prove that the wildcard
expansion is valid, it will prove that the wildcard expansion is not
masking any signed records.
4.1.4 Dynamic Update
Opt-In changes the semantics of Secure DNS Dynamic Update [9]. In
particular, it introduces the need for rules that describe when to
add or remove a delegation name from the NSEC chain. This document
does not attempt to define these rules. Until these rules are
defined, servers MUST NOT process DNS Dynamic Update requests against
zones that use Opt-In NSEC records. Servers SHOULD return responses
to update requests with RCODE=REFUSED.
4.2 Client Considerations
Opt-In imposes some new requirements on security-aware resolvers
(caching or otherwise).
4.2.1 Delegations Only
As stated in the "Server Considerations" section above, this
specification restricts the namespace covered by Opt-In tagged NSEC
records to insecure delegations only. Thus, resolvers MUST reject as
invalid any records that fall within an Opt-In NSEC record's span
that are not NS records or corresponding glue records.
4.2.2 Validation Process Changes
This specification does not change the resolver's resolution
algorithm. However, it does change the DNSSEC validation process.
Resolvers MUST be able to use Opt-In tagged NSEC records to
cryptographically prove the validity and security status (as
insecure) of a referral. Resolvers determine the security status of
the referred-to zone as follows:
o In standard DNSSEC, the security status is proven by the existence
or absence of a DS RRset at the same name as the delegation. The
existence of the DS RRset indicates that the referred-to zone is
signed. The absence of the DS RRset is proven using a verified
NSEC record of the same name that does not have the DS bit set in
the type map. This NSEC record MAY also be tagged as Opt-In.
o Using Opt-In, the security status is proven by the existence of a
DS record (for signed) or the presence of a verified Opt-In tagged
NSEC record that covers the delegation name. That is, the NSEC
record does not have the NSEC bit set in the type map, and the
delegation name falls between the NSEC's owner and "next" name.
Arends, et al. Expires January 19, 2006 [Page 7]
Internet-Draft DNSSEC Opt-In July 2005
Using Opt-In does not substantially change the nature of following
referrals within DNSSEC. At every delegation point, the resolver
will have cryptographic proof that the referred-to subzone is signed
or unsigned.
When receiving either an Opt-In insecure delegation response or a
non-existent name response where that name is covered by an Opt-In
tagged NSEC record, the resolver MUST NOT require proof (in the form
of a NSEC record) that a wildcard did not exist.
4.2.3 NSEC Record Caching
Caching resolvers MUST be able to retrieve the appropriate covering
Opt-In NSEC record when returning referrals that need them. This
requirement differs from standard DNSSEC in that the covering NSEC
will not have the same owner name as the delegation. Some
implementations may have to use new methods for finding these NSEC
records.
4.2.4 Use of the AD bit
The AD bit, as defined by [2] and [5], MUST NOT be set when:
o sending a Name Error (RCODE=3) response where the covering NSEC is
tagged as Opt-In.
o sending an Opt-In insecure delegation response, unless the
covering (Opt-In) NSEC record's owner name equals the delegation
name.
This rule is based on what the Opt-In NSEC record actually proves:
for names that exist between the Opt-In NSEC record's owner and
"next" names, the Opt-In NSEC record cannot prove the non-existence
or existence of the name. As such, not all data in the response has
been cryptographically verified, so the AD bit cannot be set.
5. Benefits
Using Opt-In allows administrators of large and/or changing
delegation-centric zones to minimize the overhead involved in
maintaining the security of the zone.
Opt-In accomplishes this by eliminating the need for NSEC records for
insecure delegations. This, in a zone with a large number of
delegations to unsigned subzones, can lead to substantial space
savings (both in memory and on disk). Additionally, Opt-In allows
for the addition or removal of insecure delegations without modifying
the NSEC record chain. Zones that are frequently updating insecure
delegations (e.g., TLDs) can avoid the substantial overhead of
Arends, et al. Expires January 19, 2006 [Page 8]
Internet-Draft DNSSEC Opt-In July 2005
modifying and resigning the affected NSEC records.
6. Example
Consider the zone EXAMPLE, shown below. This is a zone where all of
the NSEC records are tagged as Opt-In.
Example A: Fully Opt-In Zone.
EXAMPLE. SOA ...
EXAMPLE. RRSIG SOA ...
EXAMPLE. NS FIRST-SECURE.EXAMPLE.
EXAMPLE. RRSIG NS ...
EXAMPLE. DNSKEY ...
EXAMPLE. RRSIG DNSKEY ...
EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (
SOA NS RRSIG DNSKEY )
EXAMPLE. RRSIG NSEC ...
FIRST-SECURE.EXAMPLE. A ...
FIRST-SECURE.EXAMPLE. RRSIG A ...
FIRST-SECURE.EXAMPLE. NSEC NOT-SECURE-2.EXAMPLE. A RRSIG
FIRST-SECURE.EXAMPLE. RRSIG NSEC ...
NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE.
NS.NOT-SECURE.EXAMPLE. A ...
NOT-SECURE-2.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE.
NOT-SECURE-2.EXAMPLE NSEC SECOND-SECURE.EXAMPLE NS RRSIG
NOT-SECURE-2.EXAMPLE RRSIG NSEC ...
SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE.
SECOND-SECURE.EXAMPLE. DS ...
SECOND-SECURE.EXAMPLE. RRSIG DS ...
SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DNSKEY
SECOND-SECURE.EXAMPLE. RRSIG NSEC ...
UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE.
NS.UNSIGNED.EXAMPLE. A ...
In this example, a query for a signed RRset (e.g., "FIRST-
SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND-
SECURE.EXAMPLE A") will result in a standard DNSSEC response.
A query for a nonexistent RRset will result in a response that
differs from standard DNSSEC by: the NSEC record will be tagged as
Opt-In, there may be no NSEC record proving the non-existence of a
Arends, et al. Expires January 19, 2006 [Page 9]
Internet-Draft DNSSEC Opt-In July 2005
matching wildcard record, and the AD bit will not be set.
A query for an insecure delegation RRset (or a referral) will return
both the answer (in the Authority section) and the corresponding
Opt-In NSEC record to prove that it is not secure.
Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A
RCODE=NOERROR, AD=0
Answer Section:
Authority Section:
UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE
SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DS
SECOND-SECURE.EXAMPLE. RRSIG NSEC ...
Additional Section:
NS.UNSIGNED.EXAMPLE. A ...
In the Example A.1 zone, the EXAMPLE. node MAY use either style of
NSEC record, because there are no insecure delegations that occur
between it and the next node, FIRST-SECURE.EXAMPLE. In other words,
Example A would still be a valid zone if the NSEC record for EXAMPLE.
was changed to the following RR:
EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (SOA NS
RRSIG DNSKEY NSEC )
However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND-
SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are insecure
delegations in the range they define. (NOT-SECURE.EXAMPLE. and
UNSIGNED.EXAMPLE., respectively).
NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is
part of the NSEC chain and also covered by an Opt-In tagged NSEC
record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be
removed from the zone without modifying and resigning the prior NSEC
record. Delegations with names that fall between NOT-SECURE-
2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without
resigning any NSEC records.
7. Transition Issues
Opt-In is not backwards compatible with standard DNSSEC and is
considered experimental. Standard DNSSEC compliant implementations
would not recognize Opt-In tagged NSEC records as different from
Arends, et al. Expires January 19, 2006 [Page 10]
Internet-Draft DNSSEC Opt-In July 2005
standard NSEC records. Because of this, standard DNSSEC
implementations, if they were to validate Opt-In style responses,
would reject all Opt-In insecure delegations within a zone as
invalid. However, by only signing with private algorithms, standard
DNSSEC implementations will treat Opt-In responses as unsigned.
It should be noted that all elements in the resolution path between
(and including) the validator and the authoritative name server must
be aware of the Opt-In experiment and implement the Opt-In semantics
for successful validation to be possible. In particular, this
includes any caching middleboxes between the validator and
authoritative name server.
8. Security Considerations
Opt-In allows for unsigned names, in the form of delegations to
unsigned subzones, to exist within an otherwise signed zone. All
unsigned names are, by definition, insecure, and their validity or
existence cannot by cryptographically proven.
In general:
o Records with unsigned names (whether existing or not) suffer from
the same vulnerabilities as records in an unsigned zone. These
vulnerabilities are described in more detail in [12] (note in
particular sections 2.3, "Name Games" and 2.6, "Authenticated
Denial").
o Records with signed names have the same security whether or not
Opt-In is used.
Note that with or without Opt-In, an insecure delegation may have its
contents undetectably altered by an attacker. Because of this, the
primary difference in security that Opt-In introduces is the loss of
the ability to prove the existence or nonexistence of an insecure
delegation within the span of an Opt-In NSEC record.
In particular, this means that a malicious entity may be able to
insert or delete records with unsigned names. These records are
normally NS records, but this also includes signed wildcard
expansions (while the wildcard record itself is signed, its expanded
name is an unsigned name).
For example, if a resolver received the following response from the
example zone above:
Arends, et al. Expires January 19, 2006 [Page 11]
Internet-Draft DNSSEC Opt-In July 2005
Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A
RCODE=NOERROR
Answer Section:
Authority Section:
DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED.
EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \
RRSIG DNSKEY
EXAMPLE. RRSIG NSEC ...
Additional Section:
The resolver would have no choice but to believe that the referral to
NS.FORGED. is valid. If a wildcard existed that would have been
expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
have undetectably removed it and replaced it with the forged
delegation.
Note that being able to add a delegation is functionally equivalent
to being able to add any record type: an attacker merely has to forge
a delegation to nameserver under his/her control and place whatever
records needed at the subzone apex.
While in particular cases, this issue may not present a significant
security problem, in general it should not be lightly dismissed.
Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
In particular, zone signing tools SHOULD NOT default to Opt-In, and
MAY choose to not support Opt-In at all.
9. IANA Considerations
None.
10. Acknowledgments
The contributions, suggestions and remarks of the following persons
(in alphabetic order) to this draft are acknowledged:
Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf
Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning,
Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian
Wellington.
11. References
Arends, et al. Expires January 19, 2006 [Page 12]
Internet-Draft DNSSEC Opt-In July 2005
11.1 Normative References
[1] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[2] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
Authenticated Data (AD) bit", RFC 3655, November 2003.
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
[6] Blacka, D., "DNSSEC Experiments",
draft-ietf-dnsext-dnssec-experiments-01 (work in progress),
July 2005.
11.2 Informative References
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[8] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
RFC 2181, July 1997.
[9] Eastlake, D., "Secure Domain Name System Dynamic Update",
RFC 2137, April 1997.
[10] Lewis, E., "DNS Security Extension Clarification on Zone
Status", RFC 3090, March 2001.
[11] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
December 2001.
[12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
System (DNS)", RFC 3833, August 2004.
Arends, et al. Expires January 19, 2006 [Page 13]
Internet-Draft DNSSEC Opt-In July 2005
Authors' Addresses
Roy Arends
Telematica Instituut
Drienerlolaan 5
7522 NB Enschede
NL
Email: roy.arends@telin.nl
Mark Kosters
Verisign, Inc.
21355 Ridgetop Circle
Dulles, VA 20166
US
Phone: +1 703 948 3200
Email: markk@verisign.com
URI: http://www.verisignlabs.com
David Blacka
Verisign, Inc.
21355 Ridgetop Circle
Dulles, VA 20166
US
Phone: +1 703 948 3200
Email: davidb@verisign.com
URI: http://www.verisignlabs.com
Appendix A. Implementing Opt-In using "Views"
In many cases, it may be convenient to implement an Opt-In zone by
combining two separately maintained "views" of a zone at request
time. In this context, "view" refers to a particular version of a
zone, not to any specific DNS implementation feature.
In this scenario, one view is the secure view, the other is the
insecure (or legacy) view. The secure view consists of an entirely
signed zone using Opt-In tagged NSEC records. The insecure view
contains no DNSSEC information. It is helpful, although not
necessary, for the secure view to be a subset (minus DNSSEC records)
of the insecure view.
In addition, the only RRsets that may solely exist in the insecure
view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and
Arends, et al. Expires January 19, 2006 [Page 14]
Internet-Draft DNSSEC Opt-In July 2005
the zone apex NS RRset) MUST be signed and in the secure view.
These two views may be combined at request time to provide a virtual,
single Opt-In zone. The following algorithm is used when responding
to each query:
V_A is the secure view as described above.
V_B is the insecure view as described above.
R_A is a response generated from V_A, following RFC 2535bis.
R_B is a response generated from V_B, following DNS resolution as
per RFC 1035 [1].
R_C is the response generated by combining R_A with R_B, as
described below.
A query is DNSSEC-aware if it either has the DO bit [11] turned
on, or is for a DNSSEC-specific record type.
1. If V_A is a subset of V_B and the query is not DNSSEC-aware,
generate and return R_B, otherwise
2. Generate R_A.
3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise
4. Generate R_B and combine it with R_A to form R_C:
For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
records from R_A into R_B, EXCEPT the AUTHORITY section SOA
record, if R_B's RCODE = NOERROR.
5. Return R_C.
Arends, et al. Expires January 19, 2006 [Page 15]
Internet-Draft DNSSEC Opt-In July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Arends, et al. Expires January 19, 2006 [Page 16]

839
contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt Normal file
View File

@ -0,0 +1,839 @@
DNS Extensions Working Group R. Arends
Internet-Draft Telematica Instituut
Expires: August 25, 2005 P. Koch
DENIC eG
J. Schlyter
NIC-SE
February 21, 2005
Evaluating DNSSEC Transition Mechanisms
draft-ietf-dnsext-dnssec-trans-02.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 25, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document collects and summarizes different proposals for
alternative and additional strategies for authenticated denial in DNS
responses, evaluates these proposals and gives a recommendation for a
Arends, et al. Expires August 25, 2005 [Page 1]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
way forward.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3
2.1 Mechanisms With Need of Updating DNSSEC-bis . . . . . . . 4
2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4
2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . 5
2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6
2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . 6
2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . 7
2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8
2.1.7 New Answer Pseudo RR Type . . . . . . . . . . . . . . 9
2.1.8 SIG(0) Based Authenticated Denial . . . . . . . . . . 9
2.2 Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10
2.2.1 Partial Type-code and Signal Rollover . . . . . . . . 10
2.2.2 A Complete Type-code and Signal Rollover . . . . . . . 11
2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11
3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1 Normative References . . . . . . . . . . . . . . . . . . . 13
5.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
Arends, et al. Expires August 25, 2005 [Page 2]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
1. Introduction
This report shall document the process of dealing with the NSEC
walking problem late in the Last Call for
[I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol,
I-D.ietf-dnsext-dnssec-records]. It preserves some of the discussion
that took place in the DNSEXT WG during the first half of June 2004
as well as some additional ideas that came up subsequently.
This is an edited excerpt of the chairs' mail to the WG:
The working group consents on not including NSEC-alt in the
DNSSEC-bis documents. The working group considers to take up
"prevention of zone enumeration" as a work item.
There may be multiple mechanisms to allow for co-existence with
DNSSEC-bis. The chairs allow the working group a little over a
week (up to June 12, 2004) to come to consensus on a possible
modification to the document to enable gentle rollover. If that
consensus cannot be reached the DNSSEC-bis documents will go out
as-is.
To ease the process of getting consensus, a summary of the proposed
solutions and analysis of the pros and cons were written during the
weekend.
This summary includes:
An inventory of the proposed mechanisms to make a transition to
future work on authenticated denial of existence.
List the known Pros and Cons, possibly provide new arguments, and
possible security considerations of these mechanisms.
Provide a recommendation on a way forward that is least disruptive
to the DNSSEC-bis specifications as they stand and keep an open
path to other methods for authenticated denial of existence.
The descriptions of the proposals in this document are coarse and do
not cover every detail necessary for implementation. In any case,
documentation and further study is needed before implementaion and/or
deployment, including those which seem to be solely operational in
nature.
2. Transition Mechanisms
In the light of recent discussions and past proposals, we have found
several ways to allow for transition to future expansion of
authenticated denial. We tried to illuminate the paths and pitfalls
in these ways forward. Some proposals lead to a versioning of
DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other
proposals are 'clean' but may cause delay, while again others may be
Arends, et al. Expires August 25, 2005 [Page 3]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
plain hacks.
Some paths do not introduce versioning, and might require the current
DNSSEC-bis documents to be fully updated to allow for extensions to
authenticated denial mechanisms. Other paths introduce versioning
and do not (or minimally) require DNSSEC-bis documents to be updated,
allowing DNSSEC-bis to be deployed, while future versions can be
drafted independent from or partially depending on DNSSEC-bis.
2.1 Mechanisms With Need of Updating DNSSEC-bis
Mechanisms in this category demand updates to the DNSSEC-bis document
set.
2.1.1 Dynamic NSEC Synthesis
This proposal assumes that NSEC RRs and the authenticating RRSIG will
be generated dynamically to just cover the (non existent) query name.
The owner name is (the) one preceding the name queried for, the Next
Owner Name Field has the value of the Query Name Field + 1 (first
successor in canonical ordering). A separate key (the normal ZSK or
a separate ZSK per authoritative server) would be used for RRSIGs on
NSEC RRs. This is a defense against enumeration, though it has the
presumption of online signing.
2.1.1.1 Coexistence and Migration
There is no change in interpretation other then that the next owner
name might or might not exist.
2.1.1.2 Limitations
This introduces an unbalanced cost between query and response
generation due to dynamic generation of signatures.
2.1.1.3 Amendments to DNSSEC-bis
The current DNSSEC-bis documents might need to be updated to indicate
that the next owner name might not be an existing name in the zone.
This is not a real change to the spec since implementers have been
warned not to synthesize with previously cached NSEC records. A
specific bit to identify the dynamic signature generating key might
be useful as well, to prevent it from being used to fake positive
data.
2.1.1.4 Cons
Unbalanced cost is a ground for DDoS. Though this protects against
Arends, et al. Expires August 25, 2005 [Page 4]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
enumeration, it is not really a path for versioning.
2.1.1.5 Pros
Hardly any amendments to DNSSEC-bis.
2.1.2 Add Versioning/Subtyping to Current NSEC
This proposal introduces versioning for the NSEC RR type (a.k.a.
subtyping) by adding a (one octet) version field to the NSEC RDATA.
Version number 0 is assigned to the current (DNSSEC-bis) meaning,
making this an 'Must Be Zero' (MBZ) for the to be published docset.
2.1.2.1 Coexistence and Migration
Since the versioning is done inside the NSEC RR, different versions
may coexist. However, depending on future methods, that may or may
not be useful inside a single zone. Resolvers cannot ask for
specific NSEC versions but may be able to indicate version support by
means of a to be defined EDNS option bit.
2.1.2.2 Limitations
There are no technical limitations, though it will cause delay to
allow testing of the (currently unknown) new NSEC interpretation.
Since the versioning and signaling is done inside the NSEC RR, future
methods will likely be restricted to a single RR type authenticated
denial (as opposed to e.g. NSEC-alt, which currently proposes three
RR types).
2.1.2.3 Amendments to DNSSEC-bis
Full Update of the current DNSSEC-bis documents to provide for new
fields in NSEC, while specifying behavior in case of unknown field
values.
2.1.2.4 Cons
Though this is a clean and clear path without versioning DNSSEC, it
takes some time to design, gain consensus, update the current
dnssec-bis document, test and implement a new authenticated denial
record.
2.1.2.5 Pros
Does not introduce an iteration to DNSSEC while providing a clear and
clean migration strategy.
Arends, et al. Expires August 25, 2005 [Page 5]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
2.1.3 Type Bit Map NSEC Indicator
Bits in the type-bit-map are reused or allocated to signify the
interpretation of NSEC.
This proposal assumes that future extensions make use of the existing
NSEC RDATA syntax, while it may need to change the interpretation of
the RDATA or introduce an alternative denial mechanism, invoked by
the specific type-bit-map-bits.
2.1.3.1 Coexistence and migration
Old and new NSEC meaning could coexist, depending how the signaling
would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR
types are available as well as those covering meta/query types or
types to be specifically allocated.
2.1.3.2 Limitations
This mechanism uses an NSEC field that was not designed for that
purpose. Similar methods were discussed during the Opt-In discussion
and the Silly-State discussion.
2.1.3.3 Amendments to DNSSEC-bis
The specific type-bit-map-bits must be allocated and they need to be
specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis)
interpretation. Also, behaviour of the resolver and validator must
be documented in case unknown values are encountered for the MBZ
field. Currently the protocol document specifies that the validator
MUST ignore the setting of the NSEC and the RRSIG bits, while other
bits are only used for the specific purpose of the type-bit-map field
2.1.3.4 Cons
The type-bit-map was not designed for this purpose. It is a
straightforward hack. Text in protocol section 5.4 was put in
specially to defend against this usage.
2.1.3.5 Pros
No change needed to the on-the-wire protocol as specified in the
current docset.
2.1.4 New Apex Type
This introduces a new Apex type (parallel to the zone's SOA)
indicating the DNSSEC version (or authenticated denial) used in or
Arends, et al. Expires August 25, 2005 [Page 6]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
for this zone.
2.1.4.1 Coexistence and Migration
Depending on the design of this new RR type multiple denial
mechanisms may coexist in a zone. Old validators will not understand
and thus ignore the new type, so interpretation of the new NSEC
scheme may fail, negative responses may appear 'bogus'.
2.1.4.2 Limitations
A record of this kind is likely to carry additional
feature/versioning indications unrelated to the current question of
authenticated denial.
2.1.4.3 Amendments to DNSSEC-bis
The current DNSSEC-bis documents need to be updated to indicate that
the absence of this type indicates dnssec-bis, and that the (mere)
presence of this type indicated unknown versions.
2.1.4.4 Cons
The only other 'zone' or 'apex' record is the SOA record. Though
this proposal is not new, it is yet unknown how it might fulfill
authenticated denial extensions. This new RR type would only provide
for a generalized signaling mechanism, not the new authenticated
denial scheme. Since it is likely to be general in nature, due to
this generality consensus is not to be reached soon.
2.1.4.5 Pros
This approach would allow for a lot of other per zone information to
be transported or signaled to both (slave) servers and resolvers.
2.1.5 NSEC White Lies
This proposal disables one part of NSEC (the pointer part) by means
of a special target (root, apex, owner, ...), leaving intact only the
ability to authenticate denial of existence of RR sets, not denial of
existence of domain names (NXDOMAIN). It may be necessary to have
one working NSEC to prove the absence of a wildcard.
2.1.5.1 Coexistence and Migration
The NSEC target can be specified per RR, so standard NSEC and 'white
lie' NSEC can coexist in a zone. There is no need for migration
because no versioning is introduced or intended.
Arends, et al. Expires August 25, 2005 [Page 7]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
2.1.5.2 Limitations
This proposal breaks the protocol and is applicable to certain types
of zones only (no wildcard, no deep names, delegation only). Most of
the burden is put on the resolver side and operational consequences
are yet to be studied.
2.1.5.3 Amendments to DNSSEC-bis
The current DNSSEC-bis documents need to be updated to indicate that
the NXDOMAIN responses may be insecure.
2.1.5.4 Cons
Strictly speaking this breaks the protocol and doesn't fully fulfill
the requirements for authenticated denial of existence. Security
implications need to be carefully documented: search path problems
(forged denial of existence may lead to wrong expansion of non-FQDNs
[RFC1535]) and replay attacks to deny existence of records.
2.1.5.5 Pros
Hardly any amendments to DNSSEC-bis. Operational "trick" that is
available anyway.
2.1.6 NSEC Optional via DNSSKEY Flag
A new DNSKEY may be defined to declare NSEC optional per zone.
2.1.6.1 Coexistence and Migration
Current resolvers/validators will not understand the Flag bit and
will have to treat negative responses as bogus. Otherwise, no
migration path is needed since NSEC is simply turned off.
2.1.6.2 Limitations
NSEC can only be made completely optional at the cost of being unable
to prove unsecure delegations (absence of a DS RR [RFC3658]). A next
to this approach would just disable authenticated denial for
non-existence of nodes.
2.1.6.3 Amendments to DNSSEC-bis
New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to
be specified in the light of absence of authenticated denial.
Arends, et al. Expires August 25, 2005 [Page 8]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
2.1.6.4 Cons
Doesn't fully meet requirements. Operational consequences to be
studied.
2.1.6.5 Pros
Official version of the "trick" presented in (8). Operational
problems can be addressed during future work on validators.
2.1.7 New Answer Pseudo RR Type
A new pseudo RR type may be defined that will be dynamically created
(and signed) by the responding authoritative server. The RR in the
response will cover the QNAME, QCLASS and QTYPE and will authenticate
both denial of existence of name (NXDOMAIN) or RRset.
2.1.7.1 Coexistence and Migration
Current resolvers/validators will not understand the pseudo RR and
will thus not be able to process negative responses so testified. A
signaling or solicitation method would have to be specified.
2.1.7.2 Limitations
This method can only be used with online keys and online signing
capacity.
2.1.7.3 Amendments to DNSSEC-bis
Signaling method needs to be defined.
2.1.7.4 Cons
Keys have to be held and processed online with all security
implications. An additional flag for those keys identifying them as
online or negative answer only keys should be considered.
2.1.7.5 Pros
Expands DNSSEC authentication to the RCODE.
2.1.8 SIG(0) Based Authenticated Denial
2.1.8.1 Coexistence and Migration
Arends, et al. Expires August 25, 2005 [Page 9]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
2.1.8.2 Limitations
2.1.8.3 Amendments to DNSSEC-bis
2.1.8.4 Cons
2.1.8.5 Pros
2.2 Mechanisms Without Need of Updating DNSSEC-bis
2.2.1 Partial Type-code and Signal Rollover
Carefully crafted type code/signal rollover to define a new
authenticated denial space that extends/replaces DNSSEC-bis
authenticated denial space. This particular path is illuminated by
Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com>
posted to <namedroppers@ops.ietf.org> 2004-06-02.
2.2.1.1 Coexistence and Migration
To protect the current resolver for future versions, a new DNSSEC-OK
bit must be allocated to make clear it does or does not understand
the future version. Also, a new DS type needs to be allocated to
allow differentiation between a current signed delegation and a
'future' signed delegation. Also, current NSEC needs to be rolled
into a new authenticated denial type.
2.2.1.2 Limitations
None.
2.2.1.3 Amendments to DNSSEC-bis
None.
2.2.1.4 Cons
It is cumbersome to carefully craft an TCR that 'just fits'. The
DNSSEC-bis protocol has many 'borderline' cases that needs special
consideration. It might be easier to do a full TCR, since a few of
the types and signals need upgrading anyway.
Arends, et al. Expires August 25, 2005 [Page 10]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
2.2.1.5 Pros
Graceful adoption of future versions of NSEC, while there are no
amendments to DNSSEC-bis.
2.2.2 A Complete Type-code and Signal Rollover
A new DNSSEC space is defined which can exist independent of current
DNSSEC-bis space.
This proposal assumes that all current DNSSEC type-codes
(RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any
future versions of DNSSEC. Any future version of DNSSEC has its own
types to allow for keys, signatures, authenticated denial, etcetera.
2.2.2.1 Coexistence and Migration
Both spaces can co-exist. They can be made completely orthogonal.
2.2.2.2 Limitations
None.
2.2.2.3 Amendments to DNSSEC-bis
None.
2.2.2.4 Cons
With this path we abandon the current DNSSEC-bis. Though it is easy
to role specific well-known and well-tested parts into the re-write,
once deployment has started this path is very expensive for
implementers, registries, registrars and registrants as well as
resolvers/users. A TCR is not to be expected to occur frequently, so
while a next generation authenticated denial may be enabled by a TCR,
it is likely that that TCR will only be agreed upon if it serves a
whole basket of changes or additions. A quick introduction of
NSEC-ng should not be expected from this path.
2.2.2.5 Pros
No amendments/changes to current DNSSEC-bis docset needed. It is
always there as last resort.
2.2.3 Unknown Algorithm in RRSIG
This proposal assumes that future extensions make use of the existing
NSEC RDATA syntax, while it may need to change the interpretation of
Arends, et al. Expires August 25, 2005 [Page 11]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
the RDATA or introduce an alternative denial mechanism, invoked by
the specific unknown signing algorithm. The different interpretation
would be signaled by use of different signature algorithms in the
RRSIG records covering the NSEC RRs.
When an entire zone is signed with a single unknown algorithm, it
will cause implementations that follow current dnssec-bis documents
to treat individual RRsets as unsigned.
2.2.3.1 Coexistence and migration
Old and new NSEC RDATA interpretation or known and unknown Signatures
can NOT coexist in a zone since signatures cover complete (NSEC)
RRSets.
2.2.3.2 Limitations
Validating resolvers agnostic of new interpretation will treat the
NSEC RRset as "not signed". This affects wildcard and non-existence
proof, as well as proof for (un)secured delegations. Also, all
positive signatures (RRSIGs on RRSets other than DS, NSEC) appear
insecure/bogus to an old validator.
The algorithm version space is split for each future version of
DNSSEC. Violation of the 'modular components' concept. We use the
'validator' to protect the 'resolver' from unknown interpretations.
2.2.3.3 Amendments to DNSSEC-bis
None.
2.2.3.4 Cons
The algorithm field was not designed for this purpose. This is a
straightforward hack.
2.2.3.5 Pros
No amendments/changes to current DNSSEC-bis docset needed.
3. Recommendation
The authors recommend that the working group commits to and starts
work on a partial TCR, allowing graceful transition towards a future
version of NSEC. Meanwhile, to accomodate the need for an
immediately, temporary, solution against zone-traversal, we recommend
On-Demand NSEC synthesis.
Arends, et al. Expires August 25, 2005 [Page 12]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
This approach does not require any mandatory changes to DNSSEC-bis,
does not violate the protocol and fulfills the requirements. As a
side effect, it moves the cost of implementation and deployment to
the users (zone owners) of this mechanism.
4. Acknowledgements
The authors would like to thank Sam Weiler and Mark Andrews for their
input and constructive comments.
5. References
5.1 Normative References
[I-D.ietf-dnsext-dnssec-intro]
Arends, R., Austein, R., Massey, D., Larson, M. and S.
Rose, "DNS Security Introduction and Requirements",
Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October
2004.
[I-D.ietf-dnsext-dnssec-protocol]
Arends, R., "Protocol Modifications for the DNS Security
Extensions",
Internet-Draft draft-ietf-dnsext-dnssec-protocol-09,
October 2004.
[I-D.ietf-dnsext-dnssec-records]
Arends, R., "Resource Records for the DNS Security
Extensions",
Internet-Draft draft-ietf-dnsext-dnssec-records-11,
October 2004.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000.
5.2 Informative References
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction
With Widely Deployed DNS Software", RFC 1535, October
1993.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
Arends, et al. Expires August 25, 2005 [Page 13]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
RFC 2535, March 1999.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, December 2003.
Authors' Addresses
Roy Arends
Telematica Instituut
Brouwerijstraat 1
Enschede 7523 XC
The Netherlands
Phone: +31 53 4850485
Email: roy.arends@telin.nl
Peter Koch
DENIC eG
Wiesenh"uttenplatz 26
Frankfurt 60329
Germany
Phone: +49 69 27235 0
Email: pk@DENIC.DE
Jakob Schlyter
NIC-SE
Box 5774
Stockholm SE-114 87
Sweden
Email: jakob@nic.se
URI: http://www.nic.se/
Arends, et al. Expires August 25, 2005 [Page 14]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Arends, et al. Expires August 25, 2005 [Page 15]

928
contrib/bind9/doc/draft/draft-ietf-dnsext-ecc-key-07.txt Normal file
View File

@ -0,0 +1,928 @@
INTERNET-DRAFT ECC Keys in the DNS
Expires: January 2006 July 2005
Elliptic Curve KEYs in the DNS
-------- ----- ---- -- --- ---
<draft-ietf-dnsext-ecc-key-07.txt>
Richard C. Schroeppel
Donald Eastlake 3rd
Status of This Document
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.
This draft is intended to be become a Proposed Standard RFC.
Distribution of this document is unlimited. Comments should be sent
to the DNS mailing list <namedroppers@ops.ietf.org>.
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 a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
The standard method for storing elliptic curve cryptographic keys and
signatures in the Domain Name System is specified.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
R. Schroeppel, et al [Page 1]
INTERNET-DRAFT ECC Keys in the DNS
Acknowledgement
The assistance of Hilarie K. Orman in the production of this document
is greatfully acknowledged.
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Copyright Notice...........................................1
Acknowledgement............................................2
Table of Contents..........................................2
1. Introduction............................................3
2. Elliptic Curve Data in Resource Records.................3
3. The Elliptic Curve Equation.............................9
4. How do I Compute Q, G, and Y?..........................10
5. Elliptic Curve SIG Resource Records....................11
6. Performance Considerations.............................13
7. Security Considerations................................13
8. IANA Considerations....................................13
Copyright and Disclaimer..................................14
Informational References..................................15
Normative Refrences.......................................15
Author's Addresses........................................16
Expiration and File Name..................................16
R. Schroeppel, et al [Page 2]
INTERNET-DRAFT ECC Keys in the DNS
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
other information. The DNS has been extended to include digital
signatures and cryptographic keys as described in [RFC 4033, 4034,
4035].
This document describes how to store elliptic curve cryptographic
(ECC) keys and signatures in the DNS so they can be used for a
variety of security purposes. Familiarity with ECC cryptography is
assumed [Menezes].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
2. Elliptic Curve Data in Resource Records
Elliptic curve public keys are stored in the DNS within the RDATA
portions of key RRs, such as RRKEY and KEY [RFC 4034] RRs, with the
structure shown below.
The research world continues to work on the issue of which is the
best elliptic curve system, which finite field to use, and how to
best represent elements in the field. So, representations are
defined for every type of finite field, and every type of elliptic
curve. The reader should be aware that there is a unique finite
field with a particular number of elements, but many possible
representations of that field and its elements. If two different
representations of a field are given, they are interconvertible with
a tedious but practical precomputation, followed by a fast
computation for each field element to be converted. It is perfectly
reasonable for an algorithm to work internally with one field
representation, and convert to and from a different external
representation.
R. Schroeppel, et al [Page 3]
INTERNET-DRAFT ECC Keys in the DNS
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S M -FMT- A B Z|
+-+-+-+-+-+-+-+-+
| LP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P (length determined from LP) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F (length determined from LF) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEGH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEGI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEGJ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRDV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| LH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H (length determined from LH) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| LK |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| K (length determined from LK) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Q (length determined from LQ) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A (length determined from LA) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ALTA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B (length determined from LB) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C (length determined from LC) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LG |
R. Schroeppel, et al [Page 4]
INTERNET-DRAFT ECC Keys in the DNS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G (length determined from LG) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Y (length determined from LY) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SMFMTABZ is a flags octet as follows:
S = 1 indicates that the remaining 7 bits of the octet selects
one of 128 predefined choices of finite field, element
representation, elliptic curve, and signature parameters.
MFMTABZ are omitted, as are all parameters from LP through G.
LY and Y are retained.
If S = 0, the remaining parameters are as in the picture and
described below.
M determines the type of field underlying the elliptic curve.
M = 0 if the field is a GF[2^N] field;
M = 1 if the field is a (mod P) or GF[P^D] field with P>2.
FMT is a three bit field describing the format of the field
representation.
FMT = 0 for a (mod P) field.
> 0 for an extension field, either GF[2^D] or GF[P^D].
The degree D of the extension, and the field polynomial
must be specified. The field polynomial is always monic
(leading coefficient 1.)
FMT = 1 The field polynomial is given explicitly; D is implied.
If FMT >=2, the degree D is given explicitly.
= 2 The field polynomial is implicit.
= 3 The field polynomial is a binomial. P>2.
= 4 The field polynomial is a trinomial.
= 5 The field polynomial is the quotient of a trinomial by a
short polynomial. P=2.
= 6 The field polynomial is a pentanomial. P=2.
Flags A and B apply to the elliptic curve parameters.
R. Schroeppel, et al [Page 5]
INTERNET-DRAFT ECC Keys in the DNS
A = 1 When P>=5, the curve parameter A is negated. If P=2, then
A=1 indicates that the A parameter is special. See the
ALTA parameter below, following A. The combination A=1,
P=3 is forbidden.
B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3,
then B=1 indicates an alternate elliptic curve equation is
used. When P=2 and B=1, an additional curve parameter C
is present.
The Z bit SHOULD be set to zero on creation of an RR and MUST be
ignored when processing an RR (when S=0).
Most of the remaining parameters are present in some formats and
absent in others. The presence or absence of a parameter is
determined entirely by the flags. When a parameter occurs, it is in
the order defined by the picture.
Of the remaining parameters, PFHKQABCGY are variable length. When
present, each is preceded by a one-octet length field as shown in the
diagram above. The length field does not include itself. The length
field may have values from 0 through 110. The parameter length in
octets is determined by a conditional formula: If LL<=64, the
parameter length is LL. If LL>64, the parameter length is 16 times
(LL-60). In some cases, a parameter value of 0 is sensible, and MAY
be represented by an LL value of 0, with the data field omitted. A
length value of 0 represents a parameter value of 0, not an absent
parameter. (The data portion occupies 0 space.) There is no
requirement that a parameter be represented in the minimum number of
octets; high-order 0 octets are allowed at the front end. Parameters
are always right adjusted, in a field of length defined by LL. The
octet-order is always most-significant first, least-significant last.
The parameters H and K may have an optional sign bit stored in the
unused high-order bit of their length fields.
LP defines the length of the prime P. P must be an odd prime. The
parameters LP,P are present if and only if the flag M=1. If M=0, the
prime is 2.
LF,F define an explicit field polynomial. This parameter pair is
present only when FMT = 1. The length of a polynomial coefficient is
ceiling(log2 P) bits. Coefficients are in the numerical range
[0,P-1]. The coefficients are packed into fixed-width fields, from
higher order to lower order. All coefficients must be present,
including any 0s and also the leading coefficient (which is required
to be 1). The coefficients are right justified into the octet string
of length specified by LF, with the low-order "constant" coefficient
at the right end. As a concession to storage efficiency, the higher
order bits of the leading coefficient may be elided, discarding high-
order 0 octets and reducing LF. The degree is calculated by
R. Schroeppel, et al [Page 6]
INTERNET-DRAFT ECC Keys in the DNS
determining the bit position of the left most 1-bit in the F data
(counting the right most bit as position 0), and dividing by
ceiling(log2 P). The division must be exact, with no remainder. In
this format, all of the other degree and field parameters are
omitted. The next parameters will be LQ,Q.
If FMT>=2, the degree of the field extension is specified explicitly,
usually along with other parameters to define the field polynomial.
DEG is a two octet field that defines the degree of the field
extension. The finite field will have P^DEG elements. DEG is
present when FMT>=2.
When FMT=2, the field polynomial is specified implicitly. No other
parameters are required to define the field; the next parameters
present will be the LQ,Q pair. The implicit field poynomial is the
lexicographically smallest irreducible (mod P) polynomial of the
correct degree. The ordering of polynomials is by highest-degree
coefficients first -- the leading coefficient 1 is most important,
and the constant term is least important. Coefficients are ordered
by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of
degree D is X^D (which is not irreducible). The next is X^D+1, which
is sometimes irreducible, followed by X^D-1, which isn't. Assuming
odd P, this series continues to X^D - (P-1)/2, and then goes to X^D +
X, X^D + X + 1, X^D + X - 1, etc.
When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be
odd. The polynomial is determined by the degree and the low order
term K. Of all the field parameters, only the LK,K parameters are
present. The high-order bit of the LK octet stores on optional sign
for K; if the sign bit is present, the field polynomial is X^DEG - K.
When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH +
K. When P=2, the H and K parameters are implicitly 1, and are
omitted from the representation. Only DEG and DEGH are present; the
next parameters are LQ,Q. When P>2, then LH,H and LK,K are
specified. Either or both of LH, LK may contain a sign bit for its
parameter.
When FMT=5, then P=2 (only). The field polynomial is the exact
quotient of a trinomial divided by a small polynomial, the trinomial
divisor. The small polynomial is right-adjusted in the two octet
field TRDV. DEG specifies the degree of the field. The degree of
TRDV is calculated from the position of the high-order 1 bit. The
trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If
DEGH is 0, the middle term is omitted from the trinomial. The
quotient must be exact, with no remainder.
When FMT=6, then P=2 (only). The field polynomial is a pentanomial,
with the degrees of the middle terms given by the three 2-octet
R. Schroeppel, et al [Page 7]
INTERNET-DRAFT ECC Keys in the DNS
values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI +
X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI
> DEGJ > 0.
DEGH, DEGI, DEGJ are two-octet fields that define the degree of
a term in a field polynomial. DEGH is present when FMT = 4,
5, or 6. DEGI and DEGJ are present only when FMT = 6.
TRDV is a two-octet right-adjusted binary polynomial of degree <
16. It is present only for FMT=5.
LH and H define the H parameter, present only when FMT=4 and P
is odd. The high bit of LH is an optional sign bit for H.
LK and K define the K parameter, present when FMT = 3 or 4, and
P is odd. The high bit of LK is an optional sign bit for K.
The remaining parameters are concerned with the elliptic curve and
the signature algorithm.
LQ defines the length of the prime Q. Q is a prime > 2^159.
In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data
member of the pair is an element from the finite field defined
earlier. The length field defines a long octet string. Field
elements are represented as (mod P) polynomials of degree < DEG, with
DEG or fewer coefficients. The coefficients are stored from left to
right, higher degree to lower, with the constant term last. The
coefficients are represented as integers in the range [0,P-1]. Each
coefficient is allocated an area of ceiling(log2 P) bits. The field
representation is right-justified; the "constant term" of the field
element ends at the right most bit. The coefficients are fitted
adjacently without regard for octet boundaries. (Example: if P=5,
three bits are used for each coefficient. If the field is GF[5^75],
then 225 bits are required for the coefficients, and as many as 29
octets may be needed in the data area. Fewer octets may be used if
some high-order coefficients are 0.) If a flag requires a field
element to be negated, each non-zero coefficient K is replaced with
P-K. To save space, 0 bits may be removed from the left end of the
element representation, and the length field reduced appropriately.
This would normally only happen with A,B,C, because the designer
chose curve parameters with some high-order 0 coefficients or bits.
If the finite field is simply (mod P), then the field elements are
simply numbers (mod P), in the usual right-justified notation. If
the finite field is GF[2^D], the field elements are the usual right-
justified polynomial basis representation.
R. Schroeppel, et al [Page 8]
INTERNET-DRAFT ECC Keys in the DNS
LA,A is the first parameter of the elliptic curve equation.
When P>=5, the flag A = 1 indicates A should be negated (mod
P). When P=2 (indicated by the flag M=0), the flag A = 1
indicates that the parameter pair LA,A is replaced by the two
octet parameter ALTA. In this case, the parameter A in the
curve equation is x^ALTA, where x is the field generator.
Parameter A often has the value 0, which may be indicated by
LA=0 (with no A data field), and sometimes A is 1, which may
be represented with LA=1 and a data field of 1, or by setting
the A flag and using an ALTA value of 0.
LB,B is the second parameter of the elliptic curve equation.
When P>=5, the flag B = 1 indicates B should be negated (mod
P). When P=2 or 3, the flag B selects an alternate curve
equation.
LC,C is the third parameter of the elliptic curve equation,
present only when P=2 (indicated by flag M=0) and flag B=1.
LG,G defines a point on the curve, of order Q. The W-coordinate
of the curve point is given explicitly; the Z-coordinate is
implicit.
LY,Y is the user's public signing key, another curve point of
order Q. The W-coordinate is given explicitly; the Z-
coordinate is implicit. The LY,Y parameter pair is always
present.
3. The Elliptic Curve Equation
(The coordinates of an elliptic curve point are named W,Z instead of
the more usual X,Y to avoid confusion with the Y parameter of the
signing key.)
The elliptic curve equation is determined by the flag octet, together
with information about the prime P. The primes 2 and 3 are special;
all other primes are treated identically.
If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3
+ A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D].
If A and/or B is negative (i.e., in the range from P/2 to P), and
P>=5, space may be saved by putting the sign bit(s) in the A and B
bits of the flags octet, and the magnitude(s) in the parameter
fields.
If M=1 and P=3, the B flag has a different meaning: it specifies an
alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of
the right-hand-side is different. When P=3, this equation is more
R. Schroeppel, et al [Page 9]
INTERNET-DRAFT ECC Keys in the DNS
commonly used.
If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 +
A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A
parameter can often be 0 or 1, or be chosen as a single-1-bit value.
The flag B is used to select an alternate curve equation, Z^2 + C*Z =
W^3 + A*W + B. This is the only time that the C parameter is used.
4. How do I Compute Q, G, and Y?
The number of points on the curve is the number of solutions to the
curve equation, + 1 (for the "point at infinity"). The prime Q must
divide the number of points. Usually the curve is chosen first, then
the number of points is determined with Schoof's algorithm. This
number is factored, and if it has a large prime divisor, that number
is taken as Q.
G must be a point of order Q on the curve, satisfying the equation
Q * G = the point at infinity (on the elliptic curve)
G may be chosen by selecting a random [RFC 1750] curve point, and
multiplying it by (number-of-points-on-curve/Q). G must not itself
be the "point at infinity"; in this astronomically unlikely event, a
new random curve point is recalculated.
G is specified by giving its W-coordinate. The Z-coordinate is
calculated from the curve equation. In general, there will be two
possible Z values. The rule is to choose the "positive" value.
In the (mod P) case, the two possible Z values sum to P. The smaller
value is less than P/2; it is used in subsequent calculations. In
GF[P^D] fields, the highest-degree non-zero coefficient of the field
element Z is used; it is chosen to be less than P/2.
In the GF[2^N] case, the two possible Z values xor to W (or to the
parameter C with the alternate curve equation). The numerically
smaller Z value (the one which does not contain the highest-order 1
bit of W (or C)) is used in subsequent calculations.
Y is specified by giving the W-coordinate of the user's public
signature key. The Z-coordinate value is determined from the curve
equation. As with G, there are two possible Z values; the same rule
is followed for choosing which Z to use.
R. Schroeppel, et al [Page 10]
INTERNET-DRAFT ECC Keys in the DNS
During the key generation process, a random [RFC 1750] number X must
be generated such that 1 <= X <= Q-1. X is the private key and is
used in the final step of public key generation where Y is computed
as
Y = X * G (as points on the elliptic curve)
If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2
in the (mod P) case, or the high-order non-zero coefficient of Z >
P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the
GF[2^N] case), then X must be replaced with Q-X. This will
correspond to the correct Z-coordinate.
5. Elliptic Curve SIG Resource Records
The signature portion of an RR RDATA area when using the EC
algorithm, for example in the RRSIG and SIG [RFC records] RRs is
shown below.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R, (length determined from LQ) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S, (length determined from LQ) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R and S are integers (mod Q). Their length is specified by the LQ
field of the corresponding KEY RR and can also be calculated from the
SIG RR's RDLENGTH. They are right justified, high-order-octet first.
The same conditional formula for calculating the length from LQ is
used as for all the other length fields above.
The data signed is determined as specified in [RFC 2535]. Then the
following steps are taken where Q, P, G, and Y are as specified in
the public key [Schneier]:
hash = SHA-1 ( data )
Generate random [RFC 4086] K such that 0 < K < Q. (Never sign two
different messages with the same K. K should be chosen from a
very large space: If an opponent learns a K value for a single
signature, the user's signing key is compromised, and a forger
can sign arbitrary messages. There is no harm in signing the
same message multiple times with the same key or different
keys.)
R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted
R. Schroeppel, et al [Page 11]
INTERNET-DRAFT ECC Keys in the DNS
as an integer, and reduced (mod Q). (R must not be 0. In
this astronomically unlikely event, generate a new random K
and recalculate R.)
S = ( K^(-1) * (hash + X*R) ) mod Q.
S must not be 0. In this astronomically unlikely event, generate a
new random K and recalculate R and S.
If S > Q/2, set S = Q - S.
The pair (R,S) is the signature.
Another party verifies the signature as follows:
Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a
valid EC sigature.
hash = SHA-1 ( data )
Sinv = S^(-1) mod Q.
U1 = (hash * Sinv) mod Q.
U2 = (R * Sinv) mod Q.
(U1 * G + U2 * Y) is computed on the elliptic curve.
V = (the W-coordinate of this point) interpreted as an integer
and reduced (mod Q).
The signature is valid if V = R.
The reason for requiring S < Q/2 is that, otherwise, both (R,S) and
(R,Q-S) would be valid signatures for the same data. Note that a
signature that is valid for hash(data) is also valid for
hash(data)+Q or hash(data)-Q, if these happen to fall in the range
[0,2^160-1]. It's believed to be computationally infeasible to
find data that hashes to an assigned value, so this is only a
cosmetic blemish. The blemish can be eliminated by using Q >
2^160, at the cost of having slightly longer signatures, 42 octets
instead of 40.
We must specify how a field-element E ("the W-coordinate") is to be
interpreted as an integer. The field-element E is regarded as a
radix-P integer, with the digits being the coefficients in the
polynomial basis representation of E. The digits are in the ragne
[0,P-1]. In the two most common cases, this reduces to "the
obvious thing". In the (mod P) case, E is simply a residue mod P,
and is taken as an integer in the range [0,P-1]. In the GF[2^D]
R. Schroeppel, et al [Page 12]
INTERNET-DRAFT ECC Keys in the DNS
case, E is in the D-bit polynomial basis representation, and is
simply taken as an integer in the range [0,(2^D)-1]. For other
fields GF[P^D], it's necessary to do some radix conversion
arithmetic.
6. Performance Considerations
Elliptic curve signatures use smaller moduli or field sizes than
RSA and DSA. Creation of a curve is slow, but not done very often.
Key generation is faster than RSA or DSA.
DNS implementations have been optimized for small transfers,
typically less than 512 octets including DNS overhead. Larger
transfers will perform correctly and and extensions have been
standardized to make larger transfers more efficient [RFC 2671].
However, it is still advisable at this time to make reasonable
efforts to minimize the size of RR sets stored within the DNS
consistent with adequate security.
7. Security Considerations
Keys retrieved from the DNS should not be trusted unless (1) they
have been securely obtained from a secure resolver or independently
verified by the user and (2) this secure resolver and secure
obtainment or independent verification conform to security policies
acceptable to the user. As with all cryptographic algorithms,
evaluating the necessary strength of the key is essential and
dependent on local policy.
Some specific key generation considerations are given in the body
of this document.
8. IANA Considerations
The key and signature data structures defined herein correspond to
the value 4 in the Algorithm number field of the IANA registry
Assignment of meaning to the remaining ECC data flag bits or to
values of ECC fields outside the ranges for which meaning in
defined in this document requires an IETF consensus as defined in
[RFC 2434].
R. Schroeppel, et al [Page 13]
INTERNET-DRAFT ECC Keys in the DNS
Copyright and Disclaimer
Copyright (C) The Internet Society 2005. 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 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.
R. Schroeppel, et al [Page 14]
INTERNET-DRAFT ECC Keys in the DNS
Informational References
[RFC 1034] - P. Mockapetris, "Domain names - concepts and
facilities", 11/01/1987.
[RFC 1035] - P. Mockapetris, "Domain names - implementation and
specification", 11/01/1987.
[RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)",
August 1999.
[RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and
S. Rose, "DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and
S. Rose, "Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
[RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, June
2005.
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and Sons
[Menezes] - Alfred Menezes, "Elliptic Curve Public Key
Cryptosystems", 1993 Kluwer.
[Silverman] - Joseph Silverman, "The Arithmetic of Elliptic
Curves", 1986, Springer Graduate Texts in mathematics #106.
Normative Refrences
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", October 1998.
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and
S. Rose, "Resource Records for the DNS Security Extensions", RFC
4034, March 2005.
R. Schroeppel, et al [Page 15]
INTERNET-DRAFT ECC Keys in the DNS
Author's Addresses
Rich Schroeppel
500 S. Maple Drive
Woodland Hills, UT 84653 USA
Telephone: +1-505-844-9079(w)
Email: rschroe@sandia.gov
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1 508-786-7554 (w)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires in January 2006.
Its file name is draft-ietf-dnsext-ecc-key-07.txt.
R. Schroeppel, et al [Page 16]

754
contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-06.txt Normal file
View File

@ -0,0 +1,754 @@
INTERNET-DRAFT Donald E. Eastlake 3rd
Updates RFC 1034, 1035 Motorola Laboratories
Expires January 2006 July 2005
Domain Name System (DNS) Case Insensitivity Clarification
------ ---- ------ ----- ---- ------------- -------------
<draft-ietf-dnsext-insensitive-06.txt>
Donald E. Eastlake 3rd
Status of This Document
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.
Distribution of this document is unlimited. Comments should be sent
to the DNSEXT working group at namedroppers@ops.ietf.org.
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 a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
Domain Name System (DNS) names are "case insensitive". This document
explains exactly what that means and provides a clear specification
of the rules. This clarification updates RFCs 1034 and 1035.
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT DNS Case Insensitivity
Acknowledgements
The contributions to this document of Rob Austein, Olafur
Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman
are gratefully acknowledged.
Table of Contents
Status of This Document....................................1
Copyright Notice...........................................1
Abstract...................................................1
Acknowledgements...........................................2
Table of Contents..........................................2
1. Introduction............................................3
2. Case Insensitivity of DNS Labels........................3
2.1 Escaping Unusual DNS Label Octets......................3
2.2 Example Labels with Escapes............................4
3. Name Lookup, Label Types, and CLASS.....................4
3.1 Original DNS Label Types...............................5
3.2 Extended Label Type Case Insensitivity Considerations..5
3.3 CLASS Case Insensitivity Considerations................5
4. Case on Input and Output................................6
4.1 DNS Output Case Preservation...........................6
4.2 DNS Input Case Preservation............................6
5. Internationalized Domain Names..........................7
6. Security Considerations.................................8
Copyright and Disclaimer...................................9
Normative References.......................................9
Informative References....................................10
Changes Between Draft Version.............................11
-02 to -03 Changes........................................11
-03 to -04 Changes........................................11
-04 to -05 Changes........................................11
-05 to -06 Changes........................................12
Author's Address..........................................13
Expiration and File Name..................................13
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT DNS Case Insensitivity
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
other information. Each node in the DNS tree has a name consisting of
zero or more labels [STD 13][RFC 1591, 2606] that are treated in a
case insensitive fashion. This document clarifies the meaning of
"case insensitive" for the DNS. This clarification updates RFCs 1034
and 1035 [STD 13].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
2. Case Insensitivity of DNS Labels
DNS was specified in the era of [ASCII]. DNS names were expected to
look like most host names or Internet email address right halves (the
part after the at-sign, "@") or be numeric as in the in-addr.arpa
part of the DNS name space. For example,
foo.example.net.
aol.com.
www.gnu.ai.mit.edu.
or 69.2.0.192.in-addr.arpa.
Case varied alternatives to the above would be DNS names like
Foo.ExamplE.net.
AOL.COM.
WWW.gnu.AI.mit.EDU.
or 69.2.0.192.in-ADDR.ARPA.
However, the individual octets of which DNS names consist are not
limited to valid ASCII character codes. They are 8-bit bytes and all
values are allowed. Many applications, however, interpret them as
ASCII characters.
2.1 Escaping Unusual DNS Label Octets
In Master Files [STD 13] and other human readable and writable ASCII
contexts, an escape is needed for the byte value for period (0x2E,
".") and all octet values outside of the inclusive range of 0x21
("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in
the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF.
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT DNS Case Insensitivity
One typographic convention for octets that do not correspond to an
ASCII printing graphic is to use a back-slash followed by the value
of the octet as an unsigned integer represented by exactly three
decimal digits.
The same convention can be used for printing ASCII characters so that
they will be treated as a normal label character. This includes the
back-slash character used in this convention itself which can be
expressed as \092 or \\ and the special label separator period (".")
which can be expressed as and \046 or \. respectively. It is
advisable to avoid using a backslash to quote an immediately
following non-printing ASCII character code to avoid implementation
difficulties.
A back-slash followed by only one or two decimal digits is undefined.
A back-slash followed by four decimal digits produces two octets, the
first octet having the value of the first three digits considered as
a decimal number and the second octet being the character code for
the fourth decimal digit.
2.2 Example Labels with Escapes
The first example below shows embedded spaces and a period (".")
within a label. The second one show a 5-octet label where the second
octet has all bits zero, the third is a backslash, and the fourth
octet has all bits one.
Donald\032E\.\032Eastlake\0323rd.example.
and a\000\\\255z.example.
3. Name Lookup, Label Types, and CLASS
The original DNS design decision was made that comparisons on name
lookup for DNS queries should be case insensitive [STD 13]. That is
to say, a lookup string octet with a value in the inclusive range of
0x41 to 0x5A, the upper case ASCII letters, MUST match the identical
value and also match the corresponding value in the inclusive range
0x61 to 0x7A, the lower case ASCII letters. And a lookup string octet
with a lower case ASCII letter value MUST similarly match the
identical value and also match the corresponding value in the upper
case ASCII letter range.
(Historical Note: the terms "upper case" and "lower case" were
invented after movable type. The terms originally referred to the
two font trays for storing, in partitioned areas, the different
physical type elements. Before movable type, the nearest equivalent
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT DNS Case Insensitivity
terms were "majuscule" and "minuscule".)
One way to implement this rule would be, when comparing octets, to
subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A
before the comparison. Such an operation is commonly known as "case
folding" but implementation via case folding is not required. Note
that the DNS case insensitivity does NOT correspond to the case
folding specified in [iso-8859-1] or [iso-8859-2]. For example, the
octets 0xDD (\221) and 0xFD (\253) do NOT match although in other
contexts, where they are interpreted as the upper and lower case
version of "Y" with an acute accent, they might.
3.1 Original DNS Label Types
DNS labels in wire-encoded names have a type associated with them.
The original DNS standard [RFC 1035] had only two types. ASCII
labels, with a length of from zero to 63 octets, and indirect (or
compression) labels which consist of an offset pointer to a name
location elsewhere in the wire encoding on a DNS message. (The ASCII
label of length zero is reserved for use as the name of the root node
of the name tree.) ASCII labels follow the ASCII case conventions
described herein and, as stated above, can actually contain arbitrary
byte values. Indirect labels are, in effect, replaced by the name to
which they point which is then treated with the case insensitivity
rules in this document.
3.2 Extended Label Type Case Insensitivity Considerations
DNS was extended by [RFC 2671] to have additional label type numbers
available. (The only such type defined so far is the BINARY type [RFC
2673] which is now Experimental [RFC 3363].)
The ASCII case insensitivity conventions only apply to ASCII labels,
that is to say, label type 0x0, whether appearing directly or invoked
by indirect labels.
3.3 CLASS Case Insensitivity Considerations
As described in [STD 13] and [RFC 2929], DNS has an additional axis
for data location called CLASS. The only CLASS in global use at this
time is the "IN" or Internet CLASS.
The handling of DNS label case is not CLASS dependent. With the
original design of DNS, it was intended that a recursive DNS resolver
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT DNS Case Insensitivity
be able to handle new CLASSes that were unknown at the time of its
implementation. This requires uniform handling of label case
insensitivity. Should it become desireable, for example, to allocate
a CLASS with "case sensitive ASCII labels" for example, it would be
necessary to allocate a new label type for these labels.
4. Case on Input and Output
While ASCII label comparisons are case insensitive, [STD 13] says
case MUST be preserved on output, and preserved when convenient on
input. However, this means less than it would appear since the
preservation of case on output is NOT required when output is
optimized by the use of indirect labels, as explained below.
4.1 DNS Output Case Preservation
[STD 13] views the DNS namespace as a node tree. ASCII output is as
if a name was marshaled by taking the label on the node whose name is
to be output, converting it to a typographically encoded ASCII
string, walking up the tree outputting each label encountered, and
preceding all labels but the first with a period ("."). Wire output
follows the same sequence but each label is wire encoded and no
periods inserted. No "case conversion" or "case folding" is done
during such output operations, thus "preserving" case. However, to
optimize output, indirect labels may be used to point to names
elsewhere in the DNS answer. In determining whether the name to be
pointed to, for example the QNAME, is the "same" as the remainder of
the name being optimized, the case insensitive comparison specified
above is done. Thus such optimization may easily destroy the output
preservation of case. This type of optimization is commonly called
"name compression".
4.2 DNS Input Case Preservation
Originally, DNS data came from an ASCII Master File as defined in
[STD 13] or a zone transfer. DNS Dynamic update and incremental zone
transfers [RFC 1995] have been added as a source of DNS data [RFC
2136, 3007]. When a node in the DNS name tree is created by any of
such inputs, no case conversion is done. Thus the case of ASCII
labels is preserved if they are for nodes being created. However,
when a name label is input for a node that already exist in DNS data
being held, the situation is more complex. Implementations are free
to retain the case first loaded for such a label or allow new input
to override the old case or even maintain separate copies preserving
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT DNS Case Insensitivity
the input case.
For example, if data with owner name "foo.bar.example" is loaded and
then later data with owner name "xyz.BAR.example" is input, the name
of the label on the "bar.example" node, i.e. "bar", might or might
not be changed to "BAR" in the DNS stored data or the actual input
case could be preserved. Thus later retrieval of data stored under
"xyz.bar.example" in this case can return all data with
"xyz.BAR.example" or all data with "xyz.bar.example" or even, when
more than one RR is being returned, a mixture of these two cases.
This last case is unlikely because optimization of answer length
through indirect labels tends to cause only copy of the name tail
("bar.example" or "BAR.example") to be used for all returned RRs.
Note that none of this has any effect on the number of completeness
of the RR set returned, only on the case of the names in the RR set
returned.
The same considerations apply when inputting multiple data records
with owner names differing only in case. For example, if an "A"
record is the first resourced record stored under owner name
"xyz.BAR.example" and then a second "A" record is stored under
"XYZ.BAR.example", the second MAY be stored with the first (lower
case initial label) name or the second MAY override the first so that
only an upper case initial label is retained or both capitalizations
MAY be kept in the DNS stored data. In any case, a retrieval with
either capitalization will retrieve all RRs with either
capitalization.
Note that the order of insertion into a server database of the DNS
name tree nodes that appear in a Master File is not defined so that
the results of inconsistent capitalization in a Master File are
unpredictable output capitalization.
5. Internationalized Domain Names
A scheme has been adopted for "internationalized domain names" and
"internationalized labels" as described in [RFC 3490, 3454, 3491, and
3492]. It makes most of [UNICODE] available through a separate
application level transformation from internationalized domain name
to DNS domain name and from DNS domain name to internationalized
domain name. Any case insensitivity that internationalized domain
names and labels have varies depending on the script and is handled
entirely as part of the transformation described in [RFC 3454] and
[RFC 3491] which should be seen for further details. This is not a
part of the DNS as standardized in STD 13.
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT DNS Case Insensitivity
6. Security Considerations
The equivalence of certain DNS label types with case differences, as
clarified in this document, can lead to security problems. For
example, a user could be confused by believing two domain names
differing only in case were actually different names.
Furthermore, a domain name may be used in contexts other than the
DNS. It could be used as a case sensitive index into some data base
or file system. Or it could be interpreted as binary data by some
integrity or authentication code system. These problems can usually
be handled by using a standardized or "canonical" form of the DNS
ASCII type labels, that is, always mapping the ASCII letter value
octets in ASCII labels to some specific pre-chosen case, either upper
case or lower case. An example of a canonical form for domain names
(and also a canonical ordering for them) appears in Section 6 of [RFC
4034]. See also [RFC 3597].
Finally, a non-DNS name may be stored into DNS with the false
expectation that case will always be preserved. For example, although
this would be quite rare, on a system with case sensitive email
address local parts, an attempt to store two "RP" records that
differed only in case would probably produce unexpected results that
might have security implications. That is because the entire email
address, including the possibly case sensitive local or left hand
part, is encoded into a DNS name in a readable fashion where the case
of some letters might be changed on output as described above.
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT DNS Case Insensitivity
Copyright and Disclaimer
Copyright (C) The Internet Society (2005). 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 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.
Normative References
[ASCII] - ANSI, "USA Standard Code for Information Interchange",
X3.4, American National Standards Institute: New York, 1968.
[RFC 1034, 1035] - See [STD 13].
[RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August
1996.
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997.
[RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic
Update", November 2000.
[RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types",
draft-ietf-dnsext-unknown-rrs-05.txt, March 2003.
[RFC 4034} - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[STD 13]
- P. Mockapetris, "Domain names - concepts and facilities", RFC
1034, November 1987.
- P. Mockapetris, "Domain names - implementation and
specification", RFC 1035, November 1987.
D. Eastlake 3rd [Page 9]
INTERNET-DRAFT DNS Case Insensitivity
Informative References
[ISO 8859-1] - International Standards Organization, Standard for
Character Encodings, Latin-1.
[ISO 8859-2] - International Standards Organization, Standard for
Character Encodings, Latin-2.
[RFC 1591] - J. Postel, "Domain Name System Structure and
Delegation", March 1994.
[RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
June 1999.
[RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain
Name System (DNS) IANA Considerations", September 2000.
[RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
1999.
[RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
August 1999.
[RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of
Foo", 1 April 2001.
[RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
the Domain Name System (DNS)", RFC 3363, August 2002.
[RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of
Internationalized String ("stringprep")", December 2002.
[RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", March 2003.
[RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
for Internationalized Domain Names (IDN)", March 2003.
[RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications (IDNA)", March
2003.
[UNICODE] - The Unicode Consortium, "The Unicode Standard",
<http://www.unicode.org/unicode/standard/standard.html>.
D. Eastlake 3rd [Page 10]
INTERNET-DRAFT DNS Case Insensitivity
Changes Between Draft Version
RFC Editor: The following summaries of changes between draft versions
are to be removed before publication.
-02 to -03 Changes
The following changes were made between draft version -02 and -03:
1. Add internationalized domain name section and references.
2. Change to indicate that later input of a label for an existing DNS
name tree node may or may not be normalized to the earlier input or
override it or both may be preserved.
3. Numerous minor wording changes.
-03 to -04 Changes
The following changes were made between draft versions -03 and -04:
1. Change to conform to the new IPR, Copyright, etc., notice
requirements.
2. Change in some section headers for clarity.
3. Drop section on wildcards.
4. Add emphasis on loss of case preservation due to name compression.
5. Add references to RFCs 1995 and 3092.
-04 to -05 Changes
The following changes were made between draft versions -04 and -05:
1. More clearly state that this draft updates RFCs 1034, 1035 [STD
13].
2. Add informative references to ISO 8859-1 and ISO 8859-2.
3. Fix hyphenation and capitalization nits.
D. Eastlake 3rd [Page 11]
INTERNET-DRAFT DNS Case Insensitivity
-05 to -06 Changes
The following changes were made between draft version -05 and -06.
1. Add notation to the RFC Editor that the draft version change
summaries are to be removed before RFC publication.
2. Additional text explaining why labe case insensitivity is CLASS
independent.
3. Changes and additional text clarifying that the fact that
inconsistent case in data loaded into DNS may result in
unpredicatable or inconsistent case in DNS storage but has no effect
on the completeness of RR sets retrieved.
4. Add reference to [RFC 3363] and update reference to [RFC 2535] to
be to [RFC 4034].
D. Eastlake 3rd [Page 12]
INTERNET-DRAFT DNS Case Insensitivity
Author's Address
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1 508-786-7554 (w)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires January 2006.
Its file name is draft-ietf-dnsext-insensitive-06.txt.
D. Eastlake 3rd [Page 13]

334
contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-02.txt Normal file
View File

@ -0,0 +1,334 @@
DNS Extensions Working Group J. Schlyter
Internet-Draft May 19, 2005
Expires: November 20, 2005
RFC 3597 Interoperability Report
draft-ietf-dnsext-interop3597-02.txt
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 20, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo documents the result from the RFC 3597 (Handling of Unknown
DNS Resource Record Types) interoperability testing.
Schlyter Expires November 20, 2005 [Page 1]
Internet-Draft RFC 3597 Interoperability Report May 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Implementations . . . . . . . . . . . . . . . . . . . . . . . 3
3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Authoritative Primary Name Server . . . . . . . . . . . . 3
3.2 Authoritative Secondary Name Server . . . . . . . . . . . 3
3.3 Full Recursive Resolver . . . . . . . . . . . . . . . . . 4
3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . 4
3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . 4
4. Problems found . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Normative References . . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4
A. Test zone data . . . . . . . . . . . . . . . . . . . . . . . . 5
Intellectual Property and Copyright Statements . . . . . . . . 6
Schlyter Expires November 20, 2005 [Page 2]
Internet-Draft RFC 3597 Interoperability Report May 2005
1. Introduction
This memo documents the result from the RFC 3597 (Handling of Unknown
DNS Resource Record Types) interoperability testing. The test was
performed during June and July 2004 by request of the IETF DNS
Extensions Working Group.
2. Implementations
The following is a list, in alphabetic order, of implementations
tested for compliance with RFC 3597:
DNSJava 1.6.4
ISC BIND 8.4.5
ISC BIND 9.3.0
NSD 2.1.1
Net::DNS 0.47 patchlevel 1
Nominum ANS 2.2.1.0.d
These implementations covers the following functions (number of
implementations tested for each function in paranthesis):
Authoritative Name Servers (4)
Full Recursive Resolver (2)
Stub Resolver (4)
DNSSEC Zone Signers (2)
All listed implementations are genetically different.
3. Tests
The following tests was been performed to validate compliance with
RFC 3597 section 3 ("Transparency"), 4 ("Domain Name Compression")
and 5 ("Text Representation").
3.1 Authoritative Primary Name Server
The test zone data (Appendix A) was loaded into the name server
implementation and the server was queried for the loaded information.
3.2 Authoritative Secondary Name Server
The test zone data (Appendix A) was transferred using AXFR from
another name server implementation and the server was queried for the
transferred information.
Schlyter Expires November 20, 2005 [Page 3]
Internet-Draft RFC 3597 Interoperability Report May 2005
3.3 Full Recursive Resolver
A recursive resolver was queried for resource records from a domain
with the test zone data (Appendix A).
3.4 Stub Resolver
A stub resolver was used to query resource records from a domain with
the test zone data (Appendix A).
3.5 DNSSEC Signer
A DNSSEC signer was used to sign a zone with test zone data
(Appendix A).
4. Problems found
Two implementations had problems with text presentation of zero
length RDATA.
One implementation had problems with text presentation of RR type
code and classes >= 4096.
Bug reports were filed for problems found.
5. Summary
Unknown type codes works in the tested authoritative servers,
recursive resolvers and stub clients.
No changes are needed to advance RFC 3597 to draft standard.
6. Normative References
[1] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
Types", RFC 3597, September 2003.
Author's Address
Jakob Schlyter
Email: jakob@rfc.se
Schlyter Expires November 20, 2005 [Page 4]
Internet-Draft RFC 3597 Interoperability Report May 2005
Appendix A. Test zone data
; A-record encoded as TYPE1
a TYPE1 \# 4 7f000001
a TYPE1 192.0.2.1
a A \# 4 7f000002
; draft-ietf-secsh-dns-05.txt
sshfp TYPE44 \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e
; bogus test record (from RFC 3597)
type731 TYPE731 \# 6 abcd (
ef 01 23 45 )
; zero length RDATA (from RFC 3597)
type62347 TYPE62347 \# 0
Schlyter Expires November 20, 2005 [Page 5]
Internet-Draft RFC 3597 Interoperability Report May 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schlyter Expires November 20, 2005 [Page 6]

1740
contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-43.txt Normal file
View File

File diff suppressed because it is too large Load Diff

2072
contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt Normal file
View File

File diff suppressed because it is too large Load Diff

464
contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt Normal file
View File

@ -0,0 +1,464 @@
INTERNET-DRAFT DSA Information in the DNS
OBSOLETES: RFC 2536 Donald E. Eastlake 3rd
Motorola Laboratories
Expires: January 2006 July 2005
DSA Keying and Signature Information in the DNS
--- ------ --- --------- ----------- -- --- ---
<draft-ietf-dnsext-rfc2536bis-dsa-06.txt>
Donald E. Eastlake 3rd
Status of This Document
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.
Distribution of this document is unlimited. Comments should be sent
to the DNS extensions working group mailing list
<namedroppers@ops.ietf.org>.
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 a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
The standard method of encoding US Government Digital Signature
Algorithm keying and signature information for use in the Domain Name
System is specified.
Copyright Notice
Copyright (C) The Internet Society 2005. All Rights Reserved.
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT DSA Information in the DNS
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Copyright Notice...........................................1
Table of Contents..........................................2
1. Introduction............................................3
2. DSA Keying Information..................................3
3. DSA Signature Information...............................4
4. Performance Considerations..............................4
5. Security Considerations.................................5
6. IANA Considerations.....................................5
Copyright and Disclaimer...................................5
Normative References.......................................7
Informative References.....................................7
Authors Address............................................8
Expiration and File Name...................................8
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT DSA Information in the DNS
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
other information [RFC 1034, 1035]. The DNS has been extended to
include digital signatures and cryptographic keys as described in
[RFC 4033, 4034, 4035] and additional work is underway which would
require the storage of keying and signature information in the DNS.
This document describes how to encode US Government Digital Signature
Algorithm (DSA) keys and signatures in the DNS. Familiarity with the
US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
2. DSA Keying Information
When DSA public keys are stored in the DNS, the structure of the
relevant part of the RDATA part of the RR being used is the fields
listed below in the order given.
The period of key validity is not included in this data but is
indicated separately, for example by an RR such as RRSIG which signs
and authenticates the RR containing the keying information.
Field Size
----- ----
T 1 octet
Q 20 octets
P 64 + T*8 octets
G 64 + T*8 octets
Y 64 + T*8 octets
As described in [FIPS 186-2] and [Schneier], T is a key size
parameter chosen such that 0 <= T <= 8. (The meaning if the T octet
is greater than 8 is reserved and the remainder of the data may have
a different format in that case.) Q is a prime number selected at
key generation time such that 2**159 < Q < 2**160. Thus Q is always
20 octets long and, as with all other fields, is stored in "big-
endian" network order. P, G, and Y are calculated as directed by the
[FIPS 186-2] key generation algorithm [Schneier]. P is in the range
2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G
and Y are quantities modulo P and so can be up to the same length as
P and are allocated fixed size fields with the same number of octets
as P.
During the key generation process, a random number X must be
generated such that 1 <= X <= Q-1. X is the private key and is used
in the final step of public key generation where Y is computed as
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT DSA Information in the DNS
Y = G**X mod P
3. DSA Signature Information
The portion of the RDATA area used for US Digital Signature Algorithm
signature information is shown below with fields in the order they
are listed and the contents of each multi-octet field in "big-endian"
network order.
Field Size
----- ----
T 1 octet
R 20 octets
S 20 octets
First, the data signed must be determined. Then the following steps
are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
specified in the public key [Schneier]:
hash = SHA-1 ( data )
Generate a random K such that 0 < K < Q.
R = ( G**K mod P ) mod Q
S = ( K**(-1) * (hash + X*R) ) mod Q
For information on the SHA-1 hash function see [FIPS 180-2] and [RFC
3174].
Since Q is 160 bits long, R and S can not be larger than 20 octets,
which is the space allocated.
T is copied from the public key. It is not logically necessary in
the SIG but is present so that values of T > 8 can more conveniently
be used as an escape for extended versions of DSA or other algorithms
as later standardized.
4. Performance Considerations
General signature generation speeds are roughly the same for RSA [RFC
3110] and DSA. With sufficient pre-computation, signature generation
with DSA is faster than RSA. Key generation is also faster for DSA.
However, signature verification is an order of magnitude slower than
RSA when the RSA public exponent is chosen to be small, as is
recommended for some applications.
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT DSA Information in the DNS
Current DNS implementations are optimized for small transfers,
typically less than 512 bytes including DNS overhead. Larger
transfers will perform correctly and extensions have been
standardized [RFC 2671] to make larger transfers more efficient, it
is still advisable at this time to make reasonable efforts to
minimize the size of RR sets containing keying and/or signature
inforamtion consistent with adequate security.
5. Security Considerations
Keys retrieved from the DNS should not be trusted unless (1) they
have been securely obtained from a secure resolver or independently
verified by the user and (2) this secure resolver and secure
obtainment or independent verification conform to security policies
acceptable to the user. As with all cryptographic algorithms,
evaluating the necessary strength of the key is essential and
dependent on local policy.
The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
current DSA standard may limit the security of DSA. For particular
applications, implementors are encouraged to consider the range of
available algorithms and key sizes.
DSA assumes the ability to frequently generate high quality random
numbers. See [random] for guidance. DSA is designed so that if
biased rather than random numbers are used, high bandwidth covert
channels are possible. See [Schneier] and more recent research. The
leakage of an entire DSA private key in only two DSA signatures has
been demonstrated. DSA provides security only if trusted
implementations, including trusted random number generation, are
used.
6. IANA Considerations
Allocation of meaning to values of the T parameter that are not
defined herein (i.e., > 8 ) requires an IETF standards actions. It
is intended that values unallocated herein be used to cover future
extensions of the DSS standard.
Copyright and Disclaimer
Copyright (C) The Internet Society (2005). 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.
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT DSA Information in the DNS
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 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.
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT DSA Information in the DNS
Normative References
[FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
Signature Standard, 27 January 2000.
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
Informative References
[RFC 1034] - "Domain names - concepts and facilities", P.
Mockapetris, 11/01/1987.
[RFC 1035] - "Domain names - implementation and specification", P.
Mockapetris, 11/01/1987.
[RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
1999.
[RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
(DNS)", D. Eastlake 3rd. May 2001.
[RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
Jones, September 2001.
[RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC 4033, March
2005.
[RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Extensions", RFC
4035, March 2005.
[RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[Schneier] - "Applied Cryptography Second Edition: protocols,
algorithms, and source code in C" (second edition), Bruce Schneier,
1996, John Wiley and Sons, ISBN 0-471-11709-9.
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT DSA Information in the DNS
Authors Address
Donald E. Eastlake 3rd
Motorola Labortories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1-508-786-7554(w)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires in January 2006.
Its file name is draft-ietf-dnsext-rfc2536bis-dsa-06.txt.
D. Eastlake 3rd [Page 8]

840
contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt Normal file
View File

@ -0,0 +1,840 @@
Network Working Group S. Josefsson
Internet-Draft August 30, 2005
Expires: March 3, 2006
Storing Certificates in the Domain Name System (DNS)
draft-ietf-dnsext-rfc2538bis-04
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 March 3, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Cryptographic public keys are frequently published and their
authenticity demonstrated by certificates. A CERT resource record
(RR) is defined so that such certificates and related certificate
revocation lists can be stored in the Domain Name System (DNS).
This document obsoletes RFC 2538.
Josefsson Expires March 3, 2006 [Page 1]
Internet-Draft Storing Certificates in the DNS August 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3
2.1. Certificate Type Values . . . . . . . . . . . . . . . . . 4
2.2. Text Representation of CERT RRs . . . . . . . . . . . . . 5
2.3. X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6
3.1. Content-based X.509 CERT RR Names . . . . . . . . . . . . 7
3.2. Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8
3.3. Content-based OpenPGP CERT RR Names . . . . . . . . . . . 9
3.4. Purpose-based OpenPGP CERT RR Names . . . . . . . . . . . 9
3.5. Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . . 9
4. Performance Considerations . . . . . . . . . . . . . . . . . . 10
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Josefsson Expires March 3, 2006 [Page 2]
Internet-Draft Storing Certificates in the DNS August 2005
1. Introduction
Public keys are frequently published in the form of a certificate and
their authenticity is commonly demonstrated by certificates and
related certificate revocation lists (CRLs). A certificate is a
binding, through a cryptographic digital signature, of a public key,
a validity interval and/or conditions, and identity, authorization,
or other information. A certificate revocation list is a list of
certificates that are revoked, and incidental information, all signed
by the signer (issuer) of the revoked certificates. Examples are
X.509 certificates/CRLs in the X.500 directory system or OpenPGP
certificates/revocations used by OpenPGP software.
Section 2 below specifies a CERT resource record (RR) for the storage
of certificates in the Domain Name System [1] [2].
Section 3 discusses appropriate owner names for CERT RRs.
Sections 4, 5, and 6 below cover performance, IANA, and security
considerations, respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [3].
2. The CERT Resource Record
The CERT resource record (RR) has the structure given below. Its RR
type code is 37.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | key tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| algorithm | /
+---------------+ certificate or CRL /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
The type field is the certificate type as defined in section 2.1
below.
The key tag field is the 16 bit value computed for the key embedded
in the certificate, using the RRSIG Key Tag algorithm described in
Appendix B of [10]. This field is used as an efficiency measure to
pick which CERT RRs may be applicable to a particular key. The key
Josefsson Expires March 3, 2006 [Page 3]
Internet-Draft Storing Certificates in the DNS August 2005
tag can be calculated for the key in question and then only CERT RRs
with the same key tag need be examined. However, the key must always
be transformed to the format it would have as the public key portion
of a DNSKEY RR before the key tag is computed. This is only possible
if the key is applicable to an algorithm (and limits such as key size
limits) defined for DNS security. If it is not, the algorithm field
MUST BE zero and the tag field is meaningless and SHOULD BE zero.
The algorithm field has the same meaning as the algorithm field in
DNSKEY and RRSIG RRs [10], except that a zero algorithm field
indicates the algorithm is unknown to a secure DNS, which may simply
be the result of the algorithm not having been standardized for
DNSSEC.
2.1. Certificate Type Values
The following values are defined or reserved:
Value Mnemonic Certificate Type
----- -------- ----------------
0 reserved
1 PKIX X.509 as per PKIX
2 SPKI SPKI certificate
3 PGP OpenPGP packet
4 IPKIX The URL of an X.509 data object
5 ISPKI The URL of an SPKI certificate
6 IPGP The URL of an OpenPGP packet
7-252 available for IANA assignment
253 URI URI private
254 OID OID private
255-65534 available for IANA assignment
65535 reserved
The PKIX type is reserved to indicate an X.509 certificate conforming
to the profile being defined by the IETF PKIX working group. The
certificate section will start with a one-byte unsigned OID length
and then an X.500 OID indicating the nature of the remainder of the
certificate section (see 2.3 below). (NOTE: X.509 certificates do
not include their X.500 directory type designating OID as a prefix.)
The SPKI type is reserved to indicate the SPKI certificate format
[13], for use when the SPKI documents are moved from experimental
status.
The PGP type indicates an OpenPGP packet as described in [6] and its
extensions and successors. Two uses are to transfer public key
material and revocation signatures. The data is binary, and MUST NOT
be encoded into an ASCII armor. An implementation SHOULD process
Josefsson Expires March 3, 2006 [Page 4]
Internet-Draft Storing Certificates in the DNS August 2005
transferable public keys as described in section 10.1 of [6], but it
MAY handle additional OpenPGP packets.
The IPKIX, ISPKI and IPGP types indicate a URL which will serve the
content that would have been in the "certificate, CRL or URL" field
of the corresponding (PKIX, SPKI or PGP) packet types. These types
are known as "indirect". These packet types MUST be used when the
content is too large to fit in the CERT RR, and MAY be used at the
implementer's discretion. They SHOULD NOT be used where the entire
UDP packet would have fit in 512 bytes.
The URI private type indicates a certificate format defined by an
absolute URI. The certificate portion of the CERT RR MUST begin with
a null terminated URI [5] and the data after the null is the private
format certificate itself. The URI SHOULD be such that a retrieval
from it will lead to documentation on the format of the certificate.
Recognition of private certificate types need not be based on URI
equality but can use various forms of pattern matching so that, for
example, subtype or version information can also be encoded into the
URI.
The OID private type indicates a private format certificate specified
by an ISO OID prefix. The certificate section will start with a one-
byte unsigned OID length and then a BER encoded OID indicating the
nature of the remainder of the certificate section. This can be an
X.509 certificate format or some other format. X.509 certificates
that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
type, not the OID private type. Recognition of private certificate
types need not be based on OID equality but can use various forms of
pattern matching such as OID prefix.
2.2. Text Representation of CERT RRs
The RDATA portion of a CERT RR has the type field as an unsigned
decimal integer or as a mnemonic symbol as listed in section 2.1
above.
The key tag field is represented as an unsigned decimal integer.
The algorithm field is represented as an unsigned decimal integer or
a mnemonic symbol as listed in [10].
The certificate / CRL portion is represented in base 64 [14] and may
be divided up into any number of white space separated substrings,
down to single base 64 digits, which are concatenated to obtain the
full signature. These substrings can span lines using the standard
parenthesis.
Josefsson Expires March 3, 2006 [Page 5]
Internet-Draft Storing Certificates in the DNS August 2005
Note that the certificate / CRL portion may have internal sub-fields,
but these do not appear in the master file representation. For
example, with type 254, there will be an OID size, an OID, and then
the certificate / CRL proper. But only a single logical base 64
string will appear in the text representation.
2.3. X.509 OIDs
OIDs have been defined in connection with the X.500 directory for
user certificates, certification authority certificates, revocations
of certification authority, and revocations of user certificates.
The following table lists the OIDs, their BER encoding, and their
length-prefixed hex format for use in CERT RRs:
id-at-userCertificate
= { joint-iso-ccitt(2) ds(5) at(4) 36 }
== 0x 03 55 04 24
id-at-cACertificate
= { joint-iso-ccitt(2) ds(5) at(4) 37 }
== 0x 03 55 04 25
id-at-authorityRevocationList
= { joint-iso-ccitt(2) ds(5) at(4) 38 }
== 0x 03 55 04 26
id-at-certificateRevocationList
= { joint-iso-ccitt(2) ds(5) at(4) 39 }
== 0x 03 55 04 27
3. Appropriate Owner Names for CERT RRs
It is recommended that certificate CERT RRs be stored under a domain
name related to their subject, i.e., the name of the entity intended
to control the private key corresponding to the public key being
certified. It is recommended that certificate revocation list CERT
RRs be stored under a domain name related to their issuer.
Following some of the guidelines below may result in the use in DNS
names of characters that require DNS quoting which is to use a
backslash followed by the octal representation of the ASCII code for
the character (e.g., \000 for NULL).
The choice of name under which CERT RRs are stored is important to
clients that perform CERT queries. In some situations, the clients
may not know all information about the CERT RR object it wishes to
retrieve. For example, a client may not know the subject name of an
X.509 certificate, or the e-mail address of the owner of an OpenPGP
key. Further, the client might only know the hostname of a service
that uses X.509 certificates or the Key ID of an OpenPGP key.
Josefsson Expires March 3, 2006 [Page 6]
Internet-Draft Storing Certificates in the DNS August 2005
Therefore, two owner name guidelines are defined: content-based owner
names and purpose-based owner names. A content-based owner name is
derived from the content of the CERT RR data; for example, the
Subject field in an X.509 certificate or the User ID field in OpenPGP
keys. A purpose-based owner name is a name that a client retrieving
CERT RRs MUST already know; for example, the host name of an X.509
protected service or the Key ID of an OpenPGP key. The content-based
and purpose-based owner name MAY be the same; for example, when a
client looks up a key based on the From: address of an incoming
e-mail.
Implementations SHOULD use the purpose-based owner name guidelines
described in this document, and MAY use CNAMEs of content-based owner
names (or other names), pointing to the purpose-based owner name.
3.1. Content-based X.509 CERT RR Names
Some X.509 versions permit multiple names to be associated with
subjects and issuers under "Subject Alternate Name" and "Issuer
Alternate Name". For example, X.509v3 has such Alternate Names with
an ASN.1 specification as follows:
GeneralName ::= CHOICE {
otherName [0] INSTANCE OF OTHER-NAME,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] EXPLICIT OR-ADDRESS.&Type,
directoryName [4] EXPLICIT Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER
}
The recommended locations of CERT storage are as follows, in priority
order:
1. If a domain name is included in the identification in the
certificate or CRL, that should be used.
2. If a domain name is not included but an IP address is included,
then the translation of that IP address into the appropriate
inverse domain name should be used.
3. If neither of the above is used, but a URI containing a domain
name is present, that domain name should be used.
4. If none of the above is included but a character string name is
included, then it should be treated as described for OpenPGP
names below.
Josefsson Expires March 3, 2006 [Page 7]
Internet-Draft Storing Certificates in the DNS August 2005
5. If none of the above apply, then the distinguished name (DN)
should be mapped into a domain name as specified in [4].
Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/
DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)
string "John (the Man) Doe", (b) domain name john-doe.com, and (c)
uri <https://www.secure.john-doe.com:8080/>. The storage locations
recommended, in priority order, would be
1. john-doe.com,
2. www.secure.john-doe.com, and
3. Doe.com.xy.
Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
(c) string "James Hacker <hacker@mail.widget.foo.example>". The
storage locations recommended, in priority order, would be
1. widget.foo.example,
2. 201.13.251.10.in-addr.arpa, and
3. hacker.mail.widget.foo.example.
3.2. Purpose-based X.509 CERT RR Names
Due to the difficulty for clients that do not already possess a
certificate to reconstruct the content-based owner name, purpose-
based owner names are recommended in this section. Recommendations
for purpose-based owner names vary per scenario. The following table
summarizes the purpose-based X.509 CERT RR owner name guidelines for
use with S/MIME [16], SSL/TLS [11], and IPSEC [12]:
Scenario Owner name
------------------ ----------------------------------------------
S/MIME Certificate Standard translation of an RFC 2822 email
address. Example: An S/MIME certificate for
"postmaster@example.org" will use a standard
hostname translation of the owner name,
"postmaster.example.org".
TLS Certificate Hostname of the TLS server.
IPSEC Certificate Hostname of the IPSEC machine and/or, for IPv4
or IPv6 addresses, the fully qualified domain
name in the appropriate reverse domain.
An alternate approach for IPSEC is to store raw public keys [15].
Josefsson Expires March 3, 2006 [Page 8]
Internet-Draft Storing Certificates in the DNS August 2005
3.3. Content-based OpenPGP CERT RR Names
OpenPGP signed keys (certificates) use a general character string
User ID [6]. However, it is recommended by OpenPGP that such names
include the RFC 2822 [8] email address of the party, as in "Leslie
Example <Leslie@host.example>". If such a format is used, the CERT
should be under the standard translation of the email address into a
domain name, which would be leslie.host.example in this case. If no
RFC 2822 name can be extracted from the string name, no specific
domain name is recommended.
If a user has more than one email address, the CNAME type can be used
to reduce the amount of data stored in the DNS. Example:
$ORIGIN example.org.
smith IN CERT PGP 0 0 <OpenPGP binary>
john.smith IN CNAME smith
js IN CNAME smith
3.4. Purpose-based OpenPGP CERT RR Names
Applications that receive an OpenPGP packet containing encrypted or
signed data but do not know the email address of the sender will have
difficulties constructing the correct owner name and cannot use the
content-based owner name guidelines. However, these clients commonly
know the key fingerprint or the Key ID. The key ID is found in
OpenPGP packets, and the key fingerprint is commonly found in
auxilliary data that may be available. In this case, use of an owner
name identical to the key fingerprint and the key ID expressed in
hexadecimal [14] is recommended. Example:
$ORIGIN example.org.
0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
F835EDA21E94B565716F IN CERT PGP ...
B565716F IN CERT PGP ...
If the same key material is stored for several owner names, the use
of CNAME may be used to avoid data duplication. Note that CNAME is
not always applicable, because it maps one owner name to the other
for all purposes, which may be sub-optimal when two keys with the
same Key ID are stored.
3.5. Owner names for IPKIX, ISPKI, and IPGP
These types are stored under the same owner names, both purpose- and
content-based, as the PKIX, SPKI and PGP types.
Josefsson Expires March 3, 2006 [Page 9]
Internet-Draft Storing Certificates in the DNS August 2005
4. Performance Considerations
Current Domain Name System (DNS) implementations are optimized for
small transfers, typically not more than 512 bytes including
overhead. While larger transfers will perform correctly and work is
underway to make larger transfers more efficient, it is still
advisable at this time to make every reasonable effort to minimize
the size of certificates stored within the DNS. Steps that can be
taken may include using the fewest possible optional or extension
fields and using short field values for necessary variable length
fields.
The RDATA field in the DNS protocol may only hold data of size 65535
octets (64kb) or less. This means that each CERT RR MUST NOT contain
more than 64kb of payload, even if the corresponding certificate or
certificate revocation list is larger. This document addresses this
by defining "indirect" data types for each normal type.
5. Contributors
The majority of this document is copied verbatim from RFC 2538, by
Donald Eastlake 3rd and Olafur Gudmundsson.
6. Acknowledgements
Thanks to David Shaw and Michael Graff for their contributions to
earlier works that motivated, and served as inspiration for, this
document.
This document was improved by suggestions and comments from Olivier
Dubuisson, Olaf M. Kolkman, Ben Laurie, Edward Lewis, Jason
Sloderbeck, Samuel Weiler, and Florian Weimer. No doubt the list is
incomplete. We apologize to anyone we left out.
7. Security Considerations
By definition, certificates contain their own authenticating
signature. Thus, it is reasonable to store certificates in non-
secure DNS zones or to retrieve certificates from DNS with DNS
security checking not implemented or deferred for efficiency. The
results MAY be trusted if the certificate chain is verified back to a
known trusted key and this conforms with the user's security policy.
Alternatively, if certificates are retrieved from a secure DNS zone
with DNS security checking enabled and are verified by DNS security,
Josefsson Expires March 3, 2006 [Page 10]
Internet-Draft Storing Certificates in the DNS August 2005
the key within the retrieved certificate MAY be trusted without
verifying the certificate chain if this conforms with the user's
security policy.
If an organization chooses to issue certificates for it's employees,
placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC)
is in use, it is possible for someone to enumerate all employees of
the organization. This is usually not considered desirable, for the
same reason enterprise phone listings are not often publicly
published and are even mark confidential.
When the URI type is used, it should be understood that it introduces
an additional indirection that may allow for a new attack vector.
One method to secure that indirection is to include a hash of the
certificate in the URI itself.
CERT RRs are not used by DNSSEC [9], so there are no security
considerations related to CERT RRs and securing the DNS itself.
If DNSSEC is used, then the non-existence of a CERT RR and,
consequently, certificates or revocation lists can be securely
asserted. Without DNSSEC, this is not possible.
8. IANA Considerations
Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
only be assigned by an IETF standards action [7]. This document
assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE. Certificate
types 0x0100 through 0xFEFF are assigned through IETF Consensus [7]
based on RFC documentation of the certificate type. The availability
of private types under 0x00FD and 0x00FE should satisfy most
requirements for proprietary or private types.
The CERT RR reuses the DNS Security Algorithm Numbers registry. In
particular, the CERT RR requires that algorithm number 0 remain
reserved, as described in Section 2. The IANA is directed to
reference the CERT RR as a user of this registry and value 0, in
particular.
9. Changes since RFC 2538
1. Editorial changes to conform with new document requirements,
including splitting reference section into two parts and
updating the references to point at latest versions, and to add
some additional references.
Josefsson Expires March 3, 2006 [Page 11]
Internet-Draft Storing Certificates in the DNS August 2005
2. Improve terminology. For example replace "PGP" with "OpenPGP",
to align with RFC 2440.
3. In section 2.1, clarify that OpenPGP public key data are binary,
not the ASCII armored format, and reference 10.1 in RFC 2440 on
how to deal with OpenPGP keys, and acknowledge that
implementations may handle additional packet types.
4. Clarify that integers in the representation format are decimal.
5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
terminology. Improve reference for Key Tag Algorithm
calculations.
6. Add examples that suggest use of CNAME to reduce bandwidth.
7. In section 3, appended the last paragraphs that discuss
"content-based" vs "purpose-based" owner names. Add section 3.2
for purpose-based X.509 CERT owner names, and section 3.4 for
purpose-based OpenPGP CERT owner names.
8. Added size considerations.
9. The SPKI types has been reserved, until RFC 2692/2693 is moved
from the experimental status.
10. Added indirect types IPKIX, ISPKI, and IPGP.
Appendix A. Copying conditions
Regarding the portion of this document that was written by Simon
Josefsson ("the author", for the remainder of this section), the
author makes no guarantees and is not responsible for any damage
resulting from its use. The author grants irrevocable permission to
anyone to use, modify, and distribute it in any way that does not
diminish the rights of anyone else to use, modify, and distribute it,
provided that redistributed derivative works do not contain
misleading author or version information. Derivative works need not
be licensed under similar terms.
10. References
10.1. Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
Josefsson Expires March 3, 2006 [Page 12]
Internet-Draft Storing Certificates in the DNS August 2005
"Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
January 1998.
[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[6] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[8] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[10] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
10.2. Informative References
[11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[12] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[13] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
September 1999.
[14] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003.
[15] Richardson, M., "A Method for Storing IPsec Keying Material in
DNS", RFC 4025, March 2005.
[16] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004.
Josefsson Expires March 3, 2006 [Page 13]
Internet-Draft Storing Certificates in the DNS August 2005
Author's Address
Simon Josefsson
Email: simon@josefsson.org
Josefsson Expires March 3, 2006 [Page 14]
Internet-Draft Storing Certificates in the DNS August 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Josefsson Expires March 3, 2006 [Page 15]

580
contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt Normal file
View File

@ -0,0 +1,580 @@
INTERNET-DRAFT Diffie-Hellman Information in the DNS
OBSOLETES: RFC 2539 Donald E. Eastlake 3rd
Motorola Laboratories
Expires: January 2006 July 2005
Storage of Diffie-Hellman Keying Information in the DNS
------- -- -------------- ------ ----------- -- --- ---
<draft-ietf-dnsext-rfc2539bis-dhk-06.txt>
Status of This Document
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.
Distribution of this document is unlimited. Comments should be sent
to the DNS extensions working group mailing list
<namedroppers@ops.ietf.org>.
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 a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
The standard method for encoding Diffie-Hellman keys in the Domain
Name System is specified.
Copyright
Copyright (C) The Internet Society 2005.
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
Acknowledgements
Part of the format for Diffie-Hellman keys and the description
thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
and Hemma Prafullchandra. In addition, the following persons
provided useful comments that were incorporated into the predecessor
of this document: Ran Atkinson, Thomas Narten.
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Copyright..................................................1
Acknowledgements...........................................2
Table of Contents..........................................2
1. Introduction............................................3
1.1 About This Document....................................3
1.2 About Diffie-Hellman...................................3
2. Encoding Diffie-Hellman Keying Information..............4
3. Performance Considerations..............................5
4. IANA Considerations.....................................5
5. Security Considerations.................................5
Copyright and Disclaimer...................................5
Normative References.......................................7
Informative Refences.......................................7
Author Address.............................................8
Expiration and File Name...................................8
Appendix A: Well known prime/generator pairs...............9
A.1. Well-Known Group 1: A 768 bit prime..................9
A.2. Well-Known Group 2: A 1024 bit prime.................9
A.3. Well-Known Group 3: A 1536 bit prime................10
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
similar information [RFC 1034, 1035]. The DNS has been extended to
include digital signatures and cryptographic keys as described in
[RFC 4033, 4034, 4035] and additonal work is underway which would use
the storage of keying information in the DNS.
1.1 About This Document
This document describes how to store Diffie-Hellman keys in the DNS.
Familiarity with the Diffie-Hellman key exchange algorithm is assumed
[Schneier, RFC 2631].
1.2 About Diffie-Hellman
Diffie-Hellman requires two parties to interact to derive keying
information which can then be used for authentication. Thus Diffie-
Hellman is inherently a key agreement algorithm. As a result, no
format is defined for Diffie-Hellman "signature information". For
example, assume that two parties have local secrets "i" and "j".
Assume they each respectively calculate X and Y as follows:
X = g**i ( mod p )
Y = g**j ( mod p )
They exchange these quantities and then each calculates a Z as
follows:
Zi = Y**i ( mod p )
Zj = X**j ( mod p )
Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
secret between the two parties that an adversary who does not know i
or j will not be able to learn from the exchanged messages (unless
the adversary can derive i or j by performing a discrete logarithm
mod p which is hard for strong p and g).
The private key for each party is their secret i (or j). The public
key is the pair p and g, which must be the same for the parties, and
their individual X (or Y).
For further information about Diffie-Hellman and precautions to take
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
in deciding on a p and g, see [RFC 2631].
2. Encoding Diffie-Hellman Keying Information
When Diffie-Hellman keys appear within the RDATA portion of a RR,
they are encoded as shown below.
The period of key validity is not included in this data but is
indicated separately, for example by an RR such as RRSIG which signs
and authenticates the RR containing the keying information.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KEY flags | protocol | algorithm=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prime length (or flag) | prime (p) (or special) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ prime (p) (variable length) | generator length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| generator (g) (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| public value length | public value (variable length)/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ public value (g^i mod p) (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prime length is the length of the Diffie-Hellman prime (p) in bytes
if it is 16 or greater. Prime contains the binary representation of
the Diffie-Hellman prime with most significant byte first (i.e., in
network order). If "prime length" field is 1 or 2, then the "prime"
field is actually an unsigned index into a table of 65,536
prime/generator pairs and the generator length SHOULD be zero. See
Appedix A for defined table entries and Section 4 for information on
allocating additional table entries. The meaning of a zero or 3
through 15 value for "prime length" is reserved.
Generator length is the length of the generator (g) in bytes.
Generator is the binary representation of generator with most
significant byte first. PublicValueLen is the Length of the Public
Value (g**i (mod p)) in bytes. PublicValue is the binary
representation of the DH public value with most significant byte
first.
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
3. Performance Considerations
Current DNS implementations are optimized for small transfers,
typically less than 512 bytes including DNS overhead. Larger
transfers will perform correctly and extensions have been
standardized [RFC 2671] to make larger transfers more efficient. But
it is still advisable at this time to make reasonable efforts to
minimize the size of RR sets containing keying information consistent
with adequate security.
4. IANA Considerations
Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
an IETF consensus as defined in [RFC 2434].
Well known prime/generator pairs number 0x0000 through 0x07FF can
only be assigned by an IETF standards action. [RFC 2539], the
Proposed Standard predecessor of this document, assigned 0x0001
through 0x0002. This document additionally assigns 0x0003. Pairs
number 0s0800 through 0xBFFF can be assigned based on RFC
documentation. Pairs number 0xC000 through 0xFFFF are available for
private use and are not centrally coordinated. Use of such private
pairs outside of a closed environment may result in conflicts and/or
security failures.
5. Security Considerations
Keying information retrieved from the DNS should not be trusted
unless (1) it has been securely obtained from a secure resolver or
independently verified by the user and (2) this secure resolver and
secure obtainment or independent verification conform to security
policies acceptable to the user. As with all cryptographic
algorithms, evaluating the necessary strength of the key is important
and dependent on security policy.
In addition, the usual Diffie-Hellman key strength considerations
apply. (p-1)/2 should also be prime, g should be primitive mod p, p
should be "large", etc. See [RFC 2631, Schneier].
Copyright and Disclaimer
Copyright (C) The Internet Society (2005). 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.
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
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 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.
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
Normative References
[RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
1999.
[RFC 2434] - "Guidelines for Writing an IANA Considerations Section
in RFCs", T. Narten, H. Alvestrand, October 1998.
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
Informative Refences
[RFC 1034] - "Domain names - concepts and facilities", P.
Mockapetris, November 1987.
[RFC 1035] - "Domain names - implementation and specification", P.
Mockapetris, November 1987.
[RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
[RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
1999.
[RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC 4033, March
2005.
[RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Extensions", RFC
4035, March 2005.
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
and Sons.
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
Author Address
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1-508-786-7554
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires in January 2006.
Its file name is draft-ietf-dnsext-rfc2539bis-dhk-06.txt.
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
Appendix A: Well known prime/generator pairs
These numbers are copied from the IPSEC effort where the derivation of
these values is more fully explained and additional information is
available.
Richard Schroeppel performed all the mathematical and computational
work for this appendix.
A.1. Well-Known Group 1: A 768 bit prime
The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its
decimal value is
155251809230070893513091813125848175563133404943451431320235
119490296623994910210725866945387659164244291000768028886422
915080371891804634263272761303128298374438082089019628850917
0691316593175367469551763119843371637221007210577919
Prime modulus: Length (32 bit words): 24, Data (hex):
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
Generator: Length (32 bit words): 1, Data (hex): 2
A.2. Well-Known Group 2: A 1024 bit prime
The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
Its decimal value is
179769313486231590770839156793787453197860296048756011706444
423684197180216158519368947833795864925541502180565485980503
646440548199239100050792877003355816639229553136239076508735
759914822574862575007425302077447712589550957937778424442426
617334727629299387668709205606050270810842907692932019128194
467627007
Prime modulus: Length (32 bit words): 32, Data (hex):
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF
Generator: Length (32 bit words): 1, Data (hex): 2
D. Eastlake 3rd [Page 9]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
A.3. Well-Known Group 3: A 1536 bit prime
The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
Its decimal value is
241031242692103258855207602219756607485695054850245994265411
694195810883168261222889009385826134161467322714147790401219
650364895705058263194273070680500922306273474534107340669624
601458936165977404102716924945320037872943417032584377865919
814376319377685986952408894019557734611984354530154704374720
774996976375008430892633929555996888245787241299381012913029
459299994792636526405928464720973038494721168143446471443848
8520940127459844288859336526896320919633919
Prime modulus Length (32 bit words): 48, Data (hex):
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
Generator: Length (32 bit words): 1, Data (hex): 2
D. Eastlake 3rd [Page 10]

755
contrib/bind9/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt Normal file
View File

@ -0,0 +1,755 @@
Network Working Group B. Laurie
Internet-Draft Nominet
Expires: March 2, 2005 R. Loomis
SAIC
September 2004
Requirements related to DNSSEC Signed Proof of Non-Existence
draft-ietf-dnsext-signed-nonexistence-requirements-01
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 March 2, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
DNSSEC-bis uses the NSEC record to provide authenticated denial of
existence of RRsets. NSEC also has the side-effect of permitting
zone enumeration, even if zone transfers have been forbidden.
Because some see this as a problem, this document has been assembled
to detail the possible requirements for denial of existence A/K/A
signed proof of non-existence.
Laurie & Loomis Expires March 2, 2005 [Page 1]
Internet-Draft signed-nonexistence-requirements September 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Non-purposes . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Zone Enumeration . . . . . . . . . . . . . . . . . . . . . . 3
4. Zone Enumeration II . . . . . . . . . . . . . . . . . . . . 4
5. Zone Enumeration III . . . . . . . . . . . . . . . . . . . . 4
6. Exposure of Contents . . . . . . . . . . . . . . . . . . . . 4
7. Zone Size . . . . . . . . . . . . . . . . . . . . . . . . . 4
8. Single Method . . . . . . . . . . . . . . . . . . . . . . . 5
9. Empty Non-terminals . . . . . . . . . . . . . . . . . . . . 5
10. Prevention of Precomputed Dictionary Attacks . . . . . . . . 6
11. DNSSEC-Adoption and Zone-Growth Relationship . . . . . . . . 6
12. Non-overlap of denial records with possible zone records . . 7
13. Exposure of Private Keys . . . . . . . . . . . . . . . . . . 7
14. Minimisation of Zone Signing Cost . . . . . . . . . . . . . 8
15. Minimisation of Asymmetry . . . . . . . . . . . . . . . . . 8
16. Minimisation of Client Complexity . . . . . . . . . . . . . 8
17. Completeness . . . . . . . . . . . . . . . . . . . . . . . . 8
18. Purity of Namespace . . . . . . . . . . . . . . . . . . . . 8
19. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 8
20. Compatibility with NSEC . . . . . . . . . . . . . . . . . . 8
21. Compatibility with NSEC II . . . . . . . . . . . . . . . . . 9
22. Compatibility with NSEC III . . . . . . . . . . . . . . . . 9
23. Coexistence with NSEC . . . . . . . . . . . . . . . . . . . 9
24. Coexistence with NSEC II . . . . . . . . . . . . . . . . . . 9
25. Protocol Design . . . . . . . . . . . . . . . . . . . . . . 9
26. Process . . . . . . . . . . . . . . . . . . . . . . . . . . 9
27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
28. Requirements notation . . . . . . . . . . . . . . . . . . . 9
29. Security Considerations . . . . . . . . . . . . . . . . . . 10
30. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
30.1 Normative References . . . . . . . . . . . . . . . . . . . 10
30.2 Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . 11
Laurie & Loomis Expires March 2, 2005 [Page 2]
Internet-Draft signed-nonexistence-requirements September 2004
1. Introduction
NSEC records allow trivial enumeration of zones - a situation that
has existed for several years but which has recently been raised as a
significant concern for DNSSECbis deployment in several zones.
Alternate proposals have been made that make zone enumeration more
difficult, and some previous proposals to modify DNSSEC had related
requirements/desirements that are relevant to the discussion. In
addition the original designs for NSEC/NXT records were based on
working group discussions and the choices made were not always
documented with context and requirements-- so some of those choices
may need to be restated as requirements. Overall, the working group
needs to better understand the requirements for denial of existence
(and certain other requirements related to DNSSECbis deployment) in
order to evaluate the proposals that may replace NSEC.
In the remainder of this document, "NSEC++" is used as shorthand for
"a denial of existence proof that will replace NSEC". "NSECbis" has
also been used as shorthand for this, but we avoid that usage since
NSECbis will not be part of DNSSECbis and therefore there might be
some confusion.
2. Non-purposes
This document does not currently document the reasons why zone
enumeration might be "bad" from a privacy, security, business, or
other perspective--except insofar as those reasons result in
requirements. Once the list of requirements is complete and vaguely
coherent, the trade-offs (reducing zone enumeration will have X cost,
while providing Y benefit) may be revisited. The editors of this
compendium received inputs on the potential reasons why zone
enumeration is bad (and there was significant discussion on the
DNSEXT WG mailing list) but that information fell outside the scope
of this document.
Note also that this document does not assume that NSEC *must* be
replaced with NSEC++, if the requirements can be met through other
methods (e.g., "white lies" with the current NSEC). As is stated
above, this document is focused on requirements collection and
(ideally) prioritization rather than on the actual implementation.
3. Zone Enumeration
Authenticated denial should not permit trivial zone enumeration.
Additional discussion: NSEC (and NXT before it) provide a linked
list that could be "walked" to trivially enumerate all the signed
records in a zone. This requirement is primarily (though not
Laurie & Loomis Expires March 2, 2005 [Page 3]
Internet-Draft signed-nonexistence-requirements September 2004
exclusively) important for zones that either are delegation-only/
-mostly or do not have reverse lookup (PTR) records configured, since
enterprises that have PTR records for all A records have already
provided a similar capability to enumerate the contents of DNS zones.
Contributor: various
4. Zone Enumeration II
Zone enumeration should be at least as difficult as it would be to
effect a dictionary attack using simple DNS queries to do the same in
an unsecured zone.
(Editor comment: it is not clear how to measure difficulty in this
case. Some examples could be monetary cost, bandwidth, processing
power or some combination of these. It has also been suggested that
the requirement is that the graph of difficulty of enumeration vs.
the fraction of the zone enumerated should be approximately the same
shape in the two cases)
Contributor: Nominet
5. Zone Enumeration III
Enumeration of a zone with random contents should computationally
infeasible.
Editor comment: this is proposed as a way of evaluating the
effectiveness of a proposal rather than as a requirement anyone would
actually have in practice.
Contributor: Alex Bligh
6. Exposure of Contents
NSEC++ should not expose any of the contents of the zone (apart from
the NSEC++ records themselves, of course).
Editor comment: this is a weaker requirement than prevention of
enumeration, but certainly any zone that satisfied this requirement
would also satisfy the trivial prevention of enumeration requirement.
Contributor: Ed Lewis
7. Zone Size
Requirement: NSEC++ should make it possible to take precautions
against trivial zone size estimates. Since not all zone owners care
Laurie & Loomis Expires March 2, 2005 [Page 4]
Internet-Draft signed-nonexistence-requirements September 2004
about others estimation of the size of a zone, it is not always
necessary to prohibit trivial estimation of the size of the zone but
NSEC++ should allow such measures.
Additional Discussion: Even with proposals based on obfuscating names
with hashes it is trivial to give very good estimates of the number
of domains in a certain zone. Just send 10 random queries and look
at the range between the two hash values returned in each NSEC++. As
hash output can be assumed to follow a rectangular random
distribution, using the mean difference between the two values, you
can estimate the total number of records. It is probably sufficient
to look at even one NSEC++, since the two hash values should follow a
(I believe) Poisson distribution.
The concern is motivated by some wording remembered from NSEC, which
stated that NSEC MUST only be present for existing owner names in the
zone, and MUST NOT be present for non-existing owner names. If
similar wording were carried over to NSEC++, introducing bogus owner
names in the hash chain (an otherwise simple solution to guard
against trivial estimates of zone size) wouldn't be allowed.
One simple attempt at solving this is to describe in the
specifications how zone signer tools can add a number of random
"junk" records.
Editor's comment: it is interesting that obfuscating names might
actually make it easier to estimate zone size.
Contributor: Simon Josefsson.
8. Single Method
Requirement: A single NSEC++ method must be able to carry both
old-style denial (i.e. plain labels) and whatever the new style
looks like. Having two separate denial methods could result in
cornercases where one method can deny the other and vice versa.
Additional discussion: This requirement can help -bis folks to a
smooth upgrade to -ter. First they'd change the method while the
content is the same, then they can change content of the method.
Contributor: Roy Arends.
9. Empty Non-terminals
Requirement: Empty-non-terminals (ENT) should remain empty. In
other words, adding NSEC++ records to an existing DNS structure
should not cause the creation of NSEC++ records (or related records)
Laurie & Loomis Expires March 2, 2005 [Page 5]
Internet-Draft signed-nonexistence-requirements September 2004
at points that are otherwise ENT.
Additional discussion: Currently NSEC complies with ENT requirement:
b.example.com NSEC a.c.example.com implies the existence of an ENT
with ownername c.example.com. NSEC2 breaks that requirement, since
the ownername is entirely hashed causing the structure to disappear.
This is why EXIST was introduced. But EXIST causes ENT to be
non-empty-terminals. Next to the dissappearance of ENT, it causes
(some) overhead since an EXIST record needs a SIG, NSEC2 and
SIG(NSEC2). DNSNR honours this requirement by hashing individual
labels instead of ownernames. However this causes very long labels.
Truncation is a measure against very long ownernames, but that is
controversial. There is a fair discussion of the validity of
truncation in the DNSNR draft, but that hasn't got proper review yet.
Contributor: Roy Arends.
(Editor comment: it is not clear to us that an EXIST record needs an
NSEC2 record, since it is a special purpose record only used for
denial of existence)
10. Prevention of Precomputed Dictionary Attacks
Requirement: NSEC++ needs to provide a method to reduce the
effectiveness of precomputed dictionary attacks.
Additional Discussion: Salt is a measure against dictionary attacks.
There are other possible measures (such as iterating hashes in
NSEC2). The salt needs to be communicated in every response, since
it is needed in every verification. Some have suggested to move the
salt to a special record instead of the denial record. I think this
is not wise. Response size has more priority over zone size. An
extra record causes a larger response than a larger existing record.
Contributor: Roy Arends.
(Editor comment: the current version of NSEC2 also has the salt in
every NSEC2 record)
11. DNSSEC-Adoption and Zone-Growth Relationship
Background: Currently with NSEC, when a delegation centric zone
deploys DNSSEC, the zone-size multiplies by a non-trivial factor even
when the DNSSEC-adoption rate of the subzones remains low--because
each delegation point creates at least one NSEC record and
corresponding signature in the parent even if the child is not
signed.
Laurie & Loomis Expires March 2, 2005 [Page 6]
Internet-Draft signed-nonexistence-requirements September 2004
Requirements: A delegation-only (or delegation-mostly) zone that is
signed but which has no signed child zones should initially need only
to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with some
minimal set of NSEC++ records to cover zone contents. Further,
during the transition of a delegation-only zone from 0% signed
children to 100% signed children, the growth in the delegation-only
zone should be roughly proportional to the percentage of signed child
zones.
Additional Discussion: This is why DNSNR has the Authoritative Only
bit. This is similar to opt-in for delegations only. This (bit) is
currently the only method to help delegation-centric zone cope with
zone-growth due to DNSSEC adoption. As an example, A delegation only
zone which deploys DNSSEC with the help of this bit, needs to add
SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex. No
more than that.
Contributor: Roy Arends.
12. Non-overlap of denial records with possible zone records
Requirement: NSEC++ records should in some way be differentiated
from regular zone records, so that there is no possibility that a
record in the zone could be duplicated by a non-existence proof
(NSEC++) record.
Additional discussion: This requirement is derived from a discussion
on the DNSEXT mailing list related to copyrights and domain names.
As was outlined there, one solution is to put NSEC++ records in a
separate namespace, e.g.: $ORIGIN co.uk.
873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your
delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345...
; for amazon.co.uk.
Contributor: various
(Editor comment: One of us still does not see why a conflict
matters. Even if there is an apparent conflict or overlap, the
"conflicting" NSEC2 name _only_ appears in NSEC2 records, and the
other name _never_ appears in NSEC2 records.)
13. Exposure of Private Keys
Private keys associated with the public keys in the DNS should be
exposed as little as possible. It is highly undesirable for private
keys to be distributed to nameservers, or to otherwise be available
in the run-time environment of nameservers.
Laurie & Loomis Expires March 2, 2005 [Page 7]
Internet-Draft signed-nonexistence-requirements September 2004
Contributors: Nominet, Olaf Kolkman, Ed Lewis
14. Minimisation of Zone Signing Cost
The additional cost of creating an NSEC++ signed zone should not
significantly exceed the cost of creating an ordinary signed zone.
Contributor: Nominet
15. Minimisation of Asymmetry
Nameservers should have to do as little additional work as necessary.
More precisely, it is desirable for any increase in cost incurred by
the nameservers to be offset by a proportionate increase in cost to
DNS `clients', e.g. stub and/or `full-service' resolvers.
Contributor: Nominet
16. Minimisation of Client Complexity
Caching, wildcards, CNAMEs, DNAMEs should continue to work without
adding too much complexity at the client side.
Contributor: Olaf Kolkman
17. Completeness
A proof of nonexistence should be possible for all nonexistent data
in the zone.
Contributor: Olaf Kolkman
18. Purity of Namespace
The name space should not be muddied with fake names or data sets.
Contributor: Ed Lewis
19. Replay Attacks
NSEC++ should not allow a replay to be used to deny existence of an
RR that actually exists.
Contributor: Ed Lewis
20. Compatibility with NSEC
NSEC++ should not introduce changes incompatible with NSEC.
Laurie & Loomis Expires March 2, 2005 [Page 8]
Internet-Draft signed-nonexistence-requirements September 2004
Contributor: Ed Lewis
21. Compatibility with NSEC II
NSEC++ should differ from NSEC in a way that is transparent to the
resolver or validator.
Contributor: Ed Lewis
22. Compatibility with NSEC III
NSEC++ should differ from NSEC as little as possible whilst achieving
other requirements.
Contributor: Alex Bligh
23. Coexistence with NSEC
NSEC++ should be optional, allowing NSEC to be used instead.
Contributor: Ed Lewis, Alex Bligh
24. Coexistence with NSEC II
NSEC++ should not impose extra work on those content with NSEC.
Contributor: Ed Lewis
25. Protocol Design
A good security protocol would allow signing the nonexistence of some
selected names without revealing anything about other names.
Contributor: Dan Bernstein
26. Process
Clearly not all of these requirements can be met. Therefore the next
phase of this document will be to either prioritise them or narrow
them down to a non-contradictory set, which should then allow us to
judge proposals on the basis of their fit.
27. Acknowledgements
28. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Laurie & Loomis Expires March 2, 2005 [Page 9]
Internet-Draft signed-nonexistence-requirements September 2004
document are to be interpreted as described in [RFC2119].
29. Security Considerations
There are currently no security considerations called out in this
draft. There will be security considerations in the choice of which
requirements will be implemented, but there are no specific security
requirements during the requirements collection process.
30. References
30.1 Normative References
[dnssecbis-protocol]
"DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some
Month 2004.
30.2 Informative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
Authors' Addresses
Ben Laurie
Nominet
17 Perryn Road
London W3 7LR
England
Phone: +44 (20) 8735 0686
EMail: ben@algroup.co.uk
Rip Loomis
Science Applications International Corporation
7125 Columbia Gateway Drive, Suite 300
Columbia, MD 21046
US
EMail: gilbert.r.loomis@saic.com
Laurie & Loomis Expires March 2, 2005 [Page 10]
Internet-Draft signed-nonexistence-requirements September 2004
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Laurie & Loomis Expires March 2, 2005 [Page 11]

1292
contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt Normal file
View File

File diff suppressed because it is too large Load Diff

1501
contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt Normal file
View File

File diff suppressed because it is too large Load Diff

730
contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-01.txt Normal file
View File

@ -0,0 +1,730 @@
Network Working Group M. StJohns
Internet-Draft Nominum, Inc.
Expires: February 16, 2006 August 15, 2005
Automated Updates of DNSSEC Trust Anchors
draft-ietf-dnsext-trustupdate-timers-01
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 February 16, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a means for automated, authenticated and
authorized updating of DNSSEC "trust anchors". The method provides
protection against single key compromise of a key in the trust point
key set. Based on the trust established by the presence of a current
anchor, other anchors may be added at the same place in the
hierarchy, and, ultimately, supplant the existing anchor.
This mechanism, if adopted, will require changes to resolver
management behavior (but not resolver resolution behavior), and the
StJohns Expires February 16, 2006 [Page 1]
Internet-Draft trustanchor-update August 2005
addition of a single flag bit to the DNSKEY record.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Compliance Nomenclature . . . . . . . . . . . . . . . . . 3
1.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . 3
2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
2.1 Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5
2.4 Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Resolver Parameters . . . . . . . . . . . . . . . . . . . 6
2.5.1 Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6
2.5.2 Remove Hold-Down Time . . . . . . . . . . . . . . . . 6
2.5.3 Minimum Trust Anchors per Trust Point . . . . . . . . 6
3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6
4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 States . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 8
5.2 Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9
5.3 Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9
5.4 Active Key Compromised . . . . . . . . . . . . . . . . . . 9
5.5 Stand-by Key Compromised . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6.1 Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10
6.2 Multiple Key Compromise . . . . . . . . . . . . . . . . . 10
6.3 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 10
7. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
StJohns Expires February 16, 2006 [Page 2]
Internet-Draft trustanchor-update August 2005
1. Introduction
As part of the reality of fielding DNSSEC (Domain Name System
Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the
community has come to the realization that there will not be one
signed name space, but rather islands of signed name space each
originating from specific points (i.e. 'trust points') in the DNS
tree. Each of those islands will be identified by the trust point
name, and validated by at least one associated public key. For the
purpose of this document we'll call the association of that name and
a particular key a 'trust anchor'. A particular trust point can have
more than one key designated as a trust anchor.
For a DNSSEC-aware resolver to validate information in a DNSSEC
protected branch of the hierarchy, it must have knowledge of a trust
anchor applicable to that branch. It may also have more than one
trust anchor for any given trust point. Under current rules, a chain
of trust for DNSSEC-protected data that chains its way back to ANY
known trust anchor is considered 'secure'.
Because of the probable balkanization of the DNSSEC tree due to
signing voids at key locations, a resolver may need to know literally
thousands of trust anchors to perform its duties. (e.g. Consider an
unsigned ".COM".) Requiring the owner of the resolver to manually
manage this many relationships is problematic. It's even more
problematic when considering the eventual requirement for key
replacement/update for a given trust anchor. The mechanism described
herein won't help with the initial configuration of the trust anchors
in the resolvers, but should make trust point key replacement/
rollover more viable.
As mentioned above, this document describes a mechanism whereby a
resolver can update the trust anchors for a given trust point, mainly
without human intervention at the resolver. There are some corner
cases discussed (e.g. multiple key compromise) that may require
manual intervention, but they should be few and far between. This
document DOES NOT discuss the general problem of the initial
configuration of trust anchors for the resolver.
1.1 Compliance Nomenclature
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, [RFC2119].
1.2 Changes since -00
Added the concept of timer triggered resolver queries to refresh the
StJohns Expires February 16, 2006 [Page 3]
Internet-Draft trustanchor-update August 2005
resolvers view of the trust anchor key RRSet.
Re-submitted expired draft as -01. Updated DNSSEC RFC References.
2. Theory of Operation
The general concept of this mechanism is that existing trust anchors
can be used to authenticate new trust anchors at the same point in
the DNS hierarchy. When a new SEP key is added to a trust point
DNSKEY RRSet, and when that RRSet is validated by an existing trust
anchor, then the new key can be added to the set of trust anchors.
There are some issues with this approach which need to be mitigated.
For example, a compromise of one of the existing keys could allow an
attacker to add their own 'valid' data. This implies a need for a
method to revoke an existing key regardless of whether or not that
key is compromised. As another example assuming a single key
compromise, an attacker could add a new key and revoke all the other
old keys.
2.1 Revocation
Assume two trust anchor keys A and B. Assume that B has been
compromised. Without a specific revocation bit, B could invalidate A
simply by sending out a signed trust point key set which didn't
contain A. To fix this, we add a mechanism which requires knowledge
of the private key of a DNSKEY to revoke that DNSKEY.
A key is considered revoked when the resolver sees the key in a self-
signed RRSet and the key has the REVOKE bit set to '1'. Once the
resolver sees the REVOKE bit, it MUST NOT use this key as a trust
anchor or for any other purposes except validating the RRSIG over the
DNSKEY RRSet specifically for the purpose of validating the
revocation. Unlike the 'Add' operation below, revocation is
immediate and permanent upon receipt of a valid revocation at the
resolver.
N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
than one without the bit set. This affects the matching of a DNSKEY
to DS records in the parent, or the fingerprint stored at a resolver
used to configure a trust point. [msj3]
In the given example, the attacker could revoke B because it has
knowledge of B's private key, but could not revoke A.
2.2 Add Hold-Down
Assume two trust point keys A and B. Assume that B has been
StJohns Expires February 16, 2006 [Page 4]
Internet-Draft trustanchor-update August 2005
compromised. An attacker could generate and add a new trust anchor
key - C (by adding C to the DNSKEY RRSet and signing it with B), and
then invalidate the compromised key. This would result in the both
the attacker and owner being able to sign data in the zone and have
it accepted as valid by resolvers.
To mitigate, but not completely solve, this problem, we add a hold-
down time to the addition of the trust anchor. When the resolver
sees a new SEP key in a validated trust point DNSKEY RRSet, the
resolver starts an acceptance timer, and remembers all the keys that
validated the RRSet. If the resolver ever sees the DNSKEY RRSet
without the new key but validly signed, it stops the acceptance
process and resets the acceptance timer. If all of the keys which
were originally used to validate this key are revoked prior to the
timer expiring, the resolver stops the acceptance process and resets
the timer.
Once the timer expires, the new key will be added as a trust anchor
the next time the validated RRSet with the new key is seen at the
resolver. The resolver MUST NOT treat the new key as a trust anchor
until the hold down time expires AND it has retrieved and validated a
DNSKEY RRSet after the hold down time which contains the new key.
N.B.: Once the resolver has accepted a key as a trust anchor, the key
MUST be considered a valid trust anchor by that resolver until
explictly revoked as described above.
In the given example, the zone owner can recover from a compromise by
revoking B and adding a new key D and signing the DNSKEY RRSet with
both A and B.
The reason this does not completely solve the problem has to do with
the distributed nature of DNS. The resolver only knows what it sees.
A determined attacker who holds one compromised key could keep a
single resolver from realizing that key had been compromised by
intercepting 'real' data from the originating zone and substituting
their own (e.g. using the example, signed only by B). This is no
worse than the current situation assuming a compromised key.
2.3 Remove Hold-down
A new key which has been seen by the resolver, but hasn't reached
it's add hold-down time, MAY be removed from the DNSKEY RRSet by the
zone owner. If the resolver sees a validated DNSKEY RRSet without
this key, it waits for the remove hold-down time and then, if the key
hasn't reappeared, SHOULD discard any information about the key.
StJohns Expires February 16, 2006 [Page 5]
Internet-Draft trustanchor-update August 2005
2.4 Active Refresh
A resolver which has been configured for automatic update of keys
from a particular trust point MUST query that trust point (e.g. do a
lookup for the DNSKEY RRSet and related RRSIG records) no less often
than the lesser of 15 days or half the original TTL for the DNSKEY
RRSet or half the RRSIG expiration interval. The expiration interval
is the amount of time from when the RRSIG was last retrieved until
the expiration time in the RRSIG.
If the query fails, the resolver MUST repeat the query until
satisfied no more often than once an hour and no less often than the
lesser of 1 day or 10% of the original TTL or 10% of the original
expiration interval.
2.5 Resolver Parameters
2.5.1 Add Hold-Down Time
The add hold-down time is 30 days or the expiration time of the TTL
of the first trust point DNSKEY RRSet which contained the key,
whichever is greater. This ensures that at least two validated
DNSKEY RRSets which contain the new key MUST be seen by the resolver
prior to the key's acceptance.
2.5.2 Remove Hold-Down Time
The remove hold-down time is 30 days.
2.5.3 Minimum Trust Anchors per Trust Point
A compliant resolver MUST be able to manage at least five SEP keys
per trust point.
3. Changes to DNSKEY RDATA Wire Format
Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE'
flag. If this bit is set to '1', AND the resolver sees an
RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
consider this key permanently invalid for all purposes except for
validing the revocation.
4. State Table
The most important thing to understand is the resolver's view of any
key at a trust point. The following state table describes that view
at various points in the key's lifetime. The table is a normative
part of this specification. The initial state of the key is 'Start'.
StJohns Expires February 16, 2006 [Page 6]
Internet-Draft trustanchor-update August 2005
The resolver's view of the state of the key changes as various events
occur.
[msj1] This is the state of a trust point key as seen from the
resolver. The column on the left indicates the current state. The
header at the top shows the next state. The intersection of the two
shows the event that will cause the state to transition from the
current state to the next.
NEXT STATE
--------------------------------------------------
FROM |Start |AddPend |Valid |Missing|Revoked|Removed|
----------------------------------------------------------
Start | |NewKey | | | | |
----------------------------------------------------------
AddPend |KeyRem | |AddTime| | |
----------------------------------------------------------
Valid | | | |KeyRem |Revbit | |
----------------------------------------------------------
Missing | | |KeyPres| |Revbit | |
----------------------------------------------------------
Revoked | | | | | |RemTime|
----------------------------------------------------------
Removed | | | | | | |
----------------------------------------------------------
4.1 Events
NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
That key will become a new trust anchor for the named trust point
after its been present in the RRSet for at least 'add time'.
KeyPres The key has returned to the valid DNSKEY RRSet.
KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
this key.
AddTime The key has been in every valid DNSKEY RRSet seen for at
least the 'add time'.
RemTime A revoked key has been missing from the trust point DNSKEY
RRSet for sufficient time to be removed from the trust set.
RevBit The key has appeared in the trust anchor DNSKEY RRSet with its
"REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
signed by this key.
4.2 States
Start The key doesn't yet exist as a trust anchor at the resolver.
It may or may not exist at the zone server, but hasn't yet been
seen at the resolver.
StJohns Expires February 16, 2006 [Page 7]
Internet-Draft trustanchor-update August 2005
AddPend The key has been seen at the resolver, has its 'SEP' bit set,
and has been included in a validated DNSKEY RRSet. There is a
hold-down time for the key before it can be used as a trust
anchor.
Valid The key has been seen at the resolver and has been included in
all validated DNSKEY RRSets from the time it was first seen up
through the hold-down time. It is now valid for verifying RRSets
that arrive after the hold down time. Clarification: The DNSKEY
RRSet does not need to be continuously present at the resolver
(e.g. its TTL might expire). If the RRSet is seen, and is
validated (i.e. verifies against an existing trust anchor), this
key MUST be in the RRSet otherwise a 'KeyRem' event is triggered.
Missing This is an abnormal state. The key remains as a valid trust
point key, but was not seen at the resolver in the last validated
DNSKEY RRSet. This is an abnormal state because the zone operator
should be using the REVOKE bit prior to removal. [Discussion
item: Should a missing key be considered revoked after some
period of time?]
Revoked This is the state a key moves to once the resolver sees an
RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
this key with its REVOKE bit set to '1'. Once in this state, this
key MUST permanently be considered invalid as a trust anchor.
Removed After a fairly long hold-down time, information about this
key may be purged from the resolver. A key in the removed state
MUST NOT be considered a valid trust anchor.
5. Scenarios
The suggested model for operation is to have one active key and one
stand-by key at each trust point. The active key will be used to
sign the DNSKEY RRSet. The stand-by key will not normally sign this
RRSet, but the resolver will accept it as a trust anchor if/when it
sees the signature on the trust point DNSKEY RRSet.
Since the stand-by key is not in active signing use, the associated
private key may (and SHOULD) be provided with additional protections
not normally available to a key that must be used frequently. E.g.
locked in a safe, split among many parties, etc. Notionally, the
stand-by key should be less subject to compromise than an active key,
but that will be dependent on operational concerns not addressed
here.
5.1 Adding A Trust Anchor
Assume an existing trust anchor key 'A'.
1. Generate a new key pair.
StJohns Expires February 16, 2006 [Page 8]
Internet-Draft trustanchor-update August 2005
2. Create a DNSKEY record from the key pair and set the SEP and Zone
Key bits.
3. Add the DNSKEY to the RRSet.
4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
'A'.
5. Wait a while.
5.2 Deleting a Trust Anchor
Assume existing trust anchors 'A' and 'B' and that you want to revoke
and delete 'A'.
1. Set the revolcation bit on key 'A'.
2. Sign the DNSKEY RRSet with both 'A' and 'B'.
'A' is now revoked. The operator SHOULD include the revoked 'A' in
the RRSet for at least the remove hold-down time, but then may remove
it from the DNSKEY RRSet.
5.3 Key Roll-Over
Assume existing keys A and B. 'A' is actively in use (i.e. has been
signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been
in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
used to sign the RRSet.)
1. Generate a new key pair 'C'.
2. Add 'C' to the DNSKEY RRSet.
3. Set the revocation bit on key 'A'.
4. Sign the RRSet with 'A' and 'B'.
'A' is now revoked, 'B' is now the active key, and 'C' will be the
stand-by key once the hold-down expires. The operator SHOULD include
the revoked 'A' in the RRSet for at least the remove hold-down time,
but may then remove it from the DNSKEY RRSet.
5.4 Active Key Compromised
This is the same as the mechanism for Key Roll-Over (Section 5.3)
above assuming 'A' is the active key.
5.5 Stand-by Key Compromised
Using the same assumptions and naming conventions as Key Roll-Over
(Section 5.3) above:
1. Generate a new key pair 'C'.
2. Add 'C' to the DNSKEY RRSet.
3. Set the revocation bit on key 'B'.
4. Sign the RRSet with 'A' and 'B'.
'B' is now revoked, 'A' remains the active key, and 'C' will be the
stand-by key once the hold-down expires. 'B' SHOULD continue to be
included in the RRSet for the remove hold-down time.
StJohns Expires February 16, 2006 [Page 9]
Internet-Draft trustanchor-update August 2005
6. Security Considerations
6.1 Key Ownership vs Acceptance Policy
The reader should note that, while the zone owner is responsible
creating and distributing keys, it's wholly the decision of the
resolver owner as to whether to accept such keys for the
authentication of the zone information. This implies the decision
update trust anchor keys based on trust for a current trust anchor
key is also the resolver owner's decision.
The resolver owner (and resolver implementers) MAY choose to permit
or prevent key status updates based on this mechanism for specific
trust points. If they choose to prevent the automated updates, they
will need to establish a mechanism for manual or other out-of-band
updates outside the scope of this document.
6.2 Multiple Key Compromise
This scheme permits recovery as long as at least one valid trust
anchor key remains uncompromised. E.g. if there are three keys, you
can recover if two of them are compromised. The zone owner should
determine their own level of comfort with respect to the number of
active valid trust anchors in a zone and should be prepared to
implement recovery procedures once they detect a compromise. A
manual or other out-of-band update of all resolvers will be required
if all trust anchor keys at a trust point are compromised.
6.3 Dynamic Updates
Allowing a resolver to update its trust anchor set based in-band key
information is potentially less secure than a manual process.
However, given the nature of the DNS, the number of resolvers that
would require update if a trust anchor key were compromised, and the
lack of a standard management framework for DNS, this approach is no
worse than the existing situation.
7. Normative References
[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.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
StJohns Expires February 16, 2006 [Page 10]
Internet-Draft trustanchor-update August 2005
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
Editorial Comments
[msj1] msj: N.B. This table is preliminary and will be revised to
match implementation experience. For example, should there
be a state for "Add hold-down expired, but haven't seen the
new RRSet"?
[msj2] msj: To be assigned.
[msj3] msj: For discussion: What's the implementation guidance for
resolvers currently with respect to the non-assigned flag
bits? If they consider the flag bit when doing key matching
at the trust anchor, they won't be able to match.
Author's Address
Michael StJohns
Nominum, Inc.
2385 Bay Road
Redwood City, CA 94063
USA
Phone: +1-301-528-4729
Email: Mike.StJohns@nominum.com
URI: www.nominum.com
StJohns Expires February 16, 2006 [Page 11]
Internet-Draft trustanchor-update August 2005
Intellectual Property Statement
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.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
StJohns Expires February 16, 2006 [Page 12]
Internet-Draft trustanchor-update August 2005
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
StJohns Expires February 16, 2006 [Page 13]

580
contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-04.txt Normal file
View File

@ -0,0 +1,580 @@
INTERNET-DRAFT Donald E. Eastlake 3rd
UPDATES RFC 2845 Motorola Laboratories
Expires: December 2005 June 2005
HMAC SHA TSIG Algorithm Identifiers
---- --- ---- --------- -----------
<draft-ietf-dnsext-tsig-sha-04.txt>
Status of This Document
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.
This draft is intended to be become a Proposed Standard RFC.
Distribution of this document is unlimited. Comments should be sent
to the DNSEXT working group mailing list <namedroppers@ops.ietf.org>.
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 a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
Use of the TSIG DNS resource record requires specification of a
cryptographic message authentication code. Currently identifiers
have been specified only for the HMAC-MD5 and GSS TSIG algorithms.
This document standardizes identifiers and implementation
requirements for additional HMAC SHA TSIG algorithms and standardizes
how to specify and handle the truncation of HMAC values.
Copyright Notice
Copyright (C) The Internet Society 2005. All Rights Reserved.
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT HMAC-SHA TSIG Identifiers
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Copyright Notice...........................................1
Table of Contents..........................................2
1. Introduction............................................3
2. Algorithms and Identifiers..............................4
3. Specifying Truncation...................................5
3.1 Truncation Specification...............................5
4. TSIG Policy Provisions and Truncation Error.............7
5. IANA Considerations.....................................8
6. Security Considerations.................................8
6. Copyright and Disclaimer................................8
7. Normative References....................................9
8. Informative References..................................9
Author's Address..........................................10
Expiration and File Name..................................10
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT HMAC-SHA TSIG Identifiers
1. Introduction
[RFC 2845] specifies a TSIG Resource Record (RR) that can be used to
authenticate DNS queries and responses. This RR contains a domain
name syntax data item which names the authentication algorithm used.
[RFC 2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for
authentication codes using the HMAC [RFC 2104] algorithm with the MD5
[RFC 1321] hash algorithm. IANA has also registered "gss-tsig" as an
identifier for TSIG authentication where the cryptographic operations
are delegated to GSS [RFC 3645].
In Section 2, this document specifies additional names for TSIG
authentication algorithms based on US NIST SHA algorithms and HMAC
and specifies the implementation requirements for those algorithms.
In Section 3, this document specifies the meaning of inequality
between the normal output size of the specified hash function and the
length of MAC (message authentication code) data given in the TSIG
RR. In particular, it specifies that a shorter length field value
specifies truncation and a longer length field is an error.
In Section 4, policy restrictions and implications related to
truncation and a new error code to indicate truncation shorter than
permitted by policy are described and specified.
The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as
defined in [RFC 2119].
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT HMAC-SHA TSIG Identifiers
2. Algorithms and Identifiers
TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS
queries and responses. They are intended to be efficient symmetric
authentication codes based on a shared secret. (Asymmetric signatures
can be provided using the SIG RR [RFC 2931]. In particular, SIG(0)
can be used for transaction signatures.) Used with a strong hash
function, HMAC [RFC 2104] provides a way to calculate such symmetric
authentication codes. The only specified HMAC based TSIG algorithm
identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321].
The use of SHA-1 [FIPS 180-2, RFC 3174], which is a 160 bit hash, as
compared with the 128 bits for MD5, and additional hash algorithms in
the SHA family [FIPS 180-2, RFC 3874, SHA2draft] with 224, 256, 384,
and 512 bits, may be preferred in some cases particularly since
increasingly successful cryptanalytic attacks are being made on the
shorter hashes. Use of TSIG between a DNS resolver and server is by
mutual agreement. That agreement can include the support of
additional algorithms and may specify policies as to which algorithms
and truncations are acceptable subject to the restrication and
guidelines in Section 3 and 4 below.
The current HMAC-MD5.SIG-ALG.REG.INT identifier is included in the
table below for convenience. Implementations which support TSIG MUST
also implement HMAC SHA1 and HMAC SHA256 and MAY implement gss-tsig
and the other algorithms listed below.
Mandatory HMAC-MD5.SIG-ALG.REG.INT
Mandatory hmac-sha1
Optional hmac-sha224
Mandatory hmac-sha256
Optional hamc-sha384
Optional hmac-sha512
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT HMAC-SHA TSIG Identifiers
3. Specifying Truncation
When space is at a premium and the strength of the full length of an
HMAC is not needed, it is reasonable to truncate the HMAC output and
use the truncated value for authentication. HMAC SHA-1 truncated to
96 bits is an option available in several IETF protocols including
IPSEC and TLS.
The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the
size of the MAC field in octets. But [RFC 2845] does not specify what
to do if this MAC size differs from the length of the output of HMAC
for a particular hash function. Truncation is indicated by a MAC size
less than the HMAC size as specified below.
3.1 Truncation Specification
The specification for TSIG handling is changed as follows:
1. If "MAC size" field is greater than HMAC output length:
This case MUST NOT be generated and if received MUST cause the
packet to be dropped and RCODE 1 (FORMERR) to be returned.
2. If "MAC size" field equals HMAC output length:
Operation is as described in [RFC 2845] with the entire output
HMAC output present.
3. "MAC size" field is less than HMAC output length but greater than
that specified in case 4 below:
This is sent when the signer has truncated the HMAC output to
an allowable length, as described in RFC 2104, taking initial
octets and discarding trailing octets. TSIG truncation can only be
to an integral number of octets. On receipt of a packet with
truncation thus indicated, the locally calculated MAC is similarly
truncated and only the truncated values compared for
authentication. The request MAC used when calculating the TSIG MAC
for a reply is the trucated request MAC.
4. "MAC size" field is less than the larger of 10 (octets) and half
the length of the hash function in use:
With the exception of certain TSIG error messages described in
RFC 2845 section 3.2 where it is permitted that the MAC size be
zero, this case MUST NOT be generated and if received MUST cause
the packet to be dropped and RCODE 1 (FORMERR) to be returned. The
size limit for this case can also, for the hash functions
mentioned in this document, be stated as less than half the hash
function length for hash functions other than MD5 and less than 10
octets for MD5.
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT HMAC-SHA TSIG Identifiers
SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT HMAC-SHA TSIG Identifiers
4. TSIG Policy Provisions and Truncation Error
Use of TSIG is by mutual agreement between a resolver and server.
Implicit in such "agreement" are policies as to acceptable keys and
algorithms and, with the extensions in this doucment, truncations. In
particular note the following:
Such policies MAY require the rejection of TSIGs even though they
use an algorithm for which implementation is mandatory.
When a policy calls for the acceptance of a TSIG with a particular
algorithm and a particular non-zero amount of trunction it SHOULD
also permit the use of that algorithm with lesser truncation (a
longer MAC) up to the full HMAC output.
Regardless of a lower acceptable truncated MAC length specified by
policy, a reply SHOULD be sent with a MAC at least as long as that in
the corresponding request unless the request specified a MAC length
longer than the HMAC output.
Implementations permitting policies with multiple acceptable
algorithms and/or truncations SHOULD permit this list to be ordered
by presumed strength and SHOULD allow different truncations for the
same algorithm to be treatred as spearate entities in this list. When
so implemented, policies SHOULD accept a presumed stronger algorithm
and truncation than the minimum strength required by the policy.
If a TSIG is received with truncation which is permitted under
Section 3 above but the MAC is too short for the policy in force, an
RCODE of TBA [22 suggested](BADTRUNC) MUST be returned.
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT HMAC-SHA TSIG Identifiers
5. IANA Considerations
This document, on approval for publication as a standards track RFC,
(1) registers the new TSIG algorithm identifiers listed in Section 2
with IANA and (2) Section 4 allocates the BADTRUNC RCODE TBA [22
suggested].
6. Security Considerations
For all of the message authentication code algorithms listed herein,
those producing longer values are believed to be stronger; however,
while there have been some arguments that mild truncation can
strengthen a MAC by reducing the information available to an
attacker, excessive truncation clearly weakens authentication by
reducing the number of bits an attacker has to try to brute force
[RFC 2104].
Significant progress has been made recently in cryptanalysis of hash
function of the type used herein, all of which ultimately derive from
the design of MD4. While the results so far should not effect HMAC,
the stronger SHA-1 and SHA-256 algorithms are being made mandatory
due to caution.
See the Security Considerations section of [RFC 2845]. See also the
Security Considerations section of [RFC 2104] from which the limits
on truncation in this RFC were taken.
6. Copyright and Disclaimer
Copyright (C) The Internet Society (2005). 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 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.
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT HMAC-SHA TSIG Identifiers
7. Normative References
[FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US
Federal Information Processing Standard, with Change Notice 1,
February 2004.
[RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
1321, April 1992.
[RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February 1997.
[RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, May 2000.
8. Informative References.
[RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
Signatures ( SIG(0)s )", RFC 2931, September 2000.
[RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
1 (SHA1)", RFC 3174, September 2001.
[RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead,
J., and R. Hall, "Generic Security Service Algorithm for Secret Key
Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
2003.
[RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224",
September 2004,
[SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms
(SHA)", work in progress.
D. Eastlake 3rd [Page 9]
INTERNET-DRAFT HMAC-SHA TSIG Identifiers
Author's Address
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1-508-786-7554 (w)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires in December 2005.
Its file name is draft-ietf-dnsext-tsig-sha-04.txt
D. Eastlake 3rd [Page 10]

956
contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-08.txt Normal file
View File

@ -0,0 +1,956 @@
DNSEXT Working Group E. Lewis
INTERNET DRAFT NeuStar
Expiration Date: January 6, 2006 July 6, 2005
Updates RFC 1034, RFC 2672
The Role of Wildcards
in the Domain Name System
draft-ietf-dnsext-wcard-clarify-08.txt
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 January 6, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This is an update to the wildcard definition of RFC 1034. The
interaction with wildcards and CNAME is changed, an error
condition removed, and the words defining some concepts central
to wildcards are changed. The overall goal is not to change
wildcards, but to refine the definition of RFC 1034.
Table of Contents
1. Introduction
1.1 Motivation
1.2 The Original Definition
1.3 Roadmap to This Document
1.3.1 New Terms
1.3.2 Changed Text
1.3.3 Considerations with Special Types
1.4 Standards Terminology
2. Wildcard Syntax
2.1 Identifying a Wildcard
2.1.1 Wild Card Domain Name and Asterisk Label
2.1.2 Asterisks and Other Characters
2.1.3 Non-terminal Wild Card Domain Names
2.2 Existence Rules
2.2.1 An Example
2.2.2 Empty Non-terminals
2.2.3 Yet Another Definition of Existence
2.3 When is a Wild Card Domain Name Not Special
3. Impact of a Wild Card Domain Name On a Response
3.1 Step 2
3.2 Step 3
3.3 Part 'c'
3.3.1 Closest Encloser and the Source of Synthesis
3.3.2 Closest Encloser and Source of Synthesis Examples
3.3.3 Type Matching
4. Considerations with Special Types
4.1 SOA RRSet at a Wild Card Domain Name
4.2 NS RRSet at a Wild Card Domain Name
4.2.1 Discarded Notions
4.3 CNAME RRSet at a Wild Card Domain Name
4.4 DNAME RRSet at a Wild Card Domain Name
4.5 SRV RRSet at a Wild Card Domain Name
4.6 DS RRSet at a Wild Card Domain Name
4.7 NSEC RRSet at a Wild Card Domain Name
4.8 RRSIG at a Wild Card Domain Name
4.9 Empty Non-terminal Wild Card Domain Name
5. Security Considerations
6. IANA Considerations
7. References
8. Editor
9. Others Contributing to the Document
10. Trailing Boilerplate
1. Introduction
In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the
synthesis of answers from special resource records called
wildcards. The definition in RFC 1034 is incomplete and has
proven to be confusing. This document describes the wildcard
synthesis by adding to the discussion and making limited
modifications. Modifications are made to close inconsistencies
that have led to interoperability issues. This description
does not expand the service intended by the original definition.
Staying within the spirit and style of the original documents,
this document avoids specifying rules for DNS implementations
regarding wildcards. The intention is to only describe what is
needed for interoperability, not restrict implementation choices.
In addition, consideration is given to minimize any backwards
compatibility issues with implementations that comply with RFC
1034's definition.
This document is focused on the concept of wildcards as defined
in RFC 1034. Nothing is implied regarding alternative means of
synthesizing resource record sets, nor are alternatives discussed.
1.1 Motivation
Many DNS implementations diverge, in different ways, from the
original definition of wildcards. Although there is clearly a
need to clarify the original documents in light of this alone,
the impetus for this document lay in the engineering of the DNS
security extensions [RFC4033]. With an unclear definition of
wildcards the design of authenticated denial became entangled.
This document is intended to limit its changes, documenting only
those based on implementation experience, and to remain as close
to the original document as possible. To reinforce that this
document is meant to clarify and adjust and not redefine wildcards,
relevant sections of RFC 1034 are repeated verbatim to facilitate
comparison of the old and new text.
1.2 The Original Definition
The defintion of the wildcard concept is comprised by the
documentation of the algorithm by which a name server prepares
a response (in RFC 1034's section 4.3.2) and the way in which
a resource record (set) is identified as being a source of
synthetic data (section 4.3.3).
This is the definition of the term "wildcard" as it appears in
RFC 1034, section 4.3.3.
# In the previous algorithm, special treatment was given to RRs with
# owner names starting with the label "*". Such RRs are called
# wildcards. Wildcard RRs can be thought of as instructions for
# synthesizing RRs. When the appropriate conditions are met, the name
# server creates RRs with an owner name equal to the query name and
# contents taken from the wildcard RRs.
This passage follows the algorithm in which the term wildcard
is first used. In this definition, wildcard refers to resource
records. In other usage, wildcard has referred to domain names,
and it has been used to describe the operational practice of
relying on wildcards to generate answers. It is clear from this
that there is a need to define clear and unambiguous terminology
in the process of discussing wildcards.
The mention of the use of wildcards in the preparation of a
response is contained in step 3c of RFC 1034's section 4.3.2
entitled "Algorithm." Note that "wildcard" does not appear in
the algorithm, instead references are made to the "*" label.
The portion of the algorithm relating to wildcards is
deconstructed in detail in section 3 of this document, this is
the beginning of the relevant portion of the "Algorithm."
# c. If at some label, a match is impossible (i.e., the
# corresponding label does not exist), look to see if [...]
# the "*" label exists.
The scope of this document is the RFC 1034 definition of
wildcards and the implications of updates to those documents,
such as DNSSEC. Alternate schemes for synthesizing answers are
not considered. (Note that there is no reference listed. No
document is known to describe any alternate schemes, although
there has been some mention of them in mailing lists.)
1.3 Roadmap to This Document
This document accomplishes these three items.
o Defines new terms
o Makes minor changes to avoid conflicting concepts
o Describes the actions of certain resource records as wildcards
1.3.1 New Terms
To help in discussing what resource records are wildcards, two
terms will be defined - "asterisk label" and "wild card domain
name". These are defined in section 2.1.1.
To assist in clarifying the role of wildcards in the name server
algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest
encloser" are defined. These definitions are in section 3.3.2.
"Label match" is defined in section 3.2.
The new terms are used to make discussions of wildcards clearer.
Terminology doesn't directly have an impact on implementations.
1.3.2 Changed Text
The definition of "existence" is changed superficially. This
change will not be apparent to implementations; it is needed to
make descriptions more precise. The change appears in section
2.2.3.
RFC 1034, section 4.3.3., seems to prohibit having two asterisk
labels in a wildcard owner name. With this document the
restriction is removed entirely. This change and its implications
are in section 2.1.3.
The actions when a source of synthesis owns a CNAME RR are
changed to mirror the actions if an exact match name owns a
CNAME RR. This is an addition to the words in RFC 1034,
section 4.3.2, step 3, part c. The discussion of this is in
section 3.3.3.
Only the latter change represents an impact to implementations.
The definition of existence is not a protocol impact. The change
to the restriction on names is unlikely to have an impact, as
RFC 1034 contained no specification on when and how to enforce the
restriction.
1.3.3 Considerations with Special Types
This document describes semantics of wildcard RRSets for
"interesting" types as well as empty non-terminal wildcards.
Understanding these situations in the context of wildcards has
been clouded because these types incur special processing if
they are the result of an exact match. This discussion is in
section 4.
These discussions do not have an implementation impact, they cover
existing knowledge of the types, but to a greater level of detail.
1.4 Standards Terminology
This document does not use terms as defined in "Key words for use
in RFCs to Indicate Requirement Levels." [RFC2119]
Quotations of RFC 1034 are denoted by a '#' in the leftmost
column. References to section "4.3.2" are assumed to refer
to RFC 1034's section 4.3.2, simply titled "Algorithm."
2. Wildcard Syntax
The syntax of a wildcard is the same as any other DNS resource
record, across all classes and types. The only significant
feature is the owner name.
Because wildcards are encoded as resource records with special
names, they are included in zone transfers and incremental zone
transfers[RFC1995] just as non-wildcard resource records are.
This feature has been underappreciated until discussions on
alternative approaches to wildcards appeared on mailing lists.
2.1 Identifying a Wildcard
To provide a more accurate description of wildcards, the
definition has to start with a discussion of the domain names
that appear as owners. Two new terms are needed, "Asterisk
Label" and "Wild Card Domain Name."
2.1.1 Wild Card Domain Name and Asterisk Label
A "wild card domain name" is defined by having its initial
(i.e., left-most or least significant) label be, in binary format:
0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
The first octet is the normal label type and length for a 1 octet
long label, the second octet is the ASCII representation [RFC20]
for the '*' character.
A descriptive name of a label equaling that value is an "asterisk
label."
RFC 1034's definition of wildcard would be "a resource record
owned by a wild card domain name."
2.1.2 Asterisks and Other Characters
No label values other than that in section 2.1.1 are asterisk
labels, hence names beginning with other labels are never wild
card domain names. Labels such as 'the*' and '**' are not
asterisk labels so these labels do not start wild card domain
names.
2.1.3 Non-terminal Wild Card Domain Names
In section 4.3.3, the following is stated:
# .......................... The owner name of the wildcard RRs is of
# the form "*.<anydomain>", where <anydomain> is any domain name.
# <anydomain> should not contain other * labels......................
The restriction is now removed. The original documentation of it
is incomplete and the restriction does not serve any purpose given
years of operational experience.
There are three possible reasons for putting the restriction in
place, but none of the three has held up over time. One is
that the restriction meant that there would never be subdomains
of wild card domain names, but the restriciton as stated still
permits "example.*.example." for instance. Another is that
wild card domain names are not intended to be empty non-terminals,
but this situation does not disrupt the algorithm in 4.3.2.
Finally, "nested" wild card domain names are not ambiguous once
the concept of the closest encloser had been documented.
A wild card domain name can have subdomains. There is no need
to inspect the subdomains to see if there is another asterisk
label in any subdomain.
A wild card domain name can be an empty non-terminal. (See the
upcoming sections on empty non-terminals.) In this case, any
lookup encountering it will terminate as would any empty
non-terminal match.
2.2 Existence Rules
The notion that a domain name 'exists' is mentioned in the
definition of wildcards. In section 4.3.3 of RFC 1034:
# Wildcard RRs do not apply:
#
...
# - When the query name or a name between the wildcard domain and
# the query name is know[n] to exist. For example, if a wildcard
"Existence" is therefore an important concept in the understanding
of wildcards. Unfortunately, the definition of what exists, in RFC
1034, is unlcear. So, in sections 2.2.2. and 2.2.3, another look is
taken at the definition of existence.
2.2.1 An Example
To illustrate what is meant by existence consider this complete
zone:
$ORIGIN example.
example. 3600 IN SOA <SOA RDATA>
example. 3600 NS ns.example.com.
example. 3600 NS ns.example.net.
*.example. 3600 TXT "this is a wild card"
*.example. 3600 MX 10 host1.example.
sub.*.example. 3600 TXT "this is not a wild card"
host1.example. 3600 A 192.0.4.1
_ssh._tcp.host1.example. 3600 SRV <SRV RDATA>
_ssh._tcp.host2.example. 3600 SRV <SRV RDATA>
subdel.example. 3600 NS ns.example.com.
subdel.example. 3600 NS ns.example.net.
A look at the domain names in a tree structure is helpful:
|
-------------example------------
/ / \ \
/ / \ \
/ / \ \
* host1 host2 subdel
| | |
| | |
sub _tcp _tcp
| |
| |
_ssh _ssh
The following responses would be synthesized from one of the
wildcards in the zone:
QNAME=host3.example. QTYPE=MX, QCLASS=IN
the answer will be a "host3.example. IN MX ..."
QNAME=host3.example. QTYPE=A, QCLASS=IN
the answer will reflect "no error, but no data"
because there is no A RR set at '*.example.'
QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
the answer will be "foo.bar.example. IN TXT ..."
because bar.example. does not exist, but the wildcard
does.
The following responses would not be synthesized from any of the
wildcards in the zone:
QNAME=host1.example., QTYPE=MX, QCLASS=IN
because host1.example. exists
QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
because sub.*.example. exists
QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
because _tcp.host1.example. exists (without data)
QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
because subdel.example. exists (and is a zone cut)
QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
because *.example. exists
The final example highlights one common misconception about
wildcards. A wildcard "blocks itself" in the sense that a
wildcard does not match its own subdomains. I.e. "*.example."
does not match all names in the "example." zone, it fails to
match the names below "*.example." To cover names under
"*.example.", another wild card domain name is needed -
"*.*.example." - which covers all but it's own subdomains.
2.2.2 Empty Non-terminals
Empty non-terminals [RFC2136, Section 7.16] are domain names
that own no resource records but have subdomains that do. In
section 2.2.1, "_tcp.host1.example." is an example of a empty
non-terminal name. Empty non-terminals are introduced by this
text in section 3.1 of RFC 1034:
# The domain name space is a tree structure. Each node and leaf on
# the tree corresponds to a resource set (which may be empty). The
# domain system makes no distinctions between the uses of the
# interior nodes and leaves, and this memo uses the term "node" to
# refer to both.
The parenthesized "which may be empty" specifies that empty non-
terminals are explicitly recognized, and that empty non-terminals
"exist."
Pedantically reading the above paragraph can lead to an
interpretation that all possible domains exist - up to the
suggested limit of 255 octets for a domain name [RFC1035].
For example, www.example. may have an A RR, and as far as is
practically concerned, is a leaf of the domain tree. But the
definition can be taken to mean that sub.www.example. also
exists, albeit with no data. By extension, all possible domains
exist, from the root on down.
As RFC 1034 also defines "an authoritative name error indicating
that the name does not exist" in section 4.3.1, so this apparently
is not the intent of the original definition, justifying the
need for an updated definition in the next section.
2.2.3 Yet Another Definition of Existence
RFC1034's wording is fixed by the following paragraph:
The domain name space is a tree structure. Nodes in the tree
either own at least one RRSet and/or have descendants that
collectively own at least one RRSet. A node may exist with no
RRSets only if it has descendents that do, this node is an empty
non-terminal.
A node with no descendants is a leaf node. Empty leaf nodes do
not exist.
Note that at a zone boundary, the domain name owns data,
including the NS RR set. In the delegating zone, the NS RR
set is not authoritative, but that is of no consequence here.
The domain name owns data, therefore, it exists.
2.3 When is a Wild Card Domain Name Not Special
When a wild card domain name appears in a message's query section,
no special processing occurs. An asterisk label in a query name
only matches a single, corresponding asterisk label in the
existing zone tree when the 4.3.2 algorithm is being followed.
When a wild card domain name appears in the resource data of a
record, no special processing occurs. An asterisk label in that
context literally means just an asterisk.
3. Impact of a Wild Card Domain Name On a Response
RFC 1034's description of how wildcards impact response
generation is in its section 4.3.2. That passage contains the
algorithm followed by a server in constructing a response.
Within that algorithm, step 3, part 'c' defines the behavior of
the wildcard.
The algorithm in section 4.3.2. is not intended to be pseudo-code,
i.e., its steps are not intended to be followed in strict order.
The "algorithm" is a suggested means of implementing the
requirements. As such, in step 3, parts a, b, and c, do not have
to be implemented in that order, provided that the result of the
implemented code is compliant with the protocol's specification.
3.1 Step 2
Step 2 of the section 4.3.2 reads:
# 2. Search the available zones for the zone which is the nearest
# ancestor to QNAME. If such a zone is found, go to step 3,
# otherwise step 4.
In this step, the most appropriate zone for the response is
chosen. The significance of this step is that it means all of
step 3 is being performed within one zone. This has significance
when considering whether or not an SOA RR can be ever be used for
synthesis.
3.2 Step 3
Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'.
But the beginning of the step is important and needs explanation.
# 3. Start matching down, label by label, in the zone. The
# matching process can terminate several ways:
The word 'matching' refers to label matching. The concept
is based in the view of the zone as the tree of existing names.
The query name is considered to be an ordered sequence of
labels - as if the name were a path from the root to the owner
of the desired data. (Which it is - 3rd paragraph of RFC 1034,
section 3.1.)
The process of label matching a query name ends in exactly one of
three choices, the parts 'a', 'b', and 'c'. Either the name is
found, the name is below a cut point, or the name is not found.
Once one of the parts is chosen, the other parts are not
considered. (E.g., do not execute part 'c' and then change
the execution path to finish in part 'b'.) The process of label
matching is also done independent of the query type (QTYPE).
Parts 'a' and 'b' are not an issue for this clarification as they
do not relate to record synthesis. Part 'a' is an exact match
that results in an answer, part 'b' is a referral.
3.3 Part 'c'
The context of part 'c' is that the process of label matching the
labels of the query name has resulted in a situation in which
there is no corresponding label in the tree. It is as if the
lookup has "fallen off the tree."
# c. If at some label, a match is impossible (i.e., the
# corresponding label does not exist), look to see if [...]
# the "*" label exists.
To help describe the process of looking 'to see if [...] the "*"
label exists' a term has been coined to describe the last domain
(node) matched. The term is "closest encloser."
3.3.1 Closest Encloser and the Source of Synthesis
The closest encloser is the node in the zone's tree of existing
domain names that has the most labels matching the query name
(consecutively, counting from the root label downward). Each match
is a "label match" and the order of the labels is the same.
The closest encloser is, by definition, an existing name in the
zone. The closest encloser might be an empty non-terminal or even
be a wild card domain name itself. In no circumstances is the
closest encloser to be used to synthesize records for the current
query.
The source of synthesis is defined in the context of a query
process as that wild card domain name immediately descending
from the closest encloser, provided that this wild card domain
name exists. "Immediately descending" means that the source
of synthesis has a name of the form:
<asterisk label>.<closest encloser>.
A source of synthesis does not guarantee having a RRSet to use
for synthesis. The source of synthesis could be an empty
non-terminal.
If the source of synthesis does not exist (not on the domain
tree), there will be no wildcard synthesis. There is no search
for an alternate.
The important concept is that for any given lookup process, there
is at most one place at which wildcard synthetic records can be
obtained. If the source of synthesis does not exist, the lookup
terminates, the lookup does not look for other wildcard records.
3.3.2 Closest Encloser and Source of Synthesis Examples
To illustrate, using the example zone in section 2.2.1 of this
document, the following chart shows QNAMEs and the closest
enclosers.
QNAME Closest Encloser Source of Synthesis
host3.example. example. *.example.
_telnet._tcp.host1.example. _tcp.host1.example. no source
_telnet._tcp.host2.example. host2.example. no source
_telnet._tcp.host3.example. example. *.example.
_chat._udp.host3.example. example. *.example.
foobar.*.example. *.example. no source
3.3.3 Type Matching
RFC 1034 concludes part 'c' with this:
# If the "*" label does not exist, check whether the name
# we are looking for is the original QNAME in the query
# or a name we have followed due to a CNAME. If the name
# is original, set an authoritative name error in the
# response and exit. Otherwise just exit.
#
# If the "*" label does exist, match RRs at that node
# against QTYPE. If any match, copy them into the answer
# section, but set the owner of the RR to be QNAME, and
# not the node with the "*" label. Go to step 6.
The final paragraph covers the role of the QTYPE in the lookup
process.
Based on implementation feedback and similarities between step
'a' and step 'c' a change to this passage has been made.
The change is to add the following text to step 'c' prior to the
instructions to "go to step 6":
If the data at the source of synthesis is a CNAME, and
QTYPE doesn't match CNAME, copy the CNAME RR into the
answer section of the response changing the owner name
to the QNAME, change QNAME to the canonical name in the
CNAME RR, and go back to step 1.
This is essentially the same text in step a covering the
processing of CNAME RRSets.
4. Considerations with Special Types
Sections 2 and 3 of this document discuss wildcard synthesis
with respect to names in the domain tree and ignore the impact
of types. In this section, the implication of wildcards of
specific types are discussed. The types covered are those
that have proven to be the most difficult to understand. The
types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and
"none," i.e., empty non-terminal wild card domain names.
4.1 SOA RRSet at a Wild Card Domain Name
A wild card domain name owning an SOA RRSet means that the
domain is at the root of the zone (apex). The domain can not
be a source of synthesis because that is, by definition, a
descendent node (of the closest encloser) and a zone apex is
at the top of the zone.
Although a wild card domain name owning an SOA RRSet can never
be a source of synthesis, there is no reason to forbid the
ownership of an SOA RRSet.
E.g., given this zone:
$ORIGIN *.example.
@ 3600 IN SOA <SOA RDATA>
3600 NS ns1.example.com.
3600 NS ns1.example.net.
www 3600 TXT "the www txt record"
A query for www.*.example.'s TXT record would still find the
"the www txt record" answer. The reason is that the asterisk
label only becomes significant when section's 4.3.2, step 3
part 'c' in in effect.
Of course, there would need to be a delegation in the parent
zone, "example." for this to work too. This is covered in the
next section.
4.2 NS RRSet at a Wild Card Domain Name
With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now
in place, the semantics of a wild card domain name owning an
NS RRSet has come to be poorly defined. The dilemma relates to
a conflict between the rules for synthesis in part 'c' and the
fact that the resulting synthesis generates a record for which
the zone is not authoritative. In a DNSSEC signed zone, the
mechanics of signature management (generation and inclusion
in a message) become unclear.
After some lengthy discussions, there has been no clear "best
answer" on how to document the semantics of such a situation.
Barring such records from the DNS would require definition of
rules for that, as well as introducing a restriction on records
that were once legal. Allowing such records and amending the
process of signature management would entail complicating the
DNSSEC definition.
There is one more ingredient to the discussion, that being the
utility of a wild card domain name owned NS RRSet. Although
there are cases of this use, it is an operational rarity.
Expending effort to close this topic has proven to be an
exercise in diminishing returns.
In summary, there is no definition given for wild card domain
names owning an NS RRSet. The semantics are left undefined until
there is a clear need to have a set defined, and until there is
a clear direction to proceed. Operationally, inclusion of wild
card NS RRSets in a zone is discouraged, but not barred.
4.2.1 Discarded Notions
Prior to DNSSEC, a wild card domain name owning a NS RRSet
appeared to be workable, and there are some instances in which
it is found in deployments using implementations that support
this. Continuing to allow this in the specificaion is not
tenable with DNSSEC. The reason is that the synthesis of the
NS RRSet is being done in a zone that has delegated away the
responsibility for the name. This "unauthorized" synthesis is
not a problem for the base DNS protocol, but DNSSEC, in affirming
the authorization model for DNS exposes the problem.
Outright banning of wildcards of type NS is also untenable as
the DNS protocol does not define how to handle "illegal" data.
Implementations may choose not to load a zone, but there is no
protocol definition. The lack of the definition is complicated
by having to cover dynamic update [RFC 2136], zone transfers,
as well as loading at the master server. The case of a client
(resolver, cacheing server) getting a wildcard of type NS in
a reply would also have to be considered.
Given the daunting challenge of a complete definition of how to
ban such records, dealing with existing implementations that
permit the records today is a further complication. There are
uses of wild card domain name owning NS RRSets.
One compromise proposed would have redefined wildcards of type
NS to not be used in synthesis, this compromise fell apart
because it would have required significant edits to the DNSSEC
signing and validation work. (Again, DNSSEC catches
unauthorized data.)
With no clear consensus forming on the solution to this dilemma,
and the realization that wildcards of type NS are a rarity in
operations, the best course of action is to leave this open-ended
until "it matters."
4.3 CNAME RRSet at a Wild Card Domain Name
The issue of a CNAME RRSet owned by a wild card domain name has
prompted a suggested change to the last paragraph of step 3c of
the algorithm in 4.3.2. The changed text appears in section
3.3.3 of this document.
4.4 DNAME RRSet at a Wild Card Domain Name
Ownership of a DNAME [RFC2672] RRSet by a wild card domain name
represents a threat to the coherency of the DNS and is to be
avoided or outright rejected. Such a DNAME RRSet represents
non-deterministic synthesis of rules fed to different caches.
As caches are fed the different rules (in an unpredictable
manner) the caches will cease to be coherent. ("As caches
are fed" refers to the storage in a cache of records obtained
in responses by recursive or iterative servers.)
For example, assume one cache, responding to a recursive
request, obtains the record:
"a.b.example. DNAME foo.bar.example.net."
and another cache obtains:
"b.example. DNAME foo.bar.example.net."
both generated from the record:
"*.example. DNAME foo.bar.example.net."
by an authoritative server.
The DNAME specification is not clear on whether DNAME records
in a cache are used to rewrite queries. In some interpretations,
the rewrite occurs, in some, it is not. Allowing for the
occurrence of rewriting, queries for "sub.a.b.example. A" may
be rewritten as "sub.foo.bar.tld. A" by the former caching
server and may be rewritten as "sub.a.foo.bar.tld. A" by the
latter. Coherency is lost, an operational nightmare ensues.
Another justification for banning or avoiding wildcard DNAME
records is the observation that such a record could synthesize
a DNAME owned by "sub.foo.bar.example." and "foo.bar.example."
There is a restriction in the DNAME definition that no domain
exist below a DNAME-owning domain, hence, the wildcard DNAME
is not to be permitted.
4.5 SRV RRSet at a Wild Card Domain Name
The definition of the SRV RRset is RFC 2782 [RFC2782]. In the
definition of the record, there is some confusion over the term
"Name." The definition reads as follows:
# The format of the SRV RR
...
# _Service._Proto.Name TTL Class SRV Priority Weight Port Target
...
# Name
# The domain this RR refers to. The SRV RR is unique in that the
# name one searches for is not this name; the example near the end
# shows this clearly.
Do not confuse the definition "Name" with the owner name. I.e.,
once removing the _Service and _Proto labels from the owner name
of the SRV RRSet, what remains could be a wild card domain name
but this is immaterial to the SRV RRSet.
E.g., If an SRV record is:
_foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.
*.example is a wild card domain name and although it it the Name
of the SRV RR, it is not the owner (domain name). The owner
domain name is "_foo._udp.*.example." which is not a wild card
domain name.
The confusion is likely based on the mixture of the specification
of the SRV RR and the description of a "use case."
4.6 DS RRSet at a Wild Card Domain Name
A DS RRSet owned by a wild card domain name is meaningless and
harmless. This statement is made in the context that an NS RRSet
at a wild card domain name is undefined. At a non-delegation
point, a DS RRSet has no value (no corresponding DNSKEY RRSet
will be used in DNSSEC validation). If there is a synthesized
DS RRSet, it alone will not be very useful as it exists in the
context of a delegation point.
4.7 NSEC RRSet at a Wild Card Domain Name
Wild card domain names in DNSSEC signed zones will have an NSEC
RRSet. Synthesis of these records will only occur when the
query exactly matches the record. Synthesized NSEC RR's will not
be harmful as they will never be used in negative caching or to
generate a negative response.
4.8 RRSIG at a Wild Card Domain Name
RRSIG records will be present at a wild card domain name in a
signed zone, and will be synthesized along with data sought in a
query. The fact that the owner name is synthesized is not a
problem as the label count in the RRSIG will instruct the
verifying code to ignore it.
4.9 Empty Non-terminal Wild Card Domain Name
If a source of synthesis is an empty non-terminal, then the
response will be one of no error in the return code and no RRSet
in the answer section.
5. Security Considerations
This document is refining the specifications to make it more
likely that security can be added to DNS. No functional
additions are being made, just refining what is considered
proper to allow the DNS, security of the DNS, and extending
the DNS to be more predictable.
6. IANA Considerations
None.
7. References
Normative References
[RFC20] ASCII Format for Network Interchange, V.G. Cerf,
Oct-16-1969
[RFC1034] Domain Names - Concepts and Facilities,
P.V. Mockapetris, Nov-01-1987
[RFC1035] Domain Names - Implementation and Specification, P.V
Mockapetris, Nov-01-1987
[RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996
[RFC2119] Key Words for Use in RFCs to Indicate Requirement
Levels, S Bradner, March 1997
[RFC2181] Clarifications to the DNS Specification, R. Elz and
R. Bush, July 1997
[RFC2308] Negative Caching of DNS Queries (DNS NCACHE),
M. Andrews, March 1998
[RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
August 1999.
[RFC2782] A DNS RR for specifying the location of services (DNS
SRV), A. Gulbrandsen, et.al., February 2000
[RFC4033] DNS Security Introduction and Requirements, R. Arends,
et.al., March 2005
[RFC4034] Resource Records for the DNS Security Extensions,
R. Arends, et.al., March 2005
[RFC4035] Protocol Modifications for the DNS Security Extensions,
R. Arends, et.al., March 2005
[RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
August 1999
Informative References
[RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE),
P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
April 1997
8. Editor
Name: Edward Lewis
Affiliation: NeuStar
Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US
Phone: +1-571-434-5468
Email: ed.lewis@neustar.biz
Comments on this document can be sent to the editor or the mailing
list for the DNSEXT WG, namedroppers@ops.ietf.org.
9. Others Contributing to the Document
This document represents the work of a large working group. The
editor merely recorded the collective wisdom of the working group.
10. Trailing Boilerplate
Copyright (C) The Internet Society (2005).
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 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Expiration
This document expires on or about January 6, 2006.

1176
contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-04.txt Normal file
View File

File diff suppressed because it is too large Load Diff

1736
contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-04.txt Normal file
View File

File diff suppressed because it is too large Load Diff

396
contrib/bind9/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt Normal file
View File

@ -0,0 +1,396 @@
INTERNET-DRAFT D. Senie
Category: BCP Amaranth Networks Inc.
Expires in six months July 2005
Encouraging the use of DNS IN-ADDR Mapping
draft-ietf-dnsop-inaddr-required-07.txt
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
Abstract
Mapping of addresses to names has been a feature of DNS. Many sites,
implement it, many others don't. Some applications attempt to use it
as a part of a security strategy. The goal of this document is to
encourage proper deployment of address to name mappings, and provide
guidance for their use.
Copyright Notice
Copyright (C) The Internet Society. (2005)
1. Introduction
The Domain Name Service has provision for providing mapping of IP
addresses to host names. It is common practice to ensure both name to
address, and address to name mappings are provided for networks. This
practice, while documented, has never been required, though it is
generally encouraged. This document both encourages the presence of
Senie [Page 1]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
these mappings and discourages reliance on such mappings for security
checks.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Discussion
From the early days of the Domain Name Service [RFC883] a special
domain has been set aside for resolving mappings of IP addresses to
domain names. This was refined in [RFC1035], describing the .IN-
ADDR.ARPA in use today. For the in the IPv6 address space, .IP6.ARPA
was added [RFC3152]. This document uses IPv4 CIDR block sizes and
allocation strategy where there are differences and uses IPv4
terminology. Aside from these differences, this document can and
should be applied to both address spaces.
The assignment of blocks of IP address space was delegated to three
regional registries. Guidelines for the registries are specified in
[RFC2050], which requires regional registries to maintain IN-ADDR
records on the large blocks of space issued to ISPs and others.
ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger
allocations. For smaller allocations, ARIN can provide IN-ADDR for
/24 and shorter prefixes. [ARIN]. APNIC provides methods for ISPs to
update IN-ADDR, however the present version of its policy document
for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft
copies of this document. As of this writing, it appears APNIC has no
actual policy on IN-ADDR. RIPE appears to have the strongest policy
in this area [RIPE302] indicating Local Internet Registries should
provide IN-ADDR services, and delegate those as appropriate when
address blocks are delegated.
As we can see, the regional registries have their own policies for
recommendations and/or requirements for IN-ADDR maintenance. It
should be noted, however, that many address blocks were allocated
before the creation of the regional registries, and thus it is
unclear whether any of the policies of the registries are binding on
those who hold blocks from that era.
Registries allocate address blocks on CIDR [RFC1519] boundaries.
Unfortunately the IN-ADDR zones are based on classful allocations.
Guidelines [RFC2317] for delegating on non-octet-aligned boundaries
exist, but are not always implemented.
3. Examples of impact of missing IN-ADDR
Senie [Page 2]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
These are some examples of problems that may be introduced by
reliance on IN-ADDR.
Some applications use DNS lookups for security checks. To ensure
validity of claimed names, some applications will look up IN-ADDR
records to get names, and then look up the resultant name to see if
it maps back to the address originally known. Failure to resolve
matching names is seen as a potential security concern.
Some FTP sites will flat-out reject users, even for anonymous FTP, if
the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when
itself resolved, does not match. Some Telnet servers also implement
this check.
Web sites are in some cases using IN-ADDR checks to verify whether
the client is located within a certain geopolitical entity. This
approach has been employed for downloads of crypto software, for
example, where export of that software is prohibited to some locales.
Credit card anti-fraud systems also use these methods for geographic
placement purposes.
The popular TCP Wrappers program found on most Unix and Linux systems
has options to enforce IN-ADDR checks and to reject any client that
does not resolve. This program also has a way to check to see that
the name given by a PTR record then resolves back to the same IP
address. This method provdes more comfort but no appreciable
additional security.
Some anti-spam (anti junk email) systems use IN-ADDR to verify the
presence of a PTR record, or validate the PTR value points back to
the same address.
Many web servers look up the IN-ADDR of visitors to be used in log
analysis. This adds to the server load, but in the case of IN-ADDR
unavailability, it can lead to delayed responses for users.
Traceroutes with descriptive IN-ADDR naming proves useful when
debugging problems spanning large areas. When this information is
missing, the traceroutes take longer, and it takes additional steps
to determine that network is the cause of problems.
Wider-scale implementation of IN-ADDR on dialup, wireless access and
other such client-oriented portions of the Internet would result in
lower latency for queries (due to lack of negative caching), and
lower name server load and DNS traffic.
4. Recommendations
Senie [Page 3]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
4.1 Delegation Recommendations
Regional Registries and any Local Registries to whom they delegate
should establish and convey a policy to those to whom they delegate
blocks that IN-ADDR mappings are recommended. Policies should
recommend those receiving delegations to provide IN-ADDR service
and/or delegate to downstream customers.
Network operators should define and implement policies and procedures
which delegate IN-ADDR to their clients who wish to run their own IN-
ADDR DNS services, and provide IN-ADDR services for those who do not
have the resources to do it themselves. Delegation mechanisms should
permit the downstream customer to implement and comply with IETF
recommendations application of IN-ADDR to CIDR [RFC2317].
All IP address space assigned and in use should be resolved by IN-
ADDR records. All PTR records must use canonical names.
All IP addresses in use within a block should have an IN-ADDR
mapping. Those addresses not in use, and those that are not valid for
use (zeros or ones broadcast addresses within a CIDR block) need not
have mappings.
It should be noted that due to CIDR, many addresses that appear to be
otherwise valid host addresses may actually be zeroes or ones
broadcast addresses. As such, attempting to audit a site's degree of
compliance may only be done with knowledge of the internal subnet
architecture of the site. It can be assumed, however, any host that
originates an IP packet necessarily will have a valid host address,
and must therefore have an IN-ADDR mapping.
4.2 Application Recommendations
Applications SHOULD NOT rely on IN-ADDR for proper operation. The use
of IN-ADDR, sometimes in conjunction with a lookup of the name
resulting from the PTR record provides no real security, can lead to
erroneous results and generally just increases load on DNS servers.
Further, in cases where address block holders fail to properly
configure IN-ADDR, users of those blocks are penalized.
5. Security Considerations
This document has no negative impact on security. While it could be
argued that lack of PTR record capabilities provides a degree of
anonymity, this is really not valid. Trace routes, whois lookups and
other sources will still provide methods for discovering identity.
Senie [Page 4]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
By recommending applications avoid using IN-ADDR as a security
mechanism this document points out that this practice, despite its
use by many applications, is an ineffective form of security.
Applications should use better mechanisms of authentication.
6. IANA Considerations
There are no IANA considerations for this document.
7. References
7.1 Normative References
[RFC883] P.V. Mockapetris, "Domain names: Implementation
specification," RFC883, November 1983.
[RFC1035] P.V. Mockapetris, "Domain Names: Implementation
Specification," RFC 1035, November 1987.
[RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR):
an Address Assignment and Aggregation Strategy," RFC 1519, September
1993.
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
RFC 2026, BCP 9, October 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
Guidelines", RFC2050, BCP 12, Novebmer 1996.
[RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation,"
RFC 2317, March 1998.
[RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August
2001.
7.2 Informative References
[ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
unknown, http://www.arin.net/regserv/initial-isp.html
[APNIC] "Policies For IPv4 Address Space Management in the Asia
Pacific Region," APNIC-086, 13 January 2003.
[RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6
Address Space in the RIPE NCC Service Region", RIPE-302, April 26,
Senie [Page 5]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
2004. http://www.ripe.net//ripe/docs/rev-del.html
8. Acknowledgements
Thanks to Peter Koch and Gary Miller for their input, and to many
people who encouraged me to write this document.
9. Author's Address
Daniel Senie
Amaranth Networks Inc.
324 Still River Road
Bolton, MA 01740
Phone: (978) 779-5100
EMail: dts@senie.com
10. Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 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.
Senie [Page 6]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
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.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Senie [Page 7]

1848
contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt Normal file
View File

File diff suppressed because it is too large Load Diff

1682
contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt Normal file
View File

File diff suppressed because it is too large Load Diff

389
contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt Normal file
View File

@ -0,0 +1,389 @@
DNSOP G. Guette
Internet-Draft IRISA / INRIA
Expires: July 19, 2005 O. Courtay
Thomson R&D
January 18, 2005
Requirements for Automated Key Rollover in DNSSEC
draft-ietf-dnsop-key-rollover-requirements-02.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 July 19, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document describes problems that appear during an automated
rollover and gives the requirements for the design of communication
between parent zone and child zone during an automated rollover
process. This document is essentially about in-band key rollover.
Guette & Courtay Expires July 19, 2005 [Page 1]
Internet-Draft Automated Rollover Requirements January 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3
3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4
4. Messages authentication and information exchanged . . . . . . 5
5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5
6. Security consideration . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
A. Documents details and changes . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 8
Guette & Courtay Expires July 19, 2005 [Page 2]
Internet-Draft Automated Rollover Requirements January 2005
1. Introduction
The DNS security extensions (DNSSEC) [4][6][5][7] uses public-key
cryptography and digital signatures. It stores the public part of
keys in DNSKEY Resource Records (RRs). Because old keys and
frequently used keys are vulnerable, they must be renewed
periodically. In DNSSEC, this is the case for Zone Signing Keys
(ZSKs) and Key Signing Keys (KSKs) [1][2]. Automation of key
exchanges between parents and children is necessary for large zones
because there are too many changes to handle.
Let us consider for example a zone with 100000 secure delegations.
If the child zones change their keys once a year on average, that
implies 300 changes per day for the parent zone. This amount of
changes is hard to manage manually.
Automated rollover is optional and resulting from an agreement
between the administrator of the parent zone and the administrator of
the child zone. Of course, key rollover can also be done manually by
administrators.
This document describes the requirements for a protocol to perform
the automated key rollover process and focusses on interaction
between parent and child zone.
2. The Key Rollover Process
Key rollover consists of renewing the DNSSEC keys used to sign
resource records in a given DNS zone file. There are two types of
rollover, ZSK rollovers and KSK rollovers.
During a ZSK rollover, all changes are local to the zone that renews
its key: there is no need to contact other zones administrators to
propagate the performed changes because a ZSK has no associated DS
record in the parent zone.
During a KSK rollover, new DS RR(s) must be created and stored in the
parent zone. In consequence, data must be exchanged between child
and parent zones.
The key rollover is built from two parts of different nature:
o An algorithm that generates new keys and signs the zone file. It
can be local to the zone,
o the interaction between parent and child zones.
One example of manual key rollover [3] is:
o The child zone creates a new KSK,
Guette & Courtay Expires July 19, 2005 [Page 3]
Internet-Draft Automated Rollover Requirements January 2005
o the child zone waits for the creation of the DS RR in its parent
zone,
o the child zone deletes the old key,
o the parent zone deletes the old DS RR.
This document concentrates on defining interactions between entities
present in key rollover process.
3. Basic Requirements
This section provides the requirements for automated key rollover in
case of normal use. Exceptional case like emergency rollover is
specifically described later in this document.
The main condition during a key rollover is that the chain of trust
must be preserved to every validating DNS client. No matter if this
client retrieves some of the RRs from recursive caching name server
or from the authoritative servers for the zone involved in the
rollover.
Automated key rollover solution may be interrupted by a manual
intervention. This manual intervention should not compromise the
security state of the chain of trust. If the chain is safe before
the manual intervention, the chain of trust must remain safe during
and after the manual intervention
Two entities act during a KSK rollover: the child zone and its parent
zone. These zones are generally managed by different administrators.
These administrators should agree on some parameters like
availability of automated rollover, the maximum delay between
notification of changes in the child zone and the resigning of the
parent zone. The child zone needs to know this delay to schedule its
changes and/or to verify that the changes had been taken into account
in the parent zone. Hence, the child zone can also avoid some
critical cases where all child key are changed prior to the DS RR
creation.
By keeping some resource records during a given time, the recursive
cache servers can act on the automated rollover. The existence of
recursive cache servers must be taken into account by automated
rollover solution.
Indeed, during an automated key rollover a name server could have to
retrieve some DNSSEC data. An automated key rollover solution must
ensure that these data are not old DNSSEC material retrieved from a
recursive name server.
Guette & Courtay Expires July 19, 2005 [Page 4]
Internet-Draft Automated Rollover Requirements January 2005
4. Messages authentication and information exchanged
This section addresses in-band rollover, security of out-of-band
mechanisms is out of scope of this document.
The security provided by DNSSEC must not be compromised by the key
rollover, thus every exchanged message must be authenticated to avoid
fake rollover messages from malicious parties.
Once the changes related to a KSK are made in a child zone, there are
two ways for the parent zone to take this changes into account:
o the child zone notify directly or not directly its parent zone in
order to create the new DS RR and store this DS RR in parent zone
file,
o or the parent zone poll the child zone.
In both cases, the parent zone must receive all the child keys that
need the creation of associated DS RRs in the parent zone.
Because errors could occur during the transmission of keys between
child and parent, the key exchange protocol must be fault tolerant.
Should an error occured during the automated key rollover, an
automated key rollover solution must be able to keep the zone files
in a consistent state.
5. Emergency Rollover
Emergency key rollover is a special case of rollover decided by the
zone administrator generally for security reasons. In consequence,
emergency key rollover can break some of the requirement described
above.
A zone key might be compromised and an attacker can use the
compromised key to create and sign fake records. To avoid this, the
zone administrator may change the compromised key or all its keys as
soon as possible, without waiting for the creation of new DS RRs in
its parent zone.
Fast changes may break the chain of trust. The part of DNS tree
having this zone as apex can become unverifiable, but the break of
the chain of trust is necessary if the administrator wants to prevent
the compromised key from being used (to spoof DNS data).
Parent and child zones sharing an automated rollover mechanism,
should have an out-of-band way to re-establish a consistent state at
the delegation point (DS and DNSKEY RRs). This allows to avoid that
a malicious party uses the compromised key to roll the zone keys.
Guette & Courtay Expires July 19, 2005 [Page 5]
Internet-Draft Automated Rollover Requirements January 2005
6. Security consideration
The automated key rollover process in DNSSEC allows automated renewal
of any kind of DNS key (ZSK or KSK). It is essential that parent
side and child side can do mutual authentication. Moreover,
integrity of the material exchanged between the parent and child zone
must be provided to ensure the right DS are created.
As in any application using public key cryptography, in DNSSEC a key
may be compromised. What to do in such a case can be describe in the
zone local policy and can violate some requirements described in this
draft. The emergency rollover can break the chain of trust in order
to protect the zone against the use of the compromised key.
7. Acknowledgments
The authors want to thank members of IDsA project for their
contribution to this document.
8 Normative References
[1] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
RFC 3658, December 2003.
[2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
(DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
RFC 3757, May 2004.
[3] Kolkman, O., "DNSSEC Operational Practices",
draft-ietf-dnsop-dnssec-operational-practice-01 (work in
progress), May 2004.
[4] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[5] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
"Resource Records for the DNS Security Extensions",
draft-ietf-dnsext-dnssec-records-11 (work in progress), October
2004.
[6] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
"DNS Security Introduction and Requirements",
draft-ietf-dnsext-dnssec-intro-13 (work in progress), October
2004.
[7] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October
Guette & Courtay Expires July 19, 2005 [Page 6]
Internet-Draft Automated Rollover Requirements January 2005
2004.
Authors' Addresses
Gilles Guette
IRISA / INRIA
Campus de Beaulieu
35042 Rennes CEDEX
FR
EMail: gilles.guette@irisa.fr
URI: http://www.irisa.fr
Olivier Courtay
Thomson R&D
1, avenue Belle Fontaine
35510 Cesson S?vign? CEDEX
FR
EMail: olivier.courtay@thomson.net
Appendix A. Documents details and changes
This section is to be removed by the RFC editor if and when the
document is published.
Section about NS RR rollover has been removed
Remarks from Samuel Weiler and Rip Loomis added
Clarification about in-band rollover and in emergency section
Section 3, details about recursive cache servers added
Guette & Courtay Expires July 19, 2005 [Page 7]
Internet-Draft Automated Rollover Requirements January 2005
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
IETF Documents can be found in BCP 78 and 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 which may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr.org.
Full Copyright Statement
Copyright (C) The Internet Society (2005). 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 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Guette & Courtay Expires July 19, 2005 [Page 8]

480
contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-02.txt Normal file
View File

@ -0,0 +1,480 @@
DNSOP Working Group Paul Vixie, ISC
INTERNET-DRAFT Akira Kato, WIDE
<draft-ietf-dnsop-respsize-02.txt> July 2005
DNS Response Size Issues
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.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
With a mandated default minimum maximum message size of 512 octets,
the DNS protocol presents some special problems for zones wishing to
expose a moderate or high number of authority servers (NS RRs). This
document explains the operational issues caused by, or related to
this response size limit.
Expires December 2005 [Page 1]
INTERNET-DRAFT July 2005 RESPSIZE
1 - Introduction and Overview
1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
octets. Even though this limitation was due to the required minimum UDP
reassembly limit for IPv4, it is a hard DNS protocol limit and is not
implicitly relaxed by changes in transport, for example to IPv6.
1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger
responses by mutual agreement of the requestor and responder. However,
deployment of EDNS0 cannot be expected to reach every Internet resolver
in the short or medium term. The 512 octet message size limit remains
in practical effect at this time.
1.3. Since DNS responses include a copy of the request, the space
available for response data is somewhat less than the full 512 octets.
For negative responses, there is rarely a space constraint. For
positive and delegation responses, though, every octet must be carefully
and sparingly allocated. This document specifically addresses
delegation response sizes.
2 - Delegation Details
2.1. A delegation response will include the following elements:
Header Section: fixed length (12 octets)
Question Section: original query (name, class, type)
Answer Section: (empty)
Authority Section: NS RRset (nameserver names)
Additional Section: A and AAAA RRsets (nameserver addresses)
2.2. If the total response size would exceed 512 octets, and if the data
that would not fit belonged in the question, answer, or authority
section, then the TC bit will be set (indicating truncation) which may
cause the requestor to retry using TCP, depending on what information
was desired and what information was omitted. If a retry using TCP is
needed, the total cost of the transaction is much higher. (See [RFC1123
6.1.3.2] for details on the protocol requirement that UDP be attempted
before falling back to TCP.)
2.3. RRsets are never sent partially unless truncation occurs, in which
case the final apparent RRset in the final nonempty section must be
considered "possibly damaged". With or without truncation, the glue
present in the additional data section should be considered "possibly
incomplete", and requestors should be prepared to re-query for any
damaged or missing RRsets. For multi-transport name or mail services,
Expires December 2005 [Page 2]
INTERNET-DRAFT July 2005 RESPSIZE
this can mean querying for an IPv6 (AAAA) RRset even when an IPv4 (A)
RRset is present.
2.4. DNS label compression allows a domain name to be instantiated only
once per DNS message, and then referenced with a two-octet "pointer"
from other locations in that same DNS message. If all nameserver names
in a message are similar (for example, all ending in ".ROOT-
SERVERS.NET"), then more space will be available for uncompressable data
(such as nameserver addresses).
2.5. The query name can be as long as 255 characters of presentation
data, which can be up to 256 octets of network data. In this worst case
scenario, the question section will be 260 octets in size, which would
leave only 240 octets for the authority and additional sections (after
deducting 12 octets for the fixed length header.)
2.6. Average and maximum question section sizes can be predicted by the
zone owner, since they will know what names actually exist, and can
measure which ones are queried for most often. For cost and performance
reasons, the majority of requests should be satisfied without truncation
or TCP retry.
2.7. Requestors who deliberately send large queries to force truncation
are only increasing their own costs, and cannot effectively attack the
resources of an authority server since the requestor would have to retry
using TCP to complete the attack. An attack that always used TCP would
have a lower cost.
2.8. The minimum useful number of address records is two, since with
only one address, the probability that it would refer to an unreachable
server is too high. Truncation which occurs after two address records
have been added to the additional data section is therefore less
operationally significant than truncation which occurs earlier.
2.9. The best case is no truncation. This is because many requestors
will retry using TCP by reflex, or will automatically re-query for
RRsets that are "possibly truncated", without considering whether the
omitted data was actually necessary.
2.10. Each added NS RR for a zone will add a minimum of between 16 and
44 octets to every untruncated referral or negative response from the
zone's authority servers (16 octets for an NS RR, 16 octets for an A RR,
and 28 octets for an AAAA RR), in addition to whatever space is taken by
the nameserver name (NS NSDNAME and A/AAAA owner name).
Expires December 2005 [Page 3]
INTERNET-DRAFT July 2005 RESPSIZE
3 - Analysis
3.1. An instrumented protocol trace of a best case delegation response
follows. Note that 13 servers are named, and 13 addresses are given.
This query was artificially designed to exactly reach the 512 octet
limit.
;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
;; QUERY SECTION:
;; [23456789.123456789.123456789.\
123456789.123456789.123456789.com A IN] ;; @80
;; AUTHORITY SECTION:
com. 86400 NS E.GTLD-SERVERS.NET. ;; @112
com. 86400 NS F.GTLD-SERVERS.NET. ;; @128
com. 86400 NS G.GTLD-SERVERS.NET. ;; @144
com. 86400 NS H.GTLD-SERVERS.NET. ;; @160
com. 86400 NS I.GTLD-SERVERS.NET. ;; @176
com. 86400 NS J.GTLD-SERVERS.NET. ;; @192
com. 86400 NS K.GTLD-SERVERS.NET. ;; @208
com. 86400 NS L.GTLD-SERVERS.NET. ;; @224
com. 86400 NS M.GTLD-SERVERS.NET. ;; @240
com. 86400 NS A.GTLD-SERVERS.NET. ;; @256
com. 86400 NS B.GTLD-SERVERS.NET. ;; @272
com. 86400 NS C.GTLD-SERVERS.NET. ;; @288
com. 86400 NS D.GTLD-SERVERS.NET. ;; @304
;; ADDITIONAL SECTION:
A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320
B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336
C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352
D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368
E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384
F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400
G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416
H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432
I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448
J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464
K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480
L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496
M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512
;; MSG SIZE sent: 80 rcvd: 512
Expires December 2005 [Page 4]
INTERNET-DRAFT July 2005 RESPSIZE
3.2. For longer query names, the number of address records supplied will
be lower. Furthermore, it is only by using a common parent name (which
is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
fit. The following output from a response simulator demonstrates these
properties:
% perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br
a.dns.br requires 10 bytes
b.dns.br requires 4 bytes
c.dns.br requires 4 bytes
d.dns.br requires 4 bytes
# of NS: 4
For maximum size query (255 byte):
if only A is considered: # of A is 4 (green)
if A and AAAA are condered: # of A+AAAA is 3 (yellow)
if prefer_glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
For average size query (64 byte):
if only A is considered: # of A is 4 (green)
if A and AAAA are condered: # of A+AAAA is 4 (green)
if prefer_glue A is assumed: # of A is 4, # of AAAA is 4 (green)
% perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
ns-ext.isc.org requires 16 bytes
ns.psg.com requires 12 bytes
ns.ripe.net requires 13 bytes
ns.eu.int requires 11 bytes
# of NS: 4
For maximum size query (255 byte):
if only A is considered: # of A is 4 (green)
if A and AAAA are condered: # of A+AAAA is 3 (yellow)
if prefer_glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
For average size query (64 byte):
if only A is considered: # of A is 4 (green)
if A and AAAA are condered: # of A+AAAA is 4 (green)
if prefer_glue A is assumed: # of A is 4, # of AAAA is 4 (green)
(Note: The response simulator program is shown in Section 5.)
Here we use the term "green" if all address records could fit, or
"orange" if two or more could fit, or "red" if fewer than two could fit.
It's clear that without a common parent for nameserver names, much space
would be lost. For these examples we use an average/common name size of
15 octets, befitting our assumption of GTLD-SERVERS.NET as our common
parent name.
Expires December 2005 [Page 5]
INTERNET-DRAFT July 2005 RESPSIZE
We're assuming an average query name size of 64 since that is the
typical average maximum size seen in trace data at the time of this
writing. If Internationalized Domain Name (IDN) or any other technology
which results in larger query names be deployed significantly in advance
of EDNS, then new measurements and new estimates will have to be made.
4 - Conclusions
4.1. The current practice of giving all nameserver names a common parent
(such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
responses and allows for more nameservers to be enumerated than would
otherwise be possible. (Note that in this case it is wise to serve the
common parent domain's zone from the same servers that are named within
it, in order to limit external dependencies when all your eggs are in a
single basket.)
4.2. Thirteen (13) seems to be the effective maximum number of
nameserver names usable traditional (non-extended) DNS, assuming a
common parent domain name, and given that response truncation is
undesirable as an average case, and assuming mostly IPv4-only
reachability (only A RRs exist, not AAAA RRs).
4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a
prototypical delegation that currently contains thirteen (13) IPv4
nameserver addresses (A RRs) for thirteen (13) nameserver names under a
common parent, would not have a significant negative operational impact
on the domain name system.
5 - Source Code
#!/usr/bin/perl
#
# SYNOPSIS
# repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
# if all queries are assumed to have zone suffux, such as "jp" in
# JP TLD servers, specify it in -z option
#
use strict;
use Getopt::Std;
my ($sz_msg) = (512);
my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
my (%namedb, $name, $nssect, %opts, $optz);
my $n_ns = 0;
Expires December 2005 [Page 6]
INTERNET-DRAFT July 2005 RESPSIZE
getopt('z', opts);
if (defined($opts{'z'})) {
server_name_len($opts{'z'}); # just register it
}
foreach $name (@ARGV) {
my $len;
$n_ns++;
$len = server_name_len($name);
print "$name requires $len bytes\n";
$nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl + $sz_rdlen + $len;
}
print "# of NS: $n_ns\n";
arsect(255, $nssect, $n_ns, "maximum");
arsect(64, $nssect, $n_ns, "average");
sub server_name_len {
my ($name) = @_;
my (@labels, $len, $n, $suffix);
$name =~ tr/A-Z/a-z/;
@labels = split(/./, $name);
$len = length(join('.', @labels)) + 2;
for ($n = 0; $#labels >= 0; $n++, shift @labels) {
$suffix = join('.', @labels);
return length($name) - length($suffix) + $sz_ptr
if (defined($namedb{$suffix}));
$namedb{$suffix} = 1;
}
return $len;
}
sub arsect {
my ($sz_query, $nssect, $n_ns, $cond) = @_;
my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
$ansect = $sz_query + 1 + $sz_type + $sz_class;
$space = $sz_msg - $sz_header - $ansect - $nssect;
$n_a = atmost(int($space / $sz_rr_a), $n_ns);
$n_a_aaaa = atmost(int($space / ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
$n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns) / $sz_rr_aaaa), $n_ns);
printf "For %s size query (%d byte):\n", $cond, $sz_query;
printf "if only A is considered: ";
printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
printf "if A and AAAA are condered: ";
printf "# of A+AAAA is %d (%s)\n", $n_a_aaaa, &judge($n_a_aaaa, $n_ns);
Expires December 2005 [Page 7]
INTERNET-DRAFT July 2005 RESPSIZE
printf "if prefer_glue A is assumed: ";
printf "# of A is %d, # of AAAA is %d (%s)\n",
$n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns);
}
sub judge {
my ($n, $n_ns) = @_;
return "green" if ($n >= $n_ns);
return "yellow" if ($n >= 2);
return "orange" if ($n == 1);
return "red";
}
sub atmost {
my ($a, $b) = @_;
return 0 if ($a < 0);
return $b if ($a > $b);
return $a;
}
Security Considerations
The recommendations contained in this document have no known security
implications.
IANA Considerations
This document does not call for changes or additions to any IANA
registry.
IPR Statement
Copyright (C) The Internet Society (2005). 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 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.
Expires December 2005 [Page 8]
INTERNET-DRAFT July 2005 RESPSIZE
Authors' Addresses
Paul Vixie
950 Charter Street
Redwood City, CA 94063
+1 650 423 1301
vixie@isc.org
Akira Kato
University of Tokyo, Information Technology Center
2-11-16 Yayoi Bunkyo
Tokyo 113-8658, JAPAN
+81 3 5841 2750
kato@wide.ad.jp
Expires December 2005 [Page 9]

616
contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-04.txt Normal file
View File

@ -0,0 +1,616 @@
Network Working Group S. Woolf
Internet-Draft Internet Systems Consortium, Inc.
Expires: September 14, 2005 D. Conrad
Nominum, Inc.
March 13, 2005
Identifying an Authoritative Name Server
draft-ietf-dnsop-serverid-04
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 September 14, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
With the increased use of DNS anycast, load balancing, and other
mechanisms allowing more than one DNS name server to share a single
IP address, it is sometimes difficult to tell which of a pool of name
servers has answered a particular query. A standardized mechanism to
determine the identity of a name server responding to a particular
Woolf & Conrad Expires September 14, 2005 [Page 1]
Internet-Draft Identifying an Authoritative Name Server March 2005
query would be useful, particularly as a diagnostic aid. Existing ad
hoc mechanisms for addressing this concern are not adequate. This
document attempts to describe the common ad hoc solution to this
problem, including its advantages and disadvantages, and to
characterize an improved mechanism.
Woolf & Conrad Expires September 14, 2005 [Page 2]
Internet-Draft Identifying an Authoritative Name Server March 2005
1. Introduction
With the increased use of DNS anycast, load balancing, and other
mechanisms allowing more than one DNS name server to share a single
IP address, it is sometimes difficult to tell which of a pool of name
servers has answered a particular query. A standardized mechanism to
determine the identity of a name server responding to a particular
query would be useful, particularly as a diagnostic aid.
Unfortunately, existing ad-hoc mechanisms for providing such
identification have some shortcomings, not the least of which is the
lack of prior analysis of exactly how such a mechanism should be
designed and deployed. This document describes the existing
convention used in one widely deployed implementation of the DNS
protocol and discusses requirements for an improved solution to the
problem.
Woolf & Conrad Expires September 14, 2005 [Page 3]
Internet-Draft Identifying an Authoritative Name Server March 2005
2. Rationale
Identifying which name server is responding to queries is often
useful, particularly in attempting to diagnose name server
difficulties. However, relying on the IP address of the name server
has become more problematic due the deployment of various load
balancing solutions, including the use of shared unicast addresses as
documented in [RFC3258].
An unfortunate side effect of these load balancing solutions, and
some changes in management practices as the public Internet has
evolved, is that traditional methods of determining which server is
responding can be unreliable. Specifically, non-DNS methods such as
ICMP ping, TCP connections, or non-DNS UDP packets (such as those
generated by tools such as "traceroute"), etc., can end up going to a
different server than that which receives the DNS queries.
There is a well-known and frequently-used technique for determining
an identity for a nameserver more specific than the
possibly-non-unique "server that answered my query". The widespread
use of the existing convention suggests a need for a documented,
interoperable means of querying the identity of a nameserver that may
be part of an anycast or load-balancing cluster. At the same time,
however, it also has some drawbacks that argue against standardizing
it as it's been practiced so far.
Woolf & Conrad Expires September 14, 2005 [Page 4]
Internet-Draft Identifying an Authoritative Name Server March 2005
3. Existing Conventions
Recent versions of the commonly deployed Berkeley Internet Name
Domain implementation of the DNS protocol suite from the Internet
Software Consortium [BIND] support a way of identifying a particular
server via the use of a standard, if somewhat unusual, DNS query.
Specifically, a query to a late model BIND server for a TXT resource
record in class 3 (CHAOS) for the domain name "HOSTNAME.BIND." will
return a string that can be configured by the name server
administrator to provide a unique identifier for the responding
server (defaulting to the value of a gethostname() call). This
mechanism, which is an extension of the BIND convention of using
CHAOS class TXT RR queries to sub-domains of the "BIND." domain for
version information, has been copied by several name server vendors.
For reference, the other well-known name used by recent versions of
BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A
query for a TXT RR for this name will return an administratively
defined string which defaults to the version of the server
responding. This is, however, not generally implemented by other
vendors.
3.1 Advantages
There are several valuable attributes to this mechanism, which
account for its usefulness.
1. The "hostname.bind" query response mechanism is within the DNS
protocol itself. An identification mechanism that relies on the
DNS protocol is more likely to be successful (although not
guaranteed) in going to the same machine as a "normal" DNS query.
2. Since the identity information is requested and returned within
the DNS protocol, it doesn't require allowing any other query
mechanism to the server, such as holes in firewalls for
otherwise-unallowed ICMP Echo requests. Thus it does not require
any special exceptions to site security policy.
3. It is simple to configure. An administrator can easily turn on
this feature and control the results of the relevant query.
4. It allows the administrator complete control of what information
is given out in the response, minimizing passive leakage of
implementation or configuration details. Such details are often
considered sensitive by infrastructure operators.
3.2 Disadvantages
At the same time, there are some forbidding drawbacks to the
VERSION.BIND mechanism that argue against standardizing it as it
currently operates.
Woolf & Conrad Expires September 14, 2005 [Page 5]
Internet-Draft Identifying an Authoritative Name Server March 2005
1. It requires an additional query to correlate between the answer
to a DNS query under normal conditions and the supposed identity
of the server receiving the query. There are a number of
situations in which this simply isn't reliable.
2. It reserves an entire class in the DNS (CHAOS) for what amounts
to one zone. While CHAOS class is defined in [RFC1034] and
[RFC1035], it's not clear that supporting it solely for this
purpose is a good use of the namespace or of implementation
effort.
3. It is implementation specific. BIND is one DNS implementation.
At the time of this writing, it is probably the most prevalent
for authoritative servers. This does not justify standardizing
on its ad hoc solution to a problem shared across many operators
and implementors.
The first of the listed disadvantages is technically the most
serious. It argues for an attempt to design a good answer to the
problem that "I need to know what nameserver is answering my
queries", not simply a convenient one.
Woolf & Conrad Expires September 14, 2005 [Page 6]
Internet-Draft Identifying an Authoritative Name Server March 2005
4. Characteristics of an Implementation Neutral Convention
The discussion above of advantages and disadvantages to the
HOSTNAME.BIND mechanism suggest some requirements for a better
solution to the server identification problem. These are summarized
here as guidelines for any effort to provide appropriate protocol
extensions:
1. The mechanism adopted MUST be in-band for the DNS protocol. That
is, it needs to allow the query for the server's identifying
information to be part of a normal, operational query. It SHOULD
also permit a separate, dedicated query for the server's
identifying information.
2. The new mechanism SHOULD not require dedicated namespaces or
other reserved values outside of the existing protocol mechanisms
for these, i.e. the OPT pseudo-RR. In particular, it should not
propagate the existing drawback of requiring support for a CLASS
and top level domain in the authoritative server (or the querying
tool) to be useful.
3. Support for the identification functionality SHOULD be easy to
implement and easy to enable. It MUST be easy to disable and
SHOULD lend itself to access controls on who can query for it.
4. It should be possible to return a unique identifier for a server
without requiring the exposure of information that may be
non-public and considered sensitive by the operator, such as a
hostname or unicast IP address maintained for administrative
purposes.
5. The identification mechanism SHOULD NOT be
implementation-specific.
Woolf & Conrad Expires September 14, 2005 [Page 7]
Internet-Draft Identifying an Authoritative Name Server March 2005
5. IANA Considerations
This document proposes no specific IANA action. Protocol extensions,
if any, to meet the requirements described are out of scope for this
document. Should such extensions be specified and adopted by normal
IETF process, the specification will include appropriate guidance to
IANA.
Woolf & Conrad Expires September 14, 2005 [Page 8]
Internet-Draft Identifying an Authoritative Name Server March 2005
6. Security Considerations
Providing identifying information as to which server is responding to
a particular query from a particular location in the Internet can be
seen as information leakage and thus a security risk. This motivates
the suggestion above that a new mechanism for server identification
allow the administrator to disable the functionality altogether or
partially restrict availability of the data. It also suggests that
the serverid data should not be readily correlated with a hostname or
unicast IP address that may be considered private to the nameserver
operator's management infrastructure.
Propagation of protocol or service meta-data can sometimes expose the
application to denial of service or other attack. As DNS is a
critically important infrastructure service for the production
Internet, extra care needs to be taken against this risk for
designers, implementors, and operators of a new mechanism for server
identification.
Woolf & Conrad Expires September 14, 2005 [Page 9]
Internet-Draft Identifying an Authoritative Name Server March 2005
7. Acknowledgements
The technique for host identification documented here was initially
implemented by Paul Vixie of the Internet Software Consortium in the
Berkeley Internet Name Daemon package. Comments and questions on
earlier drafts were provided by Bob Halley, Brian Wellington, Andreas
Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the
ICANN Root Server System Advisory Committee. The newest version
takes a significantly different direction from previous versions,
owing to discussion among contributors to the DNSOP working group and
others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam
Weiler, and Rob Austein.
Woolf & Conrad Expires September 14, 2005 [Page 10]
Internet-Draft Identifying an Authoritative Name Server March 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Woolf & Conrad Expires September 14, 2005 [Page 11]

451
contrib/bind9/doc/rfc/rfc3757.txt Normal file
View File

@ -0,0 +1,451 @@
Network Working Group O. Kolkman
Request for Comments: 3757 RIPE NCC
Updates: 3755, 2535 J. Schlyter
Category: Standards Track NIC-SE
E. Lewis
ARIN
April 2004
Domain Name System KEY (DNSKEY) Resource Record (RR)
Secure Entry Point (SEP) Flag
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 (2004). All Rights Reserved.
Abstract
With the Delegation Signer (DS) resource record (RR), the concept of
a public key acting as a secure entry point (SEP) has been
introduced. During exchanges of public keys with the parent there is
a need to differentiate SEP keys from other public keys in the Domain
Name System KEY (DNSKEY) resource record set. A flag bit in the
DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP.
The flag bit is intended to assist in operational procedures to
correctly generate DS resource records, or to indicate what DNSKEYs
are intended for static configuration. The flag bit is not to be
used in the DNS verification protocol. This document updates RFC
2535 and RFC 3755.
Kolkman, et al. Standard Track [Page 1]
RFC 3757 DNSKEY RR SEP Flag April 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Secure Entry Point (SEP) Flag. . . . . . . . . . . . . . . 4
3. DNSSEC Protocol Changes. . . . . . . . . . . . . . . . . . . . 4
4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
7. Internationalization Considerations. . . . . . . . . . . . . . 6
8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 6
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
1. Introduction
"All keys are equal but some keys are more equal than others" [6].
With the definition of the Delegation Signer Resource Record (DS RR)
[5], it has become important to differentiate between the keys in the
DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
other keys in the DNSKEY RR set. We refer to these public keys as
Secure Entry Point (SEP) keys. A SEP key either used to generate a
DS RR or is distributed to resolvers that use the key as the root of
a trusted subtree [3].
In early deployment tests, the use of two (kinds of) key pairs for
each zone has been prevalent. For one kind of key pair the private
key is used to sign just the zone's DNSKEY resource record (RR) set.
Its public key is intended to be referenced by a DS RR at the parent
or configured statically in a resolver. The private key of the other
kind of key pair is used to sign the rest of the zone's data sets.
The former key pair is called a key-signing key (KSK) and the latter
is called a zone-signing key (ZSK). In practice there have been
usually one of each kind of key pair, but there will be multiples of
each at times.
It should be noted that division of keys pairs into KSK's and ZSK's
is not mandatory in any definition of DNSSEC, not even with the
introduction of the DS RR. But, in testing, this distinction has
been helpful when designing key roll over (key super-cession)
schemes. Given that the distinction has proven helpful, the labels
KSK and ZSK have begun to stick.
Kolkman, et al. Standard Track [Page 2]
RFC 3757 DNSKEY RR SEP Flag April 2004
There is a need to differentiate the public keys for the key pairs
that are used for key signing from keys that are not used key signing
(KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to
be sent for generating DS RRs, which DNSKEYs are to be distributed to
resolvers, and which keys are fed to the signer application at the
appropriate time.
In other words, the SEP bit provides an in-band method to communicate
a DNSKEY RR's intended use to third parties. As an example we
present 3 use cases in which the bit is useful:
The parent is a registry, the parent and the child use secured DNS
queries and responses, with a preexisting trust-relation, or plain
DNS over a secured channel to exchange the child's DNSKEY RR sets.
Since a DNSKEY RR set will contain a complete DNSKEY RRset the SEP
bit can be used to isolate the DNSKEYs for which a DS RR needs to
be created.
An administrator has configured a DNSKEY as root for a trusted
subtree into security aware resolver. Using a special purpose
tool that queries for the KEY RRs from that domain's apex, the
administrator will be able to notice the roll over of the trusted
anchor by a change of the subset of KEY RRs with the DS flag set.
A signer might use the SEP bit on the public key to determine
which private key to use to exclusively sign the DNSKEY RRset and
which private key to use to sign the other RRsets in the zone.
As demonstrated in the above examples it is important to be able to
differentiate the SEP keys from the other keys in a DNSKEY RR set in
the flow between signer and (parental) key-collector and in the flow
between the signer and the resolver configuration. The SEP flag is
to be of no interest to the flow between the verifier and the
authoritative data store.
The reason for the term "SEP" is a result of the observation that the
distinction between KSK and ZSK key pairs is made by the signer, a
key pair could be used as both a KSK and a ZSK at the same time. To
be clear, the term SEP was coined to lessen the confusion caused by
the overlap. (Once this label was applied, it had the side effect of
removing the temptation to have both a KSK flag bit and a ZSK flag
bit.)
The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
"RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
interpreted as described in BCP 14, RFC 2119 [1].
Kolkman, et al. Standard Track [Page 3]
RFC 3757 DNSKEY RR SEP Flag April 2004
2. The Secure Entry Point (SEP) Flag
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |S| protocol | algorithm |
| |E| | |
| |P| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DNSKEY RR Format
This document assigns the 15th bit in the flags field as the secure
entry point (SEP) bit. If the bit is set to 1 the key is intended to
be used as secure entry point key. One SHOULD NOT assign special
meaning to the key if the bit is set to 0. Operators can recognize
the secure entry point key by the even or odd-ness of the decimal
representation of the flag field.
3. DNSSEC Protocol Changes
The bit MUST NOT be used during the resolving and verification
process. The SEP flag is only used to provide a hint about the
different administrative properties of the key and therefore the use
of the SEP flag does not change the DNS resolution protocol or the
resolution process.
4. Operational Guidelines
The SEP bit is set by the key-pair-generator and MAY be used by the
zone signer to decide whether the public part of the key pair is to
be prepared for input to a DS RR generation function. The SEP bit is
recommended to be set (to 1) whenever the public key of the key pair
will be distributed to the parent zone to build the authentication
chain or if the public key is to be distributed for static
configuration in verifiers.
When a key pair is created, the operator needs to indicate whether
the SEP bit is to be set in the DNSKEY RR. As the SEP bit is within
the data that is used to compute the 'key tag field' in the SIG RR,
changing the SEP bit will change the identity of the key within DNS.
In other words, once a key is used to generate signatures, the
setting of the SEP bit is to remain constant. If not, a verifier
will not be able to find the relevant KEY RR.
Kolkman, et al. Standard Track [Page 4]
RFC 3757 DNSKEY RR SEP Flag April 2004
When signing a zone, it is intended that the key(s) with the SEP bit
set (if such keys exist) are used to sign the KEY RR set of the zone.
The same key can be used to sign the rest of the zone data too. It
is conceivable that not all keys with a SEP bit set will sign the
DNSKEY RR set, such keys might be pending retirement or not yet in
use.
When verifying a RR set, the SEP bit is not intended to play a role.
How the key is used by the verifier is not intended to be a
consideration at key creation time.
Although the SEP flag provides a hint on which public key is to be
used as trusted root, administrators can choose to ignore the fact
that a DNSKEY has its SEP bit set or not when configuring a trusted
root for their resolvers.
Using the SEP flag a key roll over can be automated. The parent can
use an existing trust relation to verify DNSKEY RR sets in which a
new DNSKEY RR with the SEP flag appears.
5. Security Considerations
As stated in Section 3 the flag is not to be used in the resolution
protocol or to determine the security status of a key. The flag is
to be used for administrative purposes only.
No trust in a key should be inferred from this flag - trust MUST be
inferred from an existing chain of trust or an out-of-band exchange.
Since this flag might be used for automating public key exchanges, we
think the following consideration is in place.
Automated mechanisms for roll over of the DS RR might be vulnerable
to a class of replay attacks. This might happen after a public key
exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
SEP flag set, is sent to the parent. The parent verifies the DNSKEY
RR set with the existing trust relation and creates the new DS RR
from the DNSKEY RR that the current DS RR is not pointing to. This
key exchange might be replayed. Parents are encouraged to implement
a replay defense. A simple defense can be based on a registry of
keys that have been used to generate DS RRs during the most recent
roll over. These same considerations apply to entities that
configure keys in resolvers.
Kolkman, et al. Standard Track [Page 5]
RFC 3757 DNSKEY RR SEP Flag April 2004
6. IANA Considerations
IANA has assigned the 15th bit in the DNSKEY Flags Registry (see
Section 4.3 of [4]) as the Secure Entry Point (SEP) bit.
7. Internationalization Considerations
Although SEP is a popular acronym in many different languages, there
are no internationalization considerations.
8. Acknowledgments
The ideas documented in this document are inspired by communications
we had with numerous people and ideas published by other folk. Among
others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
have contributed ideas and provided feedback.
This document saw the light during a workshop on DNSSEC operations
hosted by USC/ISI in August 2002.
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[3] Lewis, E., "DNS Security Extension Clarification on Zone
Status", RFC 3090, March 2001.
[4] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer
(DS)", RFC 3755, April 2004.
9.2. Informative References
[5] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
RFC 3658, December 2003.
[6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
Story", ISBN 0151002177 (50th anniversary edition), April 1996.
Kolkman, et al. Standard Track [Page 6]
RFC 3757 DNSKEY RR SEP Flag April 2004
10. Authors' Addresses
Olaf M. Kolkman
RIPE NCC
Singel 256
Amsterdam 1016 AB
NL
Phone: +31 20 535 4444
EMail: olaf@ripe.net
URI: http://www.ripe.net/
Jakob Schlyter
NIC-SE
Box 5774
SE-114 87 Stockholm
Sweden
EMail: jakob@nic.se
URI: http://www.nic.se/
Edward P. Lewis
ARIN
3635 Concorde Parkway Suite 200
Chantilly, VA 20151
US
Phone: +1 703 227 9854
EMail: edlewis@arin.net
URI: http://www.arin.net/
Kolkman, et al. Standard Track [Page 7]
RFC 3757 DNSKEY RR SEP Flag April 2004
11. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kolkman, et al. Standard Track [Page 8]

283
contrib/bind9/doc/rfc/rfc3901.txt Normal file
View File

@ -0,0 +1,283 @@
Network Working Group A. Durand
Request for Comments: 3901 SUN Microsystems, Inc.
BCP: 91 J. Ihren
Category: Best Current Practice Autonomica
September 2004
DNS IPv6 Transport Operational Guidelines
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This memo provides guidelines and Best Current Practice for operating
DNS in a world where queries and responses are carried in a mixed
environment of IPv4 and IPv6 networks.
1. Introduction to the Problem of Name Space Fragmentation:
following the referral chain
A resolver that tries to look up a name starts out at the root, and
follows referrals until it is referred to a name server that is
authoritative for the name. If somewhere down the chain of referrals
it is referred to a name server that is only accessible over a
transport which the resolver cannot use, the resolver is unable to
finish the task.
When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
only a matter of time until this starts to happen. The complete DNS
hierarchy then starts to fragment into a graph where authoritative
name servers for certain nodes are only accessible over a certain
transport. The concern is that a resolver using only a particular
version of IP and querying information about another node using the
same version of IP can not do it because somewhere in the chain of
servers accessed during the resolution process, one or more of them
will only be accessible with the other version of IP.
With all DNS data only available over IPv4 transport everything is
simple. IPv4 resolvers can use the intended mechanism of following
referrals from the root and down while IPv6 resolvers have to work
Durand & Ihren Best Current Practice [Page 1]
RFC 3901 DNS IPv6 Transport Guidelines September 2004
through a "translator", i.e., they have to use a recursive name
server on a so-called "dual stack" host as a "forwarder" since they
cannot access the DNS data directly.
With all DNS data only available over IPv6 transport everything would
be equally simple, with the exception of IPv4 recursive name servers
having to switch to a forwarding configuration.
However, the second situation will not arise in the foreseeable
future. Instead, the transition will be from IPv4 only to a mixture
of IPv4 and IPv6, with three categories of DNS data depending on
whether the information is available only over IPv4 transport, only
over IPv6 or both.
Having DNS data available on both transports is the best situation.
The major question is how to ensure that it becomes the norm as
quickly as possible. However, while it is obvious that some DNS data
will only be available over v4 transport for a long time it is also
obvious that it is important to avoid fragmenting the name space
available to IPv4 only hosts. For example, during transition it is
not acceptable to break the name space that we presently have
available for IPv4-only hosts.
2. Terminology
The phrase "IPv4 name server" indicates a name server available over
IPv4 transport. It does not imply anything about what DNS [1,2] data
is served. Likewise, "IPv6 [4,5,6] name server" indicates a name
server available over IPv6 transport. The phrase "dual-stack name
server" indicates a name server that is actually configured to run
both protocols, IPv4 and IPv6, and not merely a server running on a
system capable of running both but actually configured to run only
one.
3. Policy Based Avoidance of Name Space Fragmentation
Today there are only a few DNS "zones" on the public Internet that
are available over IPv6 transport, and most of them can be regarded
as "experimental". However, as soon as the root and top level
domains are available over IPv6 transport, it is reasonable to expect
that it will become more common to have zones served by IPv6 servers.
Having those zones served only by IPv6-only name server would not be
a good development, since this will fragment the previously
unfragmented IPv4 name space and there are strong reasons to find a
mechanism to avoid it.
Durand & Ihren Best Current Practice [Page 2]
RFC 3901 DNS IPv6 Transport Guidelines September 2004
The recommended approach to maintain name space continuity is to use
administrative policies, as described in the next section.
4. DNS IPv6 Transport recommended Guidelines
In order to preserve name space continuity, the following
administrative policies are recommended:
- every recursive name server SHOULD be either IPv4-only or dual
stack,
This rules out IPv6-only recursive servers. However, one might
design configurations where a chain of IPv6-only name server
forward queries to a set of dual stack recursive name server
actually performing those recursive queries.
- every DNS zone SHOULD be served by at least one IPv4-reachable
authoritative name server.
This rules out DNS zones served only by IPv6-only authoritative
name servers.
Note: zone validation processes SHOULD ensure that there is at least
one IPv4 address record available for the name servers of any child
delegations within the zone.
5. Security Considerations
The guidelines described in this memo introduce no new security
considerations into the DNS protocol or associated operational
scenarios.
6. Acknowledgment
This document is the result of many conversations that happened in
the DNS community at IETF and elsewhere since 2001. During that
period of time, a number of Internet drafts have been published to
clarify various aspects of the issues at stake. This document
focuses on the conclusion of those discussions.
The authors would like to acknowledge the role of Pekka Savola in his
thorough review of the document.
Durand & Ihren Best Current Practice [Page 3]
RFC 3901 DNS IPv6 Transport Guidelines September 2004
7. Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
Extensions to Support IP Version 6", RFC 3596, October 2003.
8. Authors' Addresses
Alain Durand
SUN Microsystems, Inc
17 Network circle UMPK17-202
Menlo Park, CA, 94025
USA
EMail: Alain.Durand@sun.com
Johan Ihren
Autonomica
Bellmansgatan 30
SE-118 47 Stockholm
Sweden
EMail: johani@autonomica.se
Durand & Ihren Best Current Practice [Page 4]
RFC 3901 DNS IPv6 Transport Guidelines September 2004
9. Full Copyright Statement
Copyright (C) The Internet Society (2004).
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/S HE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 IETF's procedures with respect to rights in IETF 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Durand & Ihren Best Current Practice [Page 5]

675
contrib/bind9/doc/rfc/rfc4025.txt Normal file
View File

@ -0,0 +1,675 @@
Network Working Group M. Richardson
Request for Comments: 4025 SSW
Category: Standards Track February 2005
A Method for Storing IPsec Keying Material in DNS
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 (2005).
Abstract
This document describes a new resource record for the Domain Name
System (DNS). This record may be used to store public keys for use
in IP security (IPsec) systems. The record also includes provisions
for indicating what system should be contacted when an IPsec tunnel
is established with the entity in question.
This record replaces the functionality of the sub-type #4 of the KEY
Resource Record, which has been obsoleted by RFC 3445.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and
IP6.ARPA) . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Usage Criteria . . . . . . . . . . . . . . . . . . . . . 3
2. Storage Formats . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. IPSECKEY RDATA Format . . . . . . . . . . . . . . . . . 3
2.2. RDATA Format - Precedence . . . . . . . . . . . . . . . 4
2.3. RDATA Format - Gateway Type . . . . . . . . . . . . . . 4
2.4. RDATA Format - Algorithm Type . . . . . . . . . . . . . 4
2.5. RDATA Format - Gateway . . . . . . . . . . . . . . . . . 5
2.6. RDATA Format - Public Keys . . . . . . . . . . . . . . . 5
3. Presentation Formats . . . . . . . . . . . . . . . . . . . . . 6
3.1. Representation of IPSECKEY RRs . . . . . . . . . . . . . 6
3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
Richardson Standards Track [Page 1]
RFC 4025 Storing IPsec Keying Material in DNS February 2005
4.1. Active Attacks Against Unsecured IPSECKEY Resource
Records . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Active Attacks Against IPSECKEY Keying
Materials. . . . . . . . . . . . . . . . . . . . 8
4.1.2. Active Attacks Against IPSECKEY Gateway
Material. . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Suppose a host wishes (or is required by policy) to establish an
IPsec tunnel with some remote entity on the network prior to allowing
normal communication to take place. In many cases, this end system
will be able to determine the DNS name for the remote entity (either
by having the DNS name given explicitly, by performing a DNS PTR
query for a particular IP address, or through some other means, e.g.,
by extracting the DNS portion of a "user@FQDN" name for a remote
entity). In these cases, the host will need to obtain a public key
to authenticate the remote entity, and may also need some guidance
about whether it should contact the entity directly or use another
node as a gateway to the target entity. The IPSECKEY RR provides a
mechanism for storing such information.
The type number for the IPSECKEY RR is 45.
This record replaces the functionality of the sub-type #4 of the KEY
Resource Record, which has been obsoleted by RFC 3445 [11].
1.1. Overview
The IPSECKEY resource record (RR) is used to publish a public key
that is to be associated with a Domain Name System (DNS) [1] name for
use with the IPsec protocol suite. This can be the public key of a
host, network, or application (in the case of per-port keying).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
Richardson Standards Track [Page 2]
RFC 4025 Storing IPsec Keying Material in DNS February 2005
1.2. Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and IP6.ARPA)
Often a security gateway will only have access to the IP address of
the node with which communication is desired and will not know any
other name for the target node. Because of this, frequently the best
way of looking up IPSECKEY RRs will be by using the IP address as an
index into one of the reverse mapping trees (IN-ADDR.ARPA for IPv4 or
IP6.ARPA for IPv6).
The lookup is done in the fashion usual for PTR records. The IP
address' octets (IPv4) or nibbles (IPv6) are reversed and looked up
with the appropriate suffix. Any CNAMEs or DNAMEs found MUST be
followed.
Note: even when the IPsec function is contained in the end-host,
often only the application will know the forward name used. Although
the case where the application knows the forward name is common, the
user could easily have typed in a literal IP address. This storage
mechanism does not preclude using the forward name when it is
available but does not require it.
1.3. Usage Criteria
An IPSECKEY resource record SHOULD be used in combination with DNSSEC
[8] unless some other means of authenticating the IPSECKEY resource
record is available.
It is expected that there will often be multiple IPSECKEY resource
records at the same name. This will be due to the presence of
multiple gateways and a need to roll over keys.
This resource record is class independent.
2. Storage Formats
2.1. IPSECKEY RDATA Format
The RDATA for an IPSECKEY RR consists of a precedence value, a
gateway type, a public key, algorithm type, and an optional gateway
address.
Richardson Standards Track [Page 3]
RFC 4025 Storing IPsec Keying Material in DNS February 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| precedence | gateway type | algorithm | gateway |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ +
~ gateway ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
2.2. RDATA Format - Precedence
This is an 8-bit precedence for this record. It is interpreted in
the same way as the PREFERENCE field described in section 3.3.9 of
RFC 1035 [2].
Gateways listed in IPSECKEY records with lower precedence are to be
attempted first. Where there is a tie in precedence, the order
should be non-deterministic.
2.3. RDATA Format - Gateway Type
The gateway type field indicates the format of the information that
is stored in the gateway field.
The following values are defined:
0 No gateway is present.
1 A 4-byte IPv4 address is present.
2 A 16-byte IPv6 address is present.
3 A wire-encoded domain name is present. The wire-encoded format is
self-describing, so the length is implicit. The domain name MUST
NOT be compressed. (See Section 3.3 of RFC 1035 [2].)
2.4. RDATA Format - Algorithm Type
The algorithm type field identifies the public key's cryptographic
algorithm and determines the format of the public key field.
A value of 0 indicates that no key is present.
The following values are defined:
1 A DSA key is present, in the format defined in RFC 2536 [9].
2 A RSA key is present, in the format defined in RFC 3110 [10].
Richardson Standards Track [Page 4]
RFC 4025 Storing IPsec Keying Material in DNS February 2005
2.5. RDATA Format - Gateway
The gateway field indicates a gateway to which an IPsec tunnel may be
created in order to reach the entity named by this resource record.
There are three formats:
A 32-bit IPv4 address is present in the gateway field. The data
portion is an IPv4 address as described in section 3.4.1 of RFC 1035
[2]. This is a 32-bit number in network byte order.
A 128-bit IPv6 address is present in the gateway field. The data
portion is an IPv6 address as described in section 2.2 of RFC 3596
[12]. This is a 128-bit number in network byte order.
The gateway field is a normal wire-encoded domain name, as described
in section 3.3 of RFC 1035 [2]. Compression MUST NOT be used.
2.6. RDATA Format - Public Keys
Both the public key types defined in this document (RSA and DSA)
inherit their public key formats from the corresponding KEY RR
formats. Specifically, the public key field contains the
algorithm-specific portion of the KEY RR RDATA, which is all the KEY
RR DATA after the first four octets. This is the same portion of the
KEY RR that must be specified by documents that define a DNSSEC
algorithm. Those documents also specify a message digest to be used
for generation of SIG RRs; that specification is not relevant for
IPSECKEY RRs.
Future algorithms, if they are to be used by both DNSSEC (in the KEY
RR) and IPSECKEY, are likely to use the same public key encodings in
both records. Unless otherwise specified, the IPSECKEY public key
field will contain the algorithm-specific portion of the KEY RR RDATA
for the corresponding algorithm. The algorithm must still be
designated for use by IPSECKEY, and an IPSECKEY algorithm type number
(which might be different from the DNSSEC algorithm number) must be
assigned to it.
The DSA key format is defined in RFC 2536 [9]
The RSA key format is defined in RFC 3110 [10], with the following
changes:
The earlier definition of RSA/MD5 in RFC 2065 [4] limited the
exponent and modulus to 2552 bits in length. RFC 3110 extended that
limit to 4096 bits for RSA/SHA1 keys. The IPSECKEY RR imposes no
length limit on RSA public keys, other than the 65535 octet limit
Richardson Standards Track [Page 5]
RFC 4025 Storing IPsec Keying Material in DNS February 2005
imposed by the two-octet length encoding. This length extension is
applicable only to IPSECKEY; it is not applicable to KEY RRs.
3. Presentation Formats
3.1. Representation of IPSECKEY RRs
IPSECKEY RRs may appear in a zone data master file. The precedence,
gateway type, algorithm, and gateway fields are REQUIRED. The base64
encoded public key block is OPTIONAL; if it is not present, the
public key field of the resource record MUST be construed to be zero
octets in length.
The algorithm field is an unsigned integer. No mnemonics are
defined.
If no gateway is to be indicated, then the gateway type field MUST be
zero, and the gateway field MUST be "."
The Public Key field is represented as a Base64 encoding of the
Public Key. Whitespace is allowed within the Base64 text. For a
definition of Base64 encoding, see RFC 3548 [6], Section 5.2.
The general presentation for the record is as follows:
IN IPSECKEY ( precedence gateway-type algorithm
gateway base64-encoded-public-key )
3.2. Examples
An example of a node, 192.0.2.38, that will accept IPsec tunnels on
its own behalf.
38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2
192.0.2.38
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
An example of a node, 192.0.2.38, that has published its key only.
38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2
.
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
Richardson Standards Track [Page 6]
RFC 4025 Storing IPsec Keying Material in DNS February 2005
An example of a node, 192.0.2.38, that has delegated authority to the
node 192.0.2.3.
38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2
192.0.2.3
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
An example of a node, 192.0.1.38 that has delegated authority to the
node with the identity "mygateway.example.com".
38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2
mygateway.example.com.
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0, that has
delegated authority to the node 2001:0DB8:c000:0200:2::1
$ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa.
0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2
2001:0DB8:0:8002::2000:1
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
4. Security Considerations
This entire memo pertains to the provision of public keying material
for use by key management protocols such as ISAKMP/IKE (RFC 2407)
[7].
The IPSECKEY resource record contains information that SHOULD be
communicated to the end client in an integral fashion; i.e., free
from modification. The form of this channel is up to the consumer of
the data; there must be a trust relationship between the end consumer
of this resource record and the server. This relationship may be
end-to-end DNSSEC validation, a TSIG or SIG(0) channel to another
secure source, a secure local channel on the host, or some
combination of the above.
The keying material provided by the IPSECKEY resource record is not
sensitive to passive attacks. The keying material may be freely
disclosed to any party without any impact on the security properties
of the resulting IPsec session. IPsec and IKE provide defense
against both active and passive attacks.
Any derivative specification that makes use of this resource record
MUST carefully document its trust model and why the trust model of
DNSSEC is appropriate, if that is the secure channel used.
Richardson Standards Track [Page 7]
RFC 4025 Storing IPsec Keying Material in DNS February 2005
An active attack on the DNS that caused the wrong IP address to be
retrieved (via forged address), and therefore the wrong QNAME to be
queried, would also result in a man-in-the-middle attack. This
situation is independent of whether the IPSECKEY RR is used.
4.1. Active Attacks Against Unsecured IPSECKEY Resource Records
This section deals with active attacks against the DNS. These
attacks require that DNS requests and responses be intercepted and
changed. DNSSEC is designed to defend against attacks of this kind.
This section deals with the situation in which DNSSEC is not
available. This is not the recommended deployment scenario.
4.1.1. Active Attacks Against IPSECKEY Keying Materials
The first kind of active attack is when the attacker replaces the
keying material with either a key under its control or with garbage.
The gateway field is either untouched or is null. The IKE
negotiation will therefore occur with the original end-system. For
this attack to succeed, the attacker must perform a man-in-the-middle
attack on the IKE negotiation. This attack requires that the
attacker be able to intercept and modify packets on the forwarding
path for the IKE and data packets.
If the attacker is not able to perform this man-in-the-middle attack
on the IKE negotiation, then a denial of service will result, as the
IKE negotiation will fail.
If the attacker is not only able to mount active attacks against DNS
but also in a position to perform a man-in-the-middle attack on IKE
and IPsec negotiations, then the attacker will be able to compromise
the resulting IPsec channel. Note that an attacker must be able to
perform active DNS attacks on both sides of the IKE negotiation for
this to succeed.
4.1.2. Active Attacks Against IPSECKEY Gateway Material
The second kind of active attack is one in which the attacker
replaces the gateway address to point to a node under the attacker's
control. The attacker then either replaces the public key or removes
it. If the public key were removed, then the attacker could provide
an accurate public key of its own in a second record.
This second form creates a simple man-in-the-middle attacks since the
attacker can then create a second tunnel to the real destination.
Note that, as before, this requires that the attacker also mount an
active attack against the responder.
Richardson Standards Track [Page 8]
RFC 4025 Storing IPsec Keying Material in DNS February 2005
Note that the man-in-the-middle cannot just forward cleartext packets
to the original destination. While the destination may be willing to
speak in the clear, replying to the original sender, the sender will
already have created a policy expecting ciphertext. Thus, the
attacker will need to intercept traffic in both directions. In some
cases, the attacker may be able to accomplish the full intercept by
use of Network Address/Port Translation (NAT/NAPT) technology.
This attack is easier than the first one because the attacker does
NOT need to be on the end-to-end forwarding path. The attacker need
only be able to modify DNS replies. This can be done by packet
modification, by various kinds of race attacks, or through methods
that pollute DNS caches.
If the end-to-end integrity of the IPSECKEY RR is suspect, the end
client MUST restrict its use of the IPSECKEY RR to cases where the RR
owner name matches the content of the gateway field. As the RR owner
name is assumed when the gateway field is null, a null gateway field
is considered a match.
Thus, any records obtained under unverified conditions (e.g., no
DNSSEC or trusted path to source) that have a non-null gateway field
MUST be ignored.
This restriction eliminates attacks against the gateway field, which
are considered much easier, as the attack does not need to be on the
forwarding path.
In the case of an IPSECKEY RR with a value of three in its gateway
type field, the gateway field contains a domain name. The subsequent
query required to translate that name into an IP address or IPSECKEY
RR will also be subject to man-in-the-middle attacks. If the
end-to-end integrity of this second query is suspect, then the
provisions above also apply. The IPSECKEY RR MUST be ignored
whenever the resulting gateway does not match the QNAME of the
original IPSECKEY RR query.
5. IANA Considerations
This document updates the IANA Registry for DNS Resource Record Types
by assigning type 45 to the IPSECKEY record.
This document creates two new IANA registries, both specific to the
IPSECKEY Resource Record:
This document creates an IANA registry for the algorithm type field.
Richardson Standards Track [Page 9]
RFC 4025 Storing IPsec Keying Material in DNS February 2005
Values 0, 1, and 2 are defined in Section 2.4. Algorithm numbers 3
through 255 can be assigned by IETF Consensus (see RFC 2434 [5]).
This document creates an IANA registry for the gateway type field.
Values 0, 1, 2, and 3 are defined in Section 2.3. Gateway type
numbers 4 through 255 can be assigned by Standards Action (see RFC
2434 [5]).
6. Acknowledgements
My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob
Austein, and Olafur Gudmundsson, who reviewed this document
carefully. Additional thanks to Olafur Gurmundsson for a reference
implementation.
7. References
7.1. Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Eastlake 3rd, D. and C. Kaufman, "Domain Name System Security
Extensions", RFC 2065, January 1997.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003.
7.2. Informative References
[7] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998.
[8] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[9] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
Richardson Standards Track [Page 10]
RFC 4025 Storing IPsec Keying Material in DNS February 2005
[10] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
Name System (DNS)", RFC 3110, May 2001.
[11] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
Record (RR)", RFC 3445, December 2002.
[12] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
Extensions to Support IP Version 6", RFC 3596, October 2003.
Author's Address
Michael C. Richardson
Sandelman Software Works
470 Dawson Avenue
Ottawa, ON K1Z 5V7
CA
EMail: mcr@sandelman.ottawa.on.ca
URI: http://www.sandelman.ottawa.on.ca/
Richardson Standards Track [Page 11]
RFC 4025 Storing IPsec Keying Material in DNS February 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 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 IETF's procedures with respect to rights in IETF 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Richardson Standards Track [Page 12]

1179
contrib/bind9/doc/rfc/rfc4033.txt Normal file
View File

File diff suppressed because it is too large Load Diff

1627
contrib/bind9/doc/rfc/rfc4034.txt Normal file
View File

File diff suppressed because it is too large Load Diff

2971
contrib/bind9/doc/rfc/rfc4035.txt Normal file
View File

File diff suppressed because it is too large Load Diff

339
contrib/bind9/doc/rfc/rfc4074.txt Normal file
View File

@ -0,0 +1,339 @@
Network Working Group Y. Morishita
Request for Comments: 4074 JPRS
Category: Informational T. Jinmei
Toshiba
May 2005
Common Misbehavior Against DNS Queries for IPv6 Addresses
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
There is some known misbehavior of DNS authoritative servers when
they are queried for AAAA resource records. Such behavior can block
IPv4 communication that should actually be available, cause a
significant delay in name resolution, or even make a denial of
service attack. This memo describes details of known cases and
discusses their effects.
1. Introduction
Many existing DNS clients (resolvers) that support IPv6 first search
for AAAA Resource Records (RRs) of a target host name, and then for A
RRs of the same name. This fallback mechanism is based on the DNS
specifications, which if not obeyed by authoritative servers, can
produce unpleasant results. In some cases, for example, a web
browser fails to connect to a web server it could otherwise reach.
In the following sections, this memo describes some typical cases of
such misbehavior and its (bad) effects.
Note that the misbehavior is not specific to AAAA RRs. In fact, all
known examples also apply to the cases of queries for MX, NS, and SOA
RRs. The authors believe this can be generalized for all types of
queries other than those for A RRs. In this memo, however, we
concentrate on the case for AAAA queries, since the problem is
particularly severe for resolvers that support IPv6, which thus
affects many end users. Resolvers at end users normally send A
and/or AAAA queries only, so the problem for the other cases is
relatively minor.
Morishita & Jinmei Informational [Page 1]
RFC 4074 Common Misbehavior Against DNS Queries May 2005
2. Network Model
In this memo, we assume a typical network model of name resolution
environment using DNS. It consists of three components: stub
resolvers, caching servers, and authoritative servers. A stub
resolver issues a recursive query to a caching server, which then
handles the entire name resolution procedure recursively. The
caching server caches the result of the query and sends the result to
the stub resolver. The authoritative servers respond to queries for
names for which they have the authority, normally in a non-recursive
manner.
3. Expected Behavior
Suppose that an authoritative server has an A RR but has no AAAA RR
for a host name. Then, the server should return a response to a
query for an AAAA RR of the name with the response code (RCODE) being
0 (indicating no error) and with an empty answer section (see
Sections 4.3.2 and 6.2.4 of [1]). Such a response indicates that
there is at least one RR of a different type than AAAA for the
queried name, and the stub resolver can then look for A RRs.
This way, the caching server can cache the fact that the queried name
has no AAAA RR (but may have other types of RRs), and thus improve
the response time to further queries for an AAAA RR of the name.
4. Problematic Behaviors
There are some known cases at authoritative servers that do not
conform to the expected behavior. This section describes those
problematic cases.
4.1. Ignore Queries for AAAA
Some authoritative servers seem to ignore queries for an AAAA RR,
causing a delay at the stub resolver to fall back to a query for an A
RR. This behavior may cause a fatal timeout at the resolver or at
the application that calls the resolver. Even if the resolver
eventually falls back, the result can be an unacceptable delay for
the application user, especially with interactive applications like
web browsing.
4.2. Return "Name Error"
This type of server returns a response with RCODE 3 ("Name Error") to
a query for an AAAA RR, indicating that it does not have any RRs of
any type for the queried name.
Morishita & Jinmei Informational [Page 2]
RFC 4074 Common Misbehavior Against DNS Queries May 2005
With this response, the stub resolver may immediately give up and
never fall back. Even if the resolver retries with a query for an A
RR, the negative response for the name has been cached in the caching
server, and the caching server will simply return the negative
response. As a result, the stub resolver considers this to be a
fatal error in name resolution.
Several examples of this behavior are known to the authors. As of
this writing, all have been fixed.
4.3. Return Other Erroneous Codes
Other authoritative servers return a response with erroneous response
codes other than RCODE 3 ("Name Error"). One such RCODE is 4 ("Not
Implemented"), indicating that the servers do not support the
requested type of query.
These cases are less harmful than the previous one; if the stub
resolver falls back to querying for an A RR, the caching server will
process the query correctly and return an appropriate response.
However, these can still cause a serious effect. There was an
authoritative server implementation that returned RCODE 2 ("Server
failure") to queries for AAAA RRs. One widely deployed mail server
implementation with a certain type of resolver library interpreted
this result as an indication of retry and did not fall back to
queries for A RRs, causing message delivery failure.
If the caching server receives a response with these response codes,
it does not cache the fact that the queried name has no AAAA RR,
resulting in redundant queries for AAAA RRs in the future. The
behavior will waste network bandwidth and increase the load of the
authoritative server.
Using RCODE 1 ("Format error") would cause a similar effect, though
the authors have not seen such implementations yet.
4.4. Return a Broken Response
Another type of authoritative servers returns broken responses to
AAAA queries. Returning a response whose RR type is AAAA with the
length of the RDATA being 4 bytes is a known behavior of this
category. The 4-byte data looks like the IPv4 address of the queried
host name.
Morishita & Jinmei Informational [Page 3]
RFC 4074 Common Misbehavior Against DNS Queries May 2005
That is, the RR in the answer section would be described as follows:
www.bad.example. 600 IN AAAA 192.0.2.1
which is, of course, bogus (or at least meaningless).
A widely deployed caching server implementation transparently returns
the broken response (and caches it) to the stub resolver. Another
known server implementation parses the response by itself, and sends
a separate response with RCODE 2 ("Server failure").
In either case, the broken response does not affect queries for an A
RR of the same name. If the stub resolver falls back to A queries,
it will get an appropriate response.
The latter case, however, causes the same bad effect as that
described in the previous section: redundant queries for AAAA RRs.
4.5. Make Lame Delegation
Some authoritative servers respond to AAAA queries in a way that
causes lame delegation. In this case, the parent zone specifies that
the authoritative server should have the authority of a zone, but the
server should not return an authoritative response for AAAA queries
within the zone (i.e., the AA bit in the response is not set). On
the other hand, the authoritative server returns an authoritative
response for A queries.
When a caching server asks the server for AAAA RRs in the zone, it
recognizes the delegation is lame, and returns a response with RCODE
2 ("Server failure") to the stub resolver.
Furthermore, some caching servers record the authoritative server as
lame for the zone and will not use it for a certain period of time.
With this type of caching server, even if the stub resolver falls
back to querying for an A RR, the caching server will simply return a
response with RCODE 2, since all the servers are known to be "lame."
There is also an implementation that relaxes the behavior a little
bit. It tries to avoid using the lame server, but continues to try
it as a last resort. With this type of caching server, the stub
resolver will get a correct response if it falls back after Server
failure. However, this still causes redundant AAAA queries, as
explained in the previous sections.
Morishita & Jinmei Informational [Page 4]
RFC 4074 Common Misbehavior Against DNS Queries May 2005
5. Security Considerations
The CERT/CC pointed out that the response with RCODE 3 ("Name
Error"), described in Section 4.2, can be used for a denial of
service attack [2]. The same argument applies to the case of "lame
delegation", described in Section 4.5, with a certain type of caching
server.
6. Acknowledgements
Erik Nordmark encouraged the authors to publish this document as an
RFC. Akira Kato and Paul Vixie reviewed a preliminary version of
this document. Pekka Savola carefully reviewed a previous version
and provided detailed comments. Bill Fenner, Scott Hollenbeck,
Thomas Narten, and Alex Zinin reviewed and helped improve the
document at the last stage for publication.
7. Informative References
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[2] The CERT Coordination Center, "Incorrect NXDOMAIN responses from
AAAA queries could cause denial-of-service conditions",
March 2003, <http://www.kb.cert.org/vuls/id/714121>.
Authors' Addresses
MORISHITA Orange Yasuhiro
Research and Development Department, Japan Registry Services Co.,Ltd.
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Chiyoda-ku, Tokyo 101-0065
Japan
EMail: yasuhiro@jprs.co.jp
JINMEI Tatuya
Corporate Research & Development Center, Toshiba Corporation
1 Komukai Toshiba-cho, Saiwai-ku
Kawasaki-shi, Kanagawa 212-8582
Japan
EMail: jinmei@isl.rdc.toshiba.co.jp
Morishita & Jinmei Informational [Page 5]
RFC 4074 Common Misbehavior Against DNS Queries May 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Morishita & Jinmei Informational [Page 6]

171
contrib/bind9/doc/rfc/rfc4159.txt Normal file
View File

@ -0,0 +1,171 @@
Network Working Group G. Huston
Request for Comments: 4159 APNIC
BCP: 109 August 2005
Category: Best Current Practice
Deprecation of "ip6.int"
Status of This Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document advises of the deprecation of the use of "ip6.int" for
Standards Conformant IPv6 implementations.
1. IPv6 Standards Action
In August 2001 the IETF published [RFC3152], which advised that the
use of "ip6.int" as the domain for reverse-mapping of IPv6 addresses
to DNS names was deprecated. The document noted that the use of
"ip6.int" would be phased out in an orderly fashion.
As of 1 September 2005, the IETF advises the community that the DNS
domain "ip6.int" should no longer be used to perform reverse mapping
of IPv6 addresses to domain names, and that the domain "ip6.arpa"
should be used henceforth, in accordance with the IANA Considerations
described in [RFC3596]. The domain "ip6.int" is deprecated, and its
use in IPv6 implementations that conform to the IPv6 Internet
Standards is discontinued.
The Regional Internet Registries (RIRs) are advised that maintenance
of delegation of entries in "ip6.int" is no longer required as part
of infrastructure services in support of Internet Standards
Conformant IPv6 implementations as of 1 September 2005. The RIRs are
requested to work with their communities to adopt a schedule
regarding the cessation of support of registration services for the
"ip6.int" domain.
Huston Best Current Practice [Page 1]
RFC 4159 ip6.int August 2005
2. IANA Considerations
IANA is advised that the "ip6.int" domain for reverse mapping of IPv6
addresses to domain names is no longer part of Internet Standards
Conformant support of IPv6 as of 1 September 2005.
3. Security Considerations
While DNS spoofing of address to name mapping has been exploited in
IPv4, removal of the "ip6.int" zone from the standard IPv6
specification creates no new threats to the security of the internet.
4. Acknowledgements
The document was prepared with the assistance of Kurt Lindqvist,
Thomas Narten, Paul Wilson, David Kessens, Bob Hinden, Brian
Haberman, and Bill Manning.
5. Normative References
[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
August 2001.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
Extensions to Support IP Version 6", RFC 3596, October
2003.
Author's Address
Geoff Huston
APNIC
EMail: gih@apnic.net
Huston Best Current Practice [Page 2]
RFC 4159 ip6.int August 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Huston Best Current Practice [Page 3]

47
contrib/bind9/lib/bind/include/resolv_mt.h Normal file
View File

@ -0,0 +1,47 @@
#ifndef _RESOLV_MT_H
#define _RESOLV_MT_H
#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
#include <resolv.h>
/* Access functions for the libresolv private interface */
int __res_enable_mt(void);
int __res_disable_mt(void);
/* Per-thread context */
typedef struct {
int no_hosts_fallback_private;
int retry_save;
int retry_private;
char inet_nsap_ntoa_tmpbuf[255*3];
char sym_ntos_unname[20];
char sym_ntop_unname[20];
char p_option_nbuf[40];
char p_time_nbuf[40];
char precsize_ntoa_retbuf[sizeof "90000000.00"];
char loc_ntoa_tmpbuf[sizeof
"1000 60 60.000 N 1000 60 60.000 W -12345678.00m 90000000.00m 90000000.00m 90000000.00m"];
char p_secstodate_output[15];
} mtctxres_t;
/* Thread-specific data (TSD) */
mtctxres_t *___mtctxres(void);
#define mtctxres (___mtctxres())
/* Various static data that should be TSD */
#define sym_ntos_unname (mtctxres->sym_ntos_unname)
#define sym_ntop_unname (mtctxres->sym_ntop_unname)
#define inet_nsap_ntoa_tmpbuf (mtctxres->inet_nsap_ntoa_tmpbuf)
#define p_option_nbuf (mtctxres->p_option_nbuf)
#define p_time_nbuf (mtctxres->p_time_nbuf)
#define precsize_ntoa_retbuf (mtctxres->precsize_ntoa_retbuf)
#define loc_ntoa_tmpbuf (mtctxres->loc_ntoa_tmpbuf)
#define p_secstodate_output (mtctxres->p_secstodate_output)
#endif /* _RESOLV_MT_H */

128
contrib/bind9/lib/bind/resolv/mtctxres.c Normal file
View File

@ -0,0 +1,128 @@
#include <port_before.h>
#ifdef DO_PTHREADS
#include <pthread.h>
#endif
#include <errno.h>
#include <netdb.h>
#include <stdlib.h>
#include <string.h>
#include <resolv_mt.h>
#include <irs.h>
#include <port_after.h>
#ifdef DO_PTHREADS
static pthread_key_t key;
static int mt_key_initialized = 0;
static int __res_init_ctx(void);
static void __res_destroy_ctx(void *);
#if defined(sun) && !defined(__GNUC__)
#pragma init (_mtctxres_init)
#endif
#endif
static mtctxres_t sharedctx;
#ifdef DO_PTHREADS
/*
* Initialize the TSD key. By doing this at library load time, we're
* implicitly running without interference from other threads, so there's
* no need for locking.
*/
static void
_mtctxres_init(void) {
int pthread_keycreate_ret;
pthread_keycreate_ret = pthread_key_create(&key, __res_destroy_ctx);
if (pthread_keycreate_ret == 0)
mt_key_initialized = 1;
}
#endif
/*
* To support binaries that used the private MT-safe interface in
* Solaris 8, we still need to provide the __res_enable_mt()
* and __res_disable_mt() entry points. They're do-nothing routines.
*/
int
__res_enable_mt(void) {
return (-1);
}
int
__res_disable_mt(void) {
return (0);
}
#ifdef DO_PTHREADS
static int
__res_init_ctx(void) {
mtctxres_t *mt;
int ret;
if (pthread_getspecific(key) != 0) {
/* Already exists */
return (0);
}
if ((mt = malloc(sizeof (mtctxres_t))) == 0) {
errno = ENOMEM;
return (-1);
}
memset(mt, 0, sizeof (mtctxres_t));
if ((ret = pthread_setspecific(key, mt)) != 0) {
free(mt);
errno = ret;
return (-1);
}
return (0);
}
static void
__res_destroy_ctx(void *value) {
mtctxres_t *mt = (mtctxres_t *)value;
if (mt != 0)
free(mt);
}
#endif
mtctxres_t *
___mtctxres(void) {
#ifdef DO_PTHREADS
mtctxres_t *mt;
/*
* This if clause should only be executed if we are linking
* statically. When linked dynamically _mtctxres_init() should
* be called at binding time due the #pragma above.
*/
if (!mt_key_initialized) {
static pthread_mutex_t keylock = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_lock(&keylock);
_mtctxres_init();
pthread_mutex_unlock(&keylock);
}
/*
* If we have already been called in this thread return the existing
* context. Otherwise recreat a new context and return it. If
* that fails return a global context.
*/
if (mt_key_initialized) {
if (((mt = pthread_getspecific(key)) != 0) ||
(__res_init_ctx() == 0 &&
(mt = pthread_getspecific(key)) != 0)) {
return (mt);
}
}
#endif
return (&sharedctx);
}

40
contrib/bind9/lib/lwres/include/lwres/stdlib.h Normal file
View File

@ -0,0 +1,40 @@
/*
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
* REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
* AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
* INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
* LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
* OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: stdlib.h,v 1.2.4.1 2005/06/08 02:08:32 marka Exp $ */
#ifndef LWRES_STDLIB_H
#define LWRES_STDLIB_H 1
/*! \file */
#include <stdlib.h>
#include <lwres/lang.h>
#include <lwres/platform.h>
#ifdef LWRES_PLATFORM_NEEDSTRTOUL
#define strtoul lwres_strtoul
#endif
LWRES_LANG_BEGINDECLS
unsigned long lwres_strtoul(const char *, char **, int);
LWRES_LANG_ENDDECLS
#endif

135
contrib/bind9/lib/lwres/strtoul.c Normal file
View File

@ -0,0 +1,135 @@
/*
* Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
* REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
* AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
* INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
* LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
* OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
* PERFORMANCE OF THIS SOFTWARE.
*/
/*
* Copyright (c) 1990, 1993
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
/*! \file */
#if defined(LIBC_SCCS) && !defined(lint)
static char sccsid[] = "@(#)strtoul.c 8.1 (Berkeley) 6/4/93";
#endif /* LIBC_SCCS and not lint */
/* $Id: strtoul.c,v 1.2.4.1 2005/06/08 02:08:31 marka Exp $ */
#include <config.h>
#include <limits.h>
#include <ctype.h>
#include <errno.h>
#include <lwres/stdlib.h>
#define DE_CONST(konst, var) \
do { \
union { const void *k; void *v; } _u; \
_u.k = konst; \
var = _u.v; \
} while (0)
/*!
* Convert a string to an unsigned long integer.
*
* Ignores `locale' stuff. Assumes that the upper and lower case
* alphabets and digits are each contiguous.
*/
unsigned long
lwres_strtoul(const char *nptr, char **endptr, int base) {
const char *s = nptr;
unsigned long acc;
unsigned char c;
unsigned long cutoff;
int neg = 0, any, cutlim;
/*
* See strtol for comments as to the logic used.
*/
do {
c = *s++;
} while (isspace(c));
if (c == '-') {
neg = 1;
c = *s++;
} else if (c == '+')
c = *s++;
if ((base == 0 || base == 16) &&
c == '0' && (*s == 'x' || *s == 'X')) {
c = s[1];
s += 2;
base = 16;
}
if (base == 0)
base = c == '0' ? 8 : 10;
cutoff = (unsigned long)ULONG_MAX / (unsigned long)base;
cutlim = (unsigned long)ULONG_MAX % (unsigned long)base;
for (acc = 0, any = 0;; c = *s++) {
if (!isascii(c))
break;
if (isdigit(c))
c -= '0';
else if (isalpha(c))
c -= isupper(c) ? 'A' - 10 : 'a' - 10;
else
break;
if (c >= base)
break;
if (any < 0 || acc > cutoff || (acc == cutoff && c > cutlim))
any = -1;
else {
any = 1;
acc *= base;
acc += c;
}
}
if (any < 0) {
acc = ULONG_MAX;
errno = ERANGE;
} else if (neg)
acc = -acc;
if (endptr != 0)
DE_CONST(any ? s - 1 : nptr, *endptr);
return (acc);
}

51
contrib/ipfilter/lib/printproto.c Normal file
View File

@ -0,0 +1,51 @@
/*
* Copyright (C) 1993-2005 by Darren Reed.
*
* See the IPFILTER.LICENCE file for details on licencing.
*/
#include "ipf.h"
#if !defined(lint)
static const char rcsid[] = "@(#)$Id: printproto.c,v 1.1.2.1 2005/06/12 07:21:53 darrenr Exp $";
#endif
void printproto(pr, p, np)
struct protoent *pr;
int p;
ipnat_t *np;
{
if (np != NULL) {
if ((np->in_flags & IPN_TCPUDP) == IPN_TCPUDP)
printf("tcp/udp");
else if (np->in_flags & IPN_TCP)
printf("tcp");
else if (np->in_flags & IPN_UDP)
printf("udp");
else if (np->in_flags & IPN_ICMPQUERY)
printf("icmp");
#ifdef _AIX51
/*
* To make up for "ip = 252" and "hopopt = 0" in /etc/protocols
*/
else if (np->in_p == 0)
printf("ip");
#endif
else if (pr != NULL)
printf("%s", pr->p_name);
else
printf("%d", np->in_p);
} else {
#ifdef _AIX51
if (p == 0)
printf("ip");
else
#endif
if (pr != NULL)
printf("%s", pr->p_name);
else
printf("%d", p);
}
}

425
lib/libc/stdio/xprintf_float.c Normal file
View File

@ -0,0 +1,425 @@
/*-
* Copyright (c) 2005 Poul-Henning Kamp
* Copyright (c) 1990, 1993
* The Regents of the University of California. All rights reserved.
*
* This code is derived from software contributed to Berkeley by
* Chris Torek.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $FreeBSD$
*/
#include <namespace.h>
#include <stdio.h>
#include <wchar.h>
#include <assert.h>
#include <locale.h>
#include <limits.h>
#define dtoa __dtoa
#define freedtoa __freedtoa
#include <float.h>
#include <math.h>
#include "gdtoa.h"
#include "floatio.h"
#include "printf.h"
#include <un-namespace.h>
/*
* The size of the buffer we use as scratch space for integer
* conversions, among other things. Technically, we would need the
* most space for base 10 conversions with thousands' grouping
* characters between each pair of digits. 100 bytes is a
* conservative overestimate even for a 128-bit uintmax_t.
*/
#define BUF 100
#define DEFPREC 6 /* Default FP precision */
/* various globals ---------------------------------------------------*/
/* padding function---------------------------------------------------*/
#define PRINTANDPAD(p, ep, len, with) do { \
n2 = (ep) - (p); \
if (n2 > (len)) \
n2 = (len); \
if (n2 > 0) \
ret += __printf_puts(io, (p), n2); \
ret += __printf_pad(io, (len) - (n2 > 0 ? n2 : 0), (with)); \
} while(0)
/* misc --------------------------------------------------------------*/
#define to_char(n) ((n) + '0')
static int
exponent(char *p0, int expo, int fmtch)
{
char *p, *t;
char expbuf[MAXEXPDIG];
p = p0;
*p++ = fmtch;
if (expo < 0) {
expo = -expo;
*p++ = '-';
}
else
*p++ = '+';
t = expbuf + MAXEXPDIG;
if (expo > 9) {
do {
*--t = to_char(expo % 10);
} while ((expo /= 10) > 9);
*--t = to_char(expo);
for (; t < expbuf + MAXEXPDIG; *p++ = *t++)
;
}
else {
/*
* Exponents for decimal floating point conversions
* (%[eEgG]) must be at least two characters long,
* whereas exponents for hexadecimal conversions can
* be only one character long.
*/
if (fmtch == 'e' || fmtch == 'E')
*p++ = '0';
*p++ = to_char(expo);
}
return (p - p0);
}
/* 'f' ---------------------------------------------------------------*/
int
__printf_arginfo_float(const struct printf_info *pi, size_t n, int *argt)
{
assert (n > 0);
argt[0] = PA_DOUBLE;
if (pi->is_long_double)
argt[0] |= PA_FLAG_LONG_DOUBLE;
return (1);
}
/*
* We can decompose the printed representation of floating
* point numbers into several parts, some of which may be empty:
*
* [+|-| ] [0x|0X] MMM . NNN [e|E|p|P] [+|-] ZZ
* A B ---C--- D E F
*
* A: 'sign' holds this value if present; '\0' otherwise
* B: ox[1] holds the 'x' or 'X'; '\0' if not hexadecimal
* C: cp points to the string MMMNNN. Leading and trailing
* zeros are not in the string and must be added.
* D: expchar holds this character; '\0' if no exponent, e.g. %f
* F: at least two digits for decimal, at least one digit for hex
*/
int
__printf_render_float(struct __printf_io *io, const struct printf_info *pi, const void *const *arg)
{
int prec; /* precision from format; <0 for N/A */
char *dtoaresult; /* buffer allocated by dtoa */
char expchar; /* exponent character: [eEpP\0] */
char *cp;
int expt; /* integer value of exponent */
int signflag; /* true if float is negative */
char *dtoaend; /* pointer to end of converted digits */
char sign; /* sign prefix (' ', '+', '-', or \0) */
int size; /* size of converted field or string */
int ndig; /* actual number of digits returned by dtoa */
int expsize; /* character count for expstr */
char expstr[MAXEXPDIG+2]; /* buffer for exponent string: e+ZZZ */
int nseps; /* number of group separators with ' */
int nrepeats; /* number of repeats of the last group */
const char *grouping; /* locale specific numeric grouping rules */
int lead; /* sig figs before decimal or group sep */
long double ld;
double d;
int realsz; /* field size expanded by dprec, sign, etc */
int dprec; /* a copy of prec if [diouxX], 0 otherwise */
char ox[2]; /* space for 0x; ox[1] is either x, X, or \0 */
int prsize; /* max size of printed field */
int ret; /* return value accumulator */
char *decimal_point; /* locale specific decimal point */
int n2; /* XXX: for PRINTANDPAD */
char thousands_sep; /* locale specific thousands separator */
char buf[BUF]; /* buffer with space for digits of uintmax_t */
const char *xdigs;
int flag;
prec = pi->prec;
ox[1] = '\0';
sign = pi->showsign;
flag = 0;
ret = 0;
thousands_sep = *(localeconv()->thousands_sep);
grouping = NULL;
if (pi->alt)
grouping = localeconv()->grouping;
decimal_point = localeconv()->decimal_point;
dprec = -1;
switch(pi->spec) {
case 'a':
case 'A':
if (pi->spec == 'a') {
ox[1] = 'x';
xdigs = __lowercase_hex;
expchar = 'p';
} else {
ox[1] = 'X';
xdigs = __uppercase_hex;
expchar = 'P';
}
if (prec >= 0)
prec++;
if (pi->is_long_double) {
ld = *((long double *)arg[0]);
dtoaresult = cp =
__hldtoa(ld, xdigs, prec,
&expt, &signflag, &dtoaend);
} else {
d = *((double *)arg[0]);
dtoaresult = cp =
__hdtoa(d, xdigs, prec,
&expt, &signflag, &dtoaend);
}
if (prec < 0)
prec = dtoaend - cp;
if (expt == INT_MAX)
ox[1] = '\0';
goto fp_common;
case 'e':
case 'E':
expchar = pi->spec;
if (prec < 0) /* account for digit before decpt */
prec = DEFPREC + 1;
else
prec++;
break;
case 'f':
case 'F':
expchar = '\0';
break;
case 'g':
case 'G':
expchar = pi->spec - ('g' - 'e');
if (prec == 0)
prec = 1;
break;
default:
assert(pi->spec == 'f');
}
if (prec < 0)
prec = DEFPREC;
if (pi->is_long_double) {
ld = *((long double *)arg[0]);
dtoaresult = cp =
__ldtoa(&ld, expchar ? 2 : 3, prec,
&expt, &signflag, &dtoaend);
} else {
d = *((double *)arg[0]);
dtoaresult = cp =
dtoa(d, expchar ? 2 : 3, prec,
&expt, &signflag, &dtoaend);
if (expt == 9999)
expt = INT_MAX;
}
fp_common:
if (signflag)
sign = '-';
if (expt == INT_MAX) { /* inf or nan */
if (*cp == 'N') {
cp = (pi->spec >= 'a') ? "nan" : "NAN";
sign = '\0';
} else
cp = (pi->spec >= 'a') ? "inf" : "INF";
size = 3;
flag = 1;
goto here;
}
ndig = dtoaend - cp;
if (pi->spec == 'g' || pi->spec == 'G') {
if (expt > -4 && expt <= prec) {
/* Make %[gG] smell like %[fF] */
expchar = '\0';
if (pi->alt)
prec -= expt;
else
prec = ndig - expt;
if (prec < 0)
prec = 0;
} else {
/*
* Make %[gG] smell like %[eE], but
* trim trailing zeroes if no # flag.
*/
if (!pi->alt)
prec = ndig;
}
}
if (expchar) {
expsize = exponent(expstr, expt - 1, expchar);
size = expsize + prec;
if (prec > 1 || pi->alt)
++size;
} else {
/* space for digits before decimal point */
if (expt > 0)
size = expt;
else /* "0" */
size = 1;
/* space for decimal pt and following digits */
if (prec || pi->alt)
size += prec + 1;
if (grouping && expt > 0) {
/* space for thousands' grouping */
nseps = nrepeats = 0;
lead = expt;
while (*grouping != CHAR_MAX) {
if (lead <= *grouping)
break;
lead -= *grouping;
if (*(grouping+1)) {
nseps++;
grouping++;
} else
nrepeats++;
}
size += nseps + nrepeats;
} else
lead = expt;
}
here:
/*
* All reasonable formats wind up here. At this point, `cp'
* points to a string which (if not flags&LADJUST) should be
* padded out to `width' places. If flags&ZEROPAD, it should
* first be prefixed by any sign or other prefix; otherwise,
* it should be blank padded before the prefix is emitted.
* After any left-hand padding and prefixing, emit zeroes
* required by a decimal [diouxX] precision, then print the
* string proper, then emit zeroes required by any leftover
* floating precision; finally, if LADJUST, pad with blanks.
*
* Compute actual size, so we know how much to pad.
* size excludes decimal prec; realsz includes it.
*/
realsz = dprec > size ? dprec : size;
if (sign)
realsz++;
if (ox[1])
realsz += 2;
prsize = pi->width > realsz ? pi->width : realsz;
/* right-adjusting blank padding */
if (pi->pad != '0' && pi->left == 0)
ret += __printf_pad(io, pi->width - realsz, 0);
/* prefix */
if (sign)
ret += __printf_puts(io, &sign, 1);
if (ox[1]) { /* ox[1] is either x, X, or \0 */
ox[0] = '0';
ret += __printf_puts(io, ox, 2);
}
/* right-adjusting zero padding */
if (pi->pad == '0' && pi->left == 0)
ret += __printf_pad(io, pi->width - realsz, 1);
/* leading zeroes from decimal precision */
ret += __printf_pad(io, dprec - size, 1);
if (flag)
ret += __printf_puts(io, cp, size);
else {
/* glue together f_p fragments */
if (!expchar) { /* %[fF] or sufficiently short %[gG] */
if (expt <= 0) {
ret += __printf_puts(io, "0", 1);
if (prec || pi->alt)
ret += __printf_puts(io, decimal_point, 1);
ret += __printf_pad(io, -expt, 1);
/* already handled initial 0's */
prec += expt;
} else {
PRINTANDPAD(cp, dtoaend, lead, 1);
cp += lead;
if (grouping) {
while (nseps>0 || nrepeats>0) {
if (nrepeats > 0)
nrepeats--;
else {
grouping--;
nseps--;
}
ret += __printf_puts(io, &thousands_sep, 1);
PRINTANDPAD(cp,dtoaend,
*grouping, 1);
cp += *grouping;
}
if (cp > dtoaend)
cp = dtoaend;
}
if (prec || pi->alt)
ret += __printf_puts(io, decimal_point,1);
}
PRINTANDPAD(cp, dtoaend, prec, 1);
} else { /* %[eE] or sufficiently long %[gG] */
if (prec > 1 || pi->alt) {
buf[0] = *cp++;
buf[1] = *decimal_point;
ret += __printf_puts(io, buf, 2);
ret += __printf_puts(io, cp, ndig-1);
ret += __printf_pad(io, prec - ndig, 1);
} else /* XeYYY */
ret += __printf_puts(io, cp, 1);
ret += __printf_puts(io, expstr, expsize);
}
}
/* left-adjusting padding (always blank) */
if (pi->left)
ret += __printf_pad(io, pi->width - realsz, 0);
__printf_flush(io);
if (dtoaresult != NULL)
freedtoa(dtoaresult);
return (ret);
}

97
lib/libc/stdio/xprintf_hexdump.c Normal file
View File

@ -0,0 +1,97 @@
/*-
* Copyright (c) 2005 Poul-Henning Kamp
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $FreeBSD$
*/
#include <namespace.h>
#include <stdio.h>
#include <wchar.h>
#include <stdint.h>
#include <assert.h>
#include <sys/time.h>
#include "printf.h"
int
__printf_arginfo_hexdump(const struct printf_info *pi, size_t n, int *argt)
{
assert(n >= 2);
argt[0] = PA_POINTER;
argt[1] = PA_INT;
return (2);
}
int
__printf_render_hexdump(struct __printf_io *io, const struct printf_info *pi, const void *const *arg)
{
unsigned char *p;
unsigned u, l, j, a;
char buf[100], *q;
int ret;
if (pi->width > 0 && pi->width < 16)
l = pi->width;
else
l = 16;
p = *((unsigned char **)arg[0]);
u = *((unsigned *)arg[1]);
ret = 0;
a = 0;
while (u > 0) {
q = buf;
if (pi->showsign)
q += sprintf(q, " %04x", a);
for (j = 0; j < l && j < u; j++)
q += sprintf(q, " %02x", p[j]);
if (pi->alt) {
for (; j < l; j++)
q += sprintf(q, " ");
q += sprintf(q, " |");
for (j = 0; j < l && j < u; j++) {
if (p[j] < ' ' || p[j] > '~')
*q++ = '.';
else
*q++ = p[j];
}
for (; j < l; j++)
*q++ = ' ';
*q++ = '|';
}
if (l < u)
j = l;
else
j = u;
p += j;
u -= j;
a += j;
if (u > 0)
*q++ = '\n';
ret += __printf_puts(io, buf + 1, q - (buf + 1));
__printf_flush(io);
}
return (ret);
}

471
lib/libc/stdio/xprintf_int.c Normal file
View File

@ -0,0 +1,471 @@
/*-
* Copyright (c) 2005 Poul-Henning Kamp
* Copyright (c) 1990, 1993
* The Regents of the University of California. All rights reserved.
*
* This code is derived from software contributed to Berkeley by
* Chris Torek.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $FreeBSD$
*/
#include <namespace.h>
#include <err.h>
#include <sys/types.h>
#include <stddef.h>
#include <stdlib.h>
#include <stdio.h>
#include <limits.h>
#include <locale.h>
#include <stdint.h>
#include <assert.h>
#include <namespace.h>
#include <string.h>
#include <wchar.h>
#include <un-namespace.h>
#include "printf.h"
/* private stuff -----------------------------------------------------*/
union arg {
int intarg;
u_int uintarg;
long longarg;
u_long ulongarg;
intmax_t intmaxarg;
uintmax_t uintmaxarg;
};
/*
* Macros for converting digits to letters and vice versa
*/
#define to_char(n) ((n) + '0')
/* various globals ---------------------------------------------------*/
/*
* The size of the buffer we use for integer conversions.
* Technically, we would need the most space for base 10
* conversions with thousands' grouping characters between
* each pair of digits: 60 digits for 128 bit intmax_t.
* Use a bit more for better alignment of stuff.
*/
#define BUF 64
/* misc --------------------------------------------------------------*/
/*
* Convert an unsigned long to ASCII for printf purposes, returning
* a pointer to the first character of the string representation.
* Octal numbers can be forced to have a leading zero; hex numbers
* use the given digits.
*/
static char *
__ultoa(u_long val, char *endp, int base, const char *xdigs,
int needgrp, char thousep, const char *grp)
{
char *cp = endp;
long sval;
int ndig;
/*
* Handle the three cases separately, in the hope of getting
* better/faster code.
*/
switch (base) {
case 10:
if (val < 10) { /* many numbers are 1 digit */
*--cp = to_char(val);
return (cp);
}
ndig = 0;
/*
* On many machines, unsigned arithmetic is harder than
* signed arithmetic, so we do at most one unsigned mod and
* divide; this is sufficient to reduce the range of
* the incoming value to where signed arithmetic works.
*/
if (val > LONG_MAX) {
*--cp = to_char(val % 10);
ndig++;
sval = val / 10;
} else
sval = val;
do {
*--cp = to_char(sval % 10);
ndig++;
/*
* If (*grp == CHAR_MAX) then no more grouping
* should be performed.
*/
if (needgrp && ndig == *grp && *grp != CHAR_MAX
&& sval > 9) {
*--cp = thousep;
ndig = 0;
/*
* If (*(grp+1) == '\0') then we have to
* use *grp character (last grouping rule)
* for all next cases
*/
if (*(grp+1) != '\0')
grp++;
}
sval /= 10;
} while (sval != 0);
break;
case 8:
do {
*--cp = to_char(val & 7);
val >>= 3;
} while (val);
break;
case 16:
do {
*--cp = xdigs[val & 15];
val >>= 4;
} while (val);
break;
default: /* oops */
assert(base == 16);
}
return (cp);
}
/* Identical to __ultoa, but for intmax_t. */
static char *
__ujtoa(uintmax_t val, char *endp, int base, const char *xdigs,
int needgrp, char thousep, const char *grp)
{
char *cp = endp;
intmax_t sval;
int ndig;
switch (base) {
case 10:
if (val < 10) {
*--cp = to_char(val % 10);
return (cp);
}
ndig = 0;
if (val > INTMAX_MAX) {
*--cp = to_char(val % 10);
ndig++;
sval = val / 10;
} else
sval = val;
do {
*--cp = to_char(sval % 10);
ndig++;
/*
* If (*grp == CHAR_MAX) then no more grouping
* should be performed.
*/
if (needgrp && *grp != CHAR_MAX && ndig == *grp
&& sval > 9) {
*--cp = thousep;
ndig = 0;
/*
* If (*(grp+1) == '\0') then we have to
* use *grp character (last grouping rule)
* for all next cases
*/
if (*(grp+1) != '\0')
grp++;
}
sval /= 10;
} while (sval != 0);
break;
case 8:
do {
*--cp = to_char(val & 7);
val >>= 3;
} while (val);
break;
case 16:
do {
*--cp = xdigs[val & 15];
val >>= 4;
} while (val);
break;
default:
abort();
}
return (cp);
}
/* 'd' ---------------------------------------------------------------*/
int
__printf_arginfo_int(const struct printf_info *pi, size_t n, int *argt)
{
assert (n > 0);
argt[0] = PA_INT;
if (pi->is_ptrdiff)
argt[0] |= PA_FLAG_PTRDIFF;
else if (pi->is_size)
argt[0] |= PA_FLAG_SIZE;
else if (pi->is_long)
argt[0] |= PA_FLAG_LONG;
else if (pi->is_intmax)
argt[0] |= PA_FLAG_INTMAX;
else if (pi->is_quad)
argt[0] |= PA_FLAG_QUAD;
else if (pi->is_long_double)
argt[0] |= PA_FLAG_LONG_LONG;
else if (pi->is_short)
argt[0] |= PA_FLAG_SHORT;
else if (pi->is_char)
argt[0] = PA_CHAR;
return (1);
}
int
__printf_render_int(struct __printf_io *io, const struct printf_info *pi, const void *const *arg)
{
const union arg *argp;
char buf[BUF];
char *p, *pe;
char ns, l;
int rdx, sign, zext, ngrp;
const char *nalt, *digit;
char thousands_sep; /* locale specific thousands separator */
const char *grouping; /* locale specific numeric grouping rules */
uintmax_t uu;
int ret;
ret = 0;
nalt = NULL;
digit = __lowercase_hex;
ns = '\0';
pe = buf + sizeof buf - 1;
if (pi->group) {
thousands_sep = *(localeconv()->thousands_sep);
grouping = localeconv()->grouping;
ngrp = 1;
} else {
thousands_sep = 0;
grouping = NULL;
ngrp = 0;
}
switch(pi->spec) {
case 'd':
case 'i':
rdx = 10;
sign = 1;
break;
case 'X':
digit = __uppercase_hex;
/*FALLTHOUGH*/
case 'x':
rdx = 16;
sign = 0;
break;
case 'u':
case 'U':
rdx = 10;
sign = 0;
break;
case 'o':
case 'O':
rdx = 8;
sign = 0;
break;
default:
fprintf(stderr, "pi->spec = '%c'\n", pi->spec);
assert(1 == 0);
}
argp = arg[0];
if (sign)
ns = pi->showsign;
if (pi->is_long_double || pi->is_quad || pi->is_intmax ||
pi->is_size || pi->is_ptrdiff) {
if (sign && argp->intmaxarg < 0) {
uu = -argp->intmaxarg;
ns = '-';
} else
uu = argp->uintmaxarg;
} else if (pi->is_long) {
if (sign && argp->longarg < 0) {
uu = (u_long)-argp->longarg;
ns = '-';
} else
uu = argp->ulongarg;
} else if (pi->is_short) {
if (sign && (short)argp->intarg < 0) {
uu = -(short)argp->intarg;
ns = '-';
} else
uu = (unsigned short)argp->uintarg;
} else if (pi->is_char) {
if (sign && (signed char)argp->intarg < 0) {
uu = -(signed char)argp->intarg;
ns = '-';
} else
uu = (unsigned char)argp->uintarg;
} else {
if (sign && argp->intarg < 0) {
uu = (unsigned)-argp->intarg;
ns = '-';
} else
uu = argp->uintarg;
}
if (uu <= ULONG_MAX)
p = __ultoa(uu, pe, rdx, digit, ngrp, thousands_sep, grouping);
else
p = __ujtoa(uu, pe, rdx, digit, ngrp, thousands_sep, grouping);
l = 0;
if (uu == 0) {
/*-
* ``The result of converting a zero value with an
* explicit precision of zero is no characters.''
* -- ANSI X3J11
*
* ``The C Standard is clear enough as is. The call
* printf("%#.0o", 0) should print 0.''
* -- Defect Report #151
*/
;
if (pi->prec == 0 && !(pi->alt && rdx == 8))
p = pe;
} else if (pi->alt) {
if (rdx == 8)
*--p = '0';
if (rdx == 16) {
if (pi->spec == 'x')
nalt = "0x";
else
nalt = "0X";
l += 2;
}
}
l += pe - p;
if (ns)
l++;
/*-
* ``... diouXx conversions ... if a precision is
* specified, the 0 flag will be ignored.''
* -- ANSI X3J11
*/
if (pi->prec > (pe - p))
zext = pi->prec - (pe - p);
else if (pi->prec != -1)
zext = 0;
else if (pi->pad == '0' && pi->width > l && !pi->left)
zext = pi->width - l;
else
zext = 0;
l += zext;
while (zext > 0 && p > buf) {
*--p = '0';
zext--;
}
if (l < BUF) {
if (ns) {
*--p = ns;
} else if (nalt != NULL) {
*--p = nalt[1];
*--p = nalt[0];
}
if (pi->width > (pe - p) && !pi->left) {
l = pi->width - (pe - p);
while (l > 0 && p > buf) {
*--p = ' ';
l--;
}
if (l)
ret += __printf_pad(io, l, 0);
}
} else {
if (!pi->left && pi->width > l)
ret += __printf_pad(io, pi->width - l, 0);
if (ns != '\0')
ret += __printf_puts(io, &ns, 1);
else if (nalt != NULL)
ret += __printf_puts(io, nalt, 2);
if (zext > 0)
ret += __printf_pad(io, zext, 1);
}
ret += __printf_puts(io, p, pe - p);
if (pi->width > ret && pi->left)
ret += __printf_pad(io, pi->width - ret, 0);
__printf_flush(io);
return (ret);
}
/* 'p' ---------------------------------------------------------------*/
int
__printf_arginfo_ptr(const struct printf_info *pi __unused, size_t n, int *argt)
{
assert (n > 0);
argt[0] = PA_POINTER;
return (1);
}
int
__printf_render_ptr(struct __printf_io *io, const struct printf_info *pi, const void *const *arg)
{
struct printf_info p2;
uintmax_t u;
const void *p;
/*-
* ``The argument shall be a pointer to void. The
* value of the pointer is converted to a sequence
* of printable characters, in an implementation-
* defined manner.''
* -- ANSI X3J11
*/
u = (uintmax_t)(uintptr_t) *((void **)arg[0]);
p2 = *pi;
p2.spec = 'x';
p2.alt = 1;
p2.is_long_double = 1;
p = &u;
return (__printf_render_int(io, &p2, &p));
}

187
lib/libc/stdio/xprintf_str.c Normal file
View File

@ -0,0 +1,187 @@
/*-
* Copyright (c) 2005 Poul-Henning Kamp
* Copyright (c) 1990, 1993
* The Regents of the University of California. All rights reserved.
*
* This code is derived from software contributed to Berkeley by
* Chris Torek.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $FreeBSD$
*/
#include <namespace.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <limits.h>
#include <stdint.h>
#include <assert.h>
#include <wchar.h>
#include "printf.h"
/*
* Convert a wide character string argument for the %ls format to a multibyte
* string representation. If not -1, prec specifies the maximum number of
* bytes to output, and also means that we can't assume that the wide char.
* string ends is null-terminated.
*/
static char *
__wcsconv(wchar_t *wcsarg, int prec)
{
static const mbstate_t initial;
mbstate_t mbs;
char buf[MB_LEN_MAX];
wchar_t *p;
char *convbuf;
size_t clen, nbytes;
/* Allocate space for the maximum number of bytes we could output. */
if (prec < 0) {
p = wcsarg;
mbs = initial;
nbytes = wcsrtombs(NULL, (const wchar_t **)&p, 0, &mbs);
if (nbytes == (size_t)-1)
return (NULL);
} else {
/*
* Optimisation: if the output precision is small enough,
* just allocate enough memory for the maximum instead of
* scanning the string.
*/
if (prec < 128)
nbytes = prec;
else {
nbytes = 0;
p = wcsarg;
mbs = initial;
for (;;) {
clen = wcrtomb(buf, *p++, &mbs);
if (clen == 0 || clen == (size_t)-1 ||
(int)(nbytes + clen) > prec)
break;
nbytes += clen;
}
}
}
if ((convbuf = malloc(nbytes + 1)) == NULL)
return (NULL);
/* Fill the output buffer. */
p = wcsarg;
mbs = initial;
if ((nbytes = wcsrtombs(convbuf, (const wchar_t **)&p,
nbytes, &mbs)) == (size_t)-1) {
free(convbuf);
return (NULL);
}
convbuf[nbytes] = '\0';
return (convbuf);
}
/* 's' ---------------------------------------------------------------*/
int
__printf_arginfo_str(const struct printf_info *pi, size_t n, int *argt)
{
assert (n > 0);
if (pi->is_long || pi->spec == 'C')
argt[0] = PA_WSTRING;
else
argt[0] = PA_STRING;
return (1);
}
int
__printf_render_str(struct __printf_io *io, const struct printf_info *pi, const void *const *arg)
{
const char *p;
wchar_t *wcp;
char *convbuf;
int l;
if (pi->is_long || pi->spec == 'S') {
wcp = *((wint_t **)arg[0]);
if (wcp == NULL)
return (__printf_out(io, pi, "(null)", 6));
convbuf = __wcsconv(wcp, pi->prec);
if (convbuf == NULL)
return (-1);
l = __printf_out(io, pi, convbuf, strlen(convbuf));
free(convbuf);
return (l);
}
p = *((char **)arg[0]);
if (p == NULL)
return (__printf_out(io, pi, "(null)", 6));
l = strlen(p);
if (pi->prec >= 0 && pi->prec < l)
l = pi->prec;
return (__printf_out(io, pi, p, l));
}
/* 'c' ---------------------------------------------------------------*/
int
__printf_arginfo_chr(const struct printf_info *pi, size_t n, int *argt)
{
assert (n > 0);
if (pi->is_long || pi->spec == 'C')
argt[0] = PA_WCHAR;
else
argt[0] = PA_INT;
return (1);
}
int
__printf_render_chr(struct __printf_io *io, const struct printf_info *pi, const void *const *arg)
{
int i;
wint_t ii;
unsigned char c;
static const mbstate_t initial; /* XXX: this is bogus! */
mbstate_t mbs;
size_t mbseqlen;
char buf[MB_CUR_MAX];
if (pi->is_long || pi->spec == 'C') {
ii = *((wint_t *)arg[0]);
mbs = initial;
mbseqlen = wcrtomb(buf, (wchar_t)ii, &mbs);
if (mbseqlen == (size_t) -1)
return (-1);
return (__printf_out(io, pi, buf, mbseqlen));
}
i = *((int *)arg[0]);
c = i;
i = __printf_out(io, pi, &c, 1);
__printf_flush(io);
return (i);
}

186
lib/libc/stdlib/a64l.3 Normal file
View File

@ -0,0 +1,186 @@
.\" Copyright (c) 2005 Tom Rhodes
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" Portions of this text are reprinted and reproduced in electronic form
.\" from IEEE Std 1003.1, 2004 Edition, Standard for Information Technology --
.\" Portable Operating System Interface (POSIX), The Open Group Base
.\" Specifications Issue 6, Copyright (C) 2001-2004 by the Institute of
.\" Electrical and Electronics Engineers, Inc and The Open Group. In the
.\" event of any discrepancy between this version and the original IEEE and
.\" The Open Group Standard, the original IEEE and The Open Group Standard is
.\" the referee document. The original Standard can be obtained online at
.\" http://www.opengroup.org/unix/online.html.
.\"
.\" $FreeBSD$
.\"
.Dd November 20, 2005
.Dt A64L 3
.Os
.Sh NAME
.Nm a64l ,
.Nm l64a ,
.Nm l64a_r
.Nd "convert between a long integer and a base-64 ASCII string"
.Sh LIBRARY
.Lb libc
.Sh SYNOPSIS
.In stdlib.h
.Ft long
.Fn a64l "const char *s"
.Ft char *
.Fn l64a "long int l"
.Ft int
.Fn l64a_r "long int l" "char *buffer" "int buflen"
.Sh DESCRIPTION
These functions are used to maintain numbers stored in radix-64
.Tn ASCII
characters.
This is a notation by which 32-bit integers can be represented by
up to six characters; each character represents a digit in
radix-64 notation.
If the type long contains more than 32 bits, only the low-order
32 bits are used for these operations.
.Pp
The characters used to represent
.Dq digits
are
.Ql .\&
for 0,
.Ql /\&
for 1,
.Ql 0\&
.Fl
.Ql 9\&
for 2
.Fl
11,
.Ql A\&
.Fl
.Ql Z\&
for 12
.Fl
37, and
.Ql a\&
.Fl
.Ql z\&
for 38
.Fl
63.
.Pp
The
.Fn a64l
function takes a pointer to a radix-64 representation, in which the first
digit is the least significant, and returns a corresponding
.Ft long
value.
If the string pointed to by
.Fa s
contains more than six characters,
.Fn a64l
uses the first six.
If the first six characters of the string contain a null terminator,
.Fn a64l
uses only characters preceding the null terminator.
The
.Fn a64l
function scans the character string from left to right with the least
significant digit on the left, decoding each character as a 6-bit
radix-64 number.
If the type long contains more than 32 bits, the resulting value is
sign-extended.
The behavior of
.Fn a64l
is unspecified if
.Fa s
is a null pointer or the string pointed to by
.Fa s
was not generated by a previous call to
.Fn l64a .
.Pp
The
.Fn l64a
function takes a long argument and returns a pointer to the corresponding
radix-64 representation.
The behavior of
.Fn l64a
is unspecified if value is negative.
.Pp
The value returned by
.Fn l64a
is a pointer into a static buffer.
Subsequent calls to
.Fn l64a
may overwrite the buffer.
.Pp
The
.Fn l64a_r
function performs a conversion identical to that of
.Fn l64a
and stores the resulting representation in the memory area pointed to by
.Fa buffer ,
consuming at most
.Fa buflen
characters including the terminating NUL character.
.Sh RETURN VALUES
On successful completion,
.Fn a64l
returns the
.Ft long
value resulting from conversion of the input string.
If a string pointed to by s is an empty string,
.Fn a64l
returns 0.
.Pp
The
l64a
function returns a pointer to the radix-64 representation.
If value is 0,
.Fn l64a
returns a pointer to an empty string.
.Sh SEE ALSO
.Xr stroul 3
.Sh HISTORY
The
.Fn a64l ,
.Fn l64a ,
and
.Fn l64a_r
functions are derived from
.Nx
with modifications.
They were added to
.Fx 6.1 .
.Sh AUTHORS
The
.Fn a64l ,
.Fn l64a ,
and
.Fn l64a_r
were added to
.Fx
by
.An Tom Rhodes Aq trhodes@FreeBSD.org .
Almost all of this manual page came from the
.Tn POSIX
standard.

46
lib/libc/stdlib/a64l.c Normal file
View File

@ -0,0 +1,46 @@
/*-
* Written by J.T. Conklin <jtc@netbsd.org>.
* Public domain.
*/
#if 0
#if defined(LIBC_SCCS) && !defined(lint)
__RCSID("$NetBSD: a64l.c,v 1.8 2000/01/22 22:19:19 mycroft Exp $");
#endif /* not lint */
#endif
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
#include <stdlib.h>
#include <inttypes.h>
#define ADOT 46 /* ASCII '.' */
#define ASLASH ADOT + 1 /* ASCII '/' */
#define A0 48 /* ASCII '0' */
#define AA 65 /* ASCII 'A' */
#define Aa 97 /* ASCII 'a' */
long
a64l(const char *s)
{
long shift;
int digit, i, value;
value = 0;
shift = 0;
for (i = 0; *s != '\0' && i < 6; i++, s++) {
if (*s <= ASLASH)
digit = *s - ASLASH + 1;
else if (*s <= A0 + 9)
digit = *s - A0 + 2;
else if (*s <= AA + 25)
digit = *s - AA + 12;
else
digit = *s - Aa + 38;
value |= digit << shift;
shift += 6;
}
return (value);
}

52
lib/libc/stdlib/l64a.c Normal file
View File

@ -0,0 +1,52 @@
/*
* Written by J.T. Conklin <jtc@NetBSD.org>.
* Public domain.
*/
#if 0
#if defined(LIBC_SCCS) && !defined(lint)
__RCSID("$NetBSD: l64a.c,v 1.13 2003/07/26 19:24:54 salo Exp $");
#endif /* not lint */
#endif
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
#include <stdlib.h>
#define ADOT 46 /* ASCII '.' */
#define ASLASH ADOT + 1 /* ASCII '/' */
#define A0 48 /* ASCII '0' */
#define AA 65 /* ASCII 'A' */
#define Aa 97 /* ASCII 'a' */
char *
l64a(long value)
{
static char buf[8];
(void)l64a_r(value, buf, sizeof(buf));
return (buf);
}
int
l64a_r(long value, char *buffer, int buflen)
{
long v;
int digit;
v = value & (long)0xffffffff;
for (; v != 0 && buflen > 1; buffer++, buflen--) {
digit = v & 0x3f;
if (digit < 2)
*buffer = digit + ADOT;
else if (digit < 12)
*buffer = digit + A0 - 2;
else if (digit < 38)
*buffer = digit + AA - 12;
else
*buffer = digit + Aa - 38;
v >>= 6;
}
return (v == 0 ? 0 : -1);
}

199
lib/libc/sys/sigwaitinfo.2 Normal file
View File

@ -0,0 +1,199 @@
.\" Copyright (c) 2005 David Xu <davidxu@FreeBSD.org>
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice(s), this list of conditions and the following disclaimer as
.\" the first lines of this file unmodified other than the possible
.\" addition of one or more copyright notices.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice(s), this list of conditions and the following disclaimer in
.\" the documentation and/or other materials provided with the
.\" distribution.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER(S) ``AS IS'' AND ANY
.\" EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) BE
.\" LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
.\" BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
.\" WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
.\" OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
.\" EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.\"
.\" $FreeBSD$
.\"
.Dd November 11, 2005
.Dt SIGTIMEDWAIT 2
.Os
.Sh NAME
.Nm sigtimedwait , sigwaitinfo
.Nd "wait for queued signals (REALTIME)"
.Sh LIBRARY
.Lb libc
.Sh SYNOPSIS
.In signal.h
.Ft int
.Fo sigtimedwait
.Fa "const sigset_t *restrict set" "siginfo_t *restrict info"
.Fa "const struct timespec *restrict timeout"
.Fc
.Ft int
.Fn sigwaitinfo "const sigset_t * restrict set" "siginfo_t * restrict info"
.Sh DESCRIPTION
The
.Fn sigtimedwait
system call is equivalent to
.Fn sigwaitinfo
except that if none of the signals specified by
.Fa set
are pending,
.Fn sigtimedwait
waits for the time interval specified in the
.Vt timespec
structure referenced by
.Fa timeout .
If the
.Vt timespec
structure pointed to by
.Fa timeout
is zero-valued and if none of the signals specified by
.Fa set
are pending, then
.Fn sigtimedwait
returns immediately with an error.
If
.Fa timeout
is the
.Dv NULL
pointer, the behavior is unspecified.
.Dv CLOCK_MONOTONIC
clock is used to measure the time interval specified by the
.Fa timeout
argument.
.Pp
The
.Fn sigwaitinfo
system call selects the pending signal from the set specified by
.Fa set .
Should any of multiple pending signals in the range
.Dv SIGRTMIN
to
.Dv SIGRTMAX
be selected, it shall be the lowest numbered one.
The
selection order between realtime and non-realtime signals, or
between multiple pending non-realtime signals, is unspecified.
If no signal in
.Fa set
is pending at the time of the call, the calling thread
is suspended until one or more signals in
.Fa set
become pending or until it is interrupted by an unblocked, caught signal.
.Pp
The
.Fn sigwaitinfo
system call is equivalent to the
.Fn sigwait
system call if the
.Fa info
argument is
.Dv NULL .
If the
.Fa info
argument is
.Pf non- Dv NULL ,
the
.Fn sigwaitinfo
function is equivalent to
.Fn sigwait ,
except that the selected signal number shall be stored in the
.Va si_signo
member, and the cause of the signal shall be stored in the
.Va si_code
member.
If any value is queued to the selected signal, the first such queued
value is dequeued and, if the info argument is
.Pf non- Dv NULL ,
the value is stored in the
.Va si_value
member of
.Fa info .
The system resource used to queue the signal
is released and returned to the system for other use.
If no value is queued,
the content of the
.Va si_value
member is zero-valued.
If no further signals are
queued for the selected signal, the pending indication for that signal
is reset.
.Sh RETURN VALUES
Upon successful completion (that is, one of the signals specified by
.Fa set
is pending or is generated)
.Fn sigwaitinfo
and
.Fn sigtimedwait
return the selected signal number.
Otherwise, the functions return a value of \-1
and set the global variable
.Va errno
to indicate the error.
.Sh ERRORS
The
.Fn sigtimedwait
system call
will fail if:
.Bl -tag -width Er
.It Bq Er EAGAIN
No signal specified by set was generated within the specified timeout period.
.El
.Pp
The
.Fn sigtimedwait
and
.Fn sigwaitinfo
system calls fail if:
.Bl -tag -width Er
.It Bq Er EINTR
The wait was interrupted by an unblocked, caught signal.
.It Bq Er EFAULT
Any arguments point outside the allocated address space or there is a
memory protection fault.
.Pp
.El
The
.Fn sigtimedwait
system call may also fail if:
.Bl -tag -width Er
.It Bq Er EINVAL
The
.Fa timeout
argument specified a
.Va tv_nsec
value less than zero or greater than or equal
to 1000 million.
Kernel only checks for this error if no signal is pending in set and it
is necessary to wait.
.El
.Sh SEE ALSO
.Xr sigaction 2 ,
.Xr sigpending 2 ,
.Xr sigqueue 2 ,
.Xr sigsuspend 2 ,
.Xr sigwait 2 ,
.Xr pause 3 ,
.Xr pthread_sigmask 3 ,
.Xr siginfo 3
.Sh STANDARDS
The
.Fn sigtimedwait
and
.Fn sigwaitinfo
system calls conform to
.St -p1003.1-96 .

87
share/man/man4/snd_atiixp.4 Normal file
View File

@ -0,0 +1,87 @@
.\" Copyright (c) 2005 Joel Dahl
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" $FreeBSD$
.\"
.Dd November 28, 2005
.Dt SND_ATIIXP 4
.Os
.Sh NAME
.Nm snd_atiixp
.Nd "ATI IXP bridge device driver"
.Sh SYNOPSIS
To compile this driver into the kernel, place the following lines in your
kernel configuration file:
.Bd -ragged -offset indent
.Cd "device sound"
.Cd "device snd_atiixp"
.Ed
.Pp
Alternatively, to load the driver as a module at boot time, place the
following line in
.Xr loader.conf 5 :
.Bd -literal -offset indent
snd_atiixp_load="YES"
.Ed
.Sh DESCRIPTION
The
.Nm
bridge driver allows the generic audio driver,
.Xr sound 4 ,
to attach to ATI IXP audio devices.
This driver supports 16bit playback and recording, and 32bit native playback.
.Sh HARDWARE
The
.Nm
driver supports the following audio chipsets:
.Pp
.Bl -bullet -compact
.It
ATI IXP 200
.It
ATI IXP 300
.It
ATI IXP 400
.El
.Sh SEE ALSO
.Xr sound 4
.Sh HISTORY
The
.Nm
device driver first appeared in
.Fx 6.1 .
.Sh AUTHORS
This manual page was written by
.An Joel Dahl Aq joel@FreeBSD.org .
.Sh BUGS
The
.Nm
driver
does not support S/PDIF, but implementing it should be fairly easy if the
right hardware is available.
.Pp
32bit recording is broken.
Perhaps this hardware cannot do 32bit recording at all.
If this is true, we can disable it entirely within the driver someday in the
future.

180
sys/dev/cardbus/cardbus_device.c Normal file
View File

@ -0,0 +1,180 @@
/*-
* Copyright (c) 2005, M. Warner Losh
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice unmodified, this list of conditions, and the following
* disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*/
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
#include <sys/param.h>
#include <sys/conf.h>
#include <sys/malloc.h>
#include <sys/systm.h>
#include <sys/uio.h>
#include <sys/bus.h>
#include <machine/bus.h>
#include <sys/rman.h>
#include <machine/resource.h>
#include <sys/pciio.h>
#include <dev/pci/pcivar.h>
#include <dev/pci/pcireg.h>
#include <dev/pci/pci_private.h>
#include <dev/cardbus/cardbusreg.h>
#include <dev/cardbus/cardbusvar.h>
#include <dev/cardbus/cardbus_cis.h>
#include <dev/pccard/pccard_cis.h>
static d_open_t cardbus_open;
static d_close_t cardbus_close;
static d_read_t cardbus_read;
static d_ioctl_t cardbus_ioctl;
static struct cdevsw cardbus_cdevsw = {
.d_version = D_VERSION,
.d_open = cardbus_open,
.d_close = cardbus_close,
.d_read = cardbus_read,
.d_ioctl = cardbus_ioctl,
.d_name = "cardbus"
};
int
cardbus_device_create(struct cardbus_softc *sc)
{
uint32_t minor;
minor = device_get_unit(sc->sc_dev) << 16;
sc->sc_cisdev = make_dev(&cardbus_cdevsw, minor, 0, 0, 0666,
"cardbus%u.cis", device_get_unit(sc->sc_dev));
sc->sc_cisdev->si_drv1 = sc;
return (0);
}
int
cardbus_device_destroy(struct cardbus_softc *sc)
{
if (sc->sc_cisdev)
destroy_dev(sc->sc_cisdev);
return (0);
}
static int
cardbus_build_cis(device_t cbdev, device_t child, int id,
int len, uint8_t *tupledata, uint32_t start, uint32_t *off,
struct tuple_callbacks *info, void *argp)
{
struct cis_buffer *cis;
int i;
cis = (struct cis_buffer *)argp;
/*
* CISTPL_END is a special case, it has no length field.
*/
if (id == CISTPL_END) {
if (cis->len + 1 > sizeof(cis->buffer))
return (ENOSPC);
cis->buffer[cis->len++] = id;
return (0);
}
if (cis->len + 2 + len > sizeof(cis->buffer))
return (ENOSPC);
cis->buffer[cis->len++] = id;
cis->buffer[cis->len++] = len;
for (i = 0; i < len; i++)
cis->buffer[cis->len++] = tupledata[i];
return (0);
}
static int
cardbus_open(struct cdev *dev, int oflags, int devtype, struct thread *td)
{
device_t parent, child;
device_t *kids;
int cnt, err;
struct cardbus_softc *sc;
struct tuple_callbacks cb[] = {
{CISTPL_GENERIC, "GENERIC", cardbus_build_cis}
};
sc = dev->si_drv1;
if (sc->sc_cis_open)
return (EBUSY);
parent = sc->sc_dev;
err = device_get_children(parent, &kids, &cnt);
if (err)
return err;
if (cnt == 0) {
free(kids, M_TEMP);
sc->sc_cis_open++;
sc->sc_cis = NULL;
return (0);
}
child = kids[0];
free(kids, M_TEMP);
sc->sc_cis = malloc(sizeof(*sc->sc_cis), M_TEMP, M_ZERO | M_WAITOK);
err = cardbus_parse_cis(parent, child, cb, sc->sc_cis);
if (err) {
free(sc->sc_cis, M_TEMP);
sc->sc_cis = NULL;
return (err);
}
sc->sc_cis_open++;
return (0);
}
static int
cardbus_close(struct cdev *dev, int fflags, int devtype, struct thread *td)
{
struct cardbus_softc *sc;
sc = dev->si_drv1;
free(sc->sc_cis, M_TEMP);
sc->sc_cis = NULL;
sc->sc_cis_open = 0;
return (0);
}
static int
cardbus_ioctl(struct cdev *dev, u_long cmd, caddr_t data, int fflag,
struct thread *td)
{
return (ENOTTY);
}
static int
cardbus_read(struct cdev *dev, struct uio *uio, int ioflag)
{
struct cardbus_softc *sc;
sc = dev->si_drv1;
/* EOF */
if (sc->sc_cis == NULL || uio->uio_offset > sc->sc_cis->len)
return (0);
return (uiomove(sc->sc_cis->buffer + uio->uio_offset,
MIN(uio->uio_resid, sc->sc_cis->len - uio->uio_offset), uio));
}

1090
sys/dev/sound/pci/atiixp.c Normal file
View File

File diff suppressed because it is too large Load Diff

9
sys/modules/i2c/controllers/amdsmb/Makefile Normal file
View File

@ -0,0 +1,9 @@
# $FreeBSD$
.PATH: ${.CURDIR}/../../../../pci
KMOD= amdsmb
SRCS= amdsmb.c
SRCS+= device_if.h smbus_if.h pci_if.h bus_if.h
.include <bsd.kmod.mk>

9
sys/modules/i2c/controllers/nfsmb/Makefile Normal file
View File

@ -0,0 +1,9 @@
# $FreeBSD$
.PATH: ${.CURDIR}/../../../../pci
KMOD= nfsmb
SRCS= nfsmb.c
SRCS+= device_if.h smbus_if.h pci_if.h bus_if.h
.include <bsd.kmod.mk>

3
sys/powerpc/conf/Makefile Normal file
View File

@ -0,0 +1,3 @@
# $FreeBSD$
.include "${.CURDIR}/../../conf/makeLINT.mk"

81
sys/powerpc/conf/NOTES Normal file
View File

@ -0,0 +1,81 @@
# $FreeBSD$
#
# This file contains machine dependent kernel configuration notes. For
# machine independent notes, look in /sys/conf/NOTES.
#####################################################################
# CPU OPTIONS
#
# You must specify at least one CPU (the one you intend to run on).
cpu OEA
options POWERMAC #NewWorld Apple PowerMacs
options PSIM #GDB PSIM ppc simulator
options SC_OFWFB # OFW frame buffer
# Standard busses
device pci
device zs # Zilog 8350 based serial ports
device gem # Sun GEM/Sun ERI/Apple GMAC
device ofwd # Open Firmware disks
#####################################################################
# Devices we don't want to deal with
nodevice atkbdc
nodevice atkbd
nodevice psm
nodevice vga
nodevice fdc
nodevice ppc
# when splash works enable *_saver
nodevice splash
nodevice blank_saver
nodevice daemon_saver
nodevice dragon_saver
nodevice fade_saver
nodevice fire_saver
nodevice green_saver
nodevice logo_saver
nodevice rain_saver
nodevice snake_saver
nodevice star_saver
nodevice warp_saver
nodevice daemon_saver
nodevice star_saver
nodevice snake_saver
# needs outsw use fixed
nodevice cs
# XXX can't remember why
nodevice uart
# isa
nodevice pcii
nodevice tnt4882
# wants gdb_cur
nodevice dcons
nodevice dcons_crom
# not yet
nodevice sio
#####################################################################
# Options we don't want to deal with
nooption SMP
nooption GDB
nooption VGA_DEBUG
nooption VGA_WIDTH90
nooption VGA_SLOW_IOACCESS
nooption VGA_ALT_SEQACCESS
nooption PPC_DEBUG
nooption PPC_PROBE_CHIPSET
nooption PSM_RESETAFTERSUSPEND
nooption PSM_HOOKRESUME
nooption ATKBD_DFLT_KEYMAP
nooption UKBD_DFLT_KEYMAP

223
tools/tools/ath/athdebug/athdebug.c Normal file
View File

@ -0,0 +1,223 @@
/*-
* Copyright (c) 2002-2004 Sam Leffler, Errno Consulting
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer,
* without modification.
* 2. Redistributions in binary form must reproduce at minimum a disclaimer
* similar to the "NO WARRANTY" disclaimer below ("Disclaimer") and any
* redistribution must be conditioned upon including a substantially
* similar Disclaimer requirement for further binary redistribution.
* 3. Neither the names of the above-listed copyright holders nor the names
* of any contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
* Alternatively, this software may be distributed under the terms of the
* GNU General Public License ("GPL") version 2 as published by the Free
* Software Foundation.
*
* NO WARRANTY
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTIBILITY
* AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
* THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY,
* OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
* IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
* THE POSSIBILITY OF SUCH DAMAGES.
*
* $FreeBSD$
*/
/*
* athdebug [-i interface] flags
* (default interface is ath0).
*/
#include <sys/types.h>
#include <sys/file.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <stdio.h>
#include <ctype.h>
#include <getopt.h>
#define N(a) (sizeof(a)/sizeof(a[0]))
const char *progname;
enum {
ATH_DEBUG_XMIT = 0x00000001, /* basic xmit operation */
ATH_DEBUG_XMIT_DESC = 0x00000002, /* xmit descriptors */
ATH_DEBUG_RECV = 0x00000004, /* basic recv operation */
ATH_DEBUG_RECV_DESC = 0x00000008, /* recv descriptors */
ATH_DEBUG_RATE = 0x00000010, /* rate control */
ATH_DEBUG_RESET = 0x00000020, /* reset processing */
ATH_DEBUG_MODE = 0x00000040, /* mode init/setup */
ATH_DEBUG_BEACON = 0x00000080, /* beacon handling */
ATH_DEBUG_WATCHDOG = 0x00000100, /* watchdog timeout */
ATH_DEBUG_INTR = 0x00001000, /* ISR */
ATH_DEBUG_TX_PROC = 0x00002000, /* tx ISR proc */
ATH_DEBUG_RX_PROC = 0x00004000, /* rx ISR proc */
ATH_DEBUG_BEACON_PROC = 0x00008000, /* beacon ISR proc */
ATH_DEBUG_CALIBRATE = 0x00010000, /* periodic calibration */
ATH_DEBUG_KEYCACHE = 0x00020000, /* key cache management */
ATH_DEBUG_STATE = 0x00040000, /* 802.11 state transitions */
ATH_DEBUG_NODE = 0x00080000, /* node management */
ATH_DEBUG_LED = 0x00100000, /* led management */
ATH_DEBUG_FF = 0x00200000, /* fast frames */
ATH_DEBUG_DFS = 0x00400000, /* DFS processing */
ATH_DEBUG_FATAL = 0x80000000, /* fatal errors */
ATH_DEBUG_ANY = 0xffffffff
};
static struct {
const char *name;
u_int bit;
} flags[] = {
{ "xmit", ATH_DEBUG_XMIT },
{ "xmit_desc", ATH_DEBUG_XMIT_DESC },
{ "recv", ATH_DEBUG_RECV },
{ "recv_desc", ATH_DEBUG_RECV_DESC },
{ "rate", ATH_DEBUG_RATE },
{ "reset", ATH_DEBUG_RESET },
{ "mode", ATH_DEBUG_MODE },
{ "beacon", ATH_DEBUG_BEACON },
{ "watchdog", ATH_DEBUG_WATCHDOG },
{ "intr", ATH_DEBUG_INTR },
{ "xmit_proc", ATH_DEBUG_TX_PROC },
{ "recv_proc", ATH_DEBUG_RX_PROC },
{ "beacon_proc",ATH_DEBUG_BEACON_PROC },
{ "calibrate", ATH_DEBUG_CALIBRATE },
{ "keycache", ATH_DEBUG_KEYCACHE },
{ "state", ATH_DEBUG_STATE },
{ "node", ATH_DEBUG_NODE },
{ "led", ATH_DEBUG_LED },
{ "ff", ATH_DEBUG_FF },
{ "dfs", ATH_DEBUG_DFS },
{ "fatal", ATH_DEBUG_FATAL },
};
static u_int
getflag(const char *name, int len)
{
int i;
for (i = 0; i < N(flags); i++)
if (strncasecmp(flags[i].name, name, len) == 0)
return flags[i].bit;
return 0;
}
static const char *
getflagname(u_int flag)
{
int i;
for (i = 0; i < N(flags); i++)
if (flags[i].bit == flag)
return flags[i].name;
return "???";
}
static void
usage(void)
{
int i;
fprintf(stderr, "usage: %s [-i device] [flags]\n", progname);
fprintf(stderr, "where flags are:\n");
for (i = 0; i < N(flags); i++)
printf("%s\n", flags[i].name);
exit(-1);
}
int
main(int argc, char *argv[])
{
const char *ifname = "ath0";
const char *cp, *tp;
const char *sep;
int c, op, i;
u_int32_t debug, ndebug;
size_t debuglen;
char oid[256];
progname = argv[0];
if (argc > 1) {
if (strcmp(argv[1], "-i") == 0) {
if (argc < 2)
errx(1, "missing interface name for -i option");
ifname = argv[2];
if (strncmp(ifname, "ath", 3) != 0)
errx(2, "huh, this is for ath devices?");
argc -= 2, argv += 2;
} else if (strcmp(argv[1], "-?") == 0)
usage();
}
#ifdef __linux__
snprintf(oid, sizeof(oid), "dev.%s.debug", ifname);
#else
snprintf(oid, sizeof(oid), "dev.ath.%s.debug", ifname+3);
#endif
debuglen = sizeof(debug);
if (sysctlbyname(oid, &debug, &debuglen, NULL, 0) < 0)
err(1, "sysctl-get(%s)", oid);
ndebug = debug;
for (; argc > 1; argc--, argv++) {
cp = argv[1];
do {
u_int bit;
if (*cp == '-') {
cp++;
op = -1;
} else if (*cp == '+') {
cp++;
op = 1;
} else
op = 0;
for (tp = cp; *tp != '\0' && *tp != '+' && *tp != '-';)
tp++;
bit = getflag(cp, tp-cp);
if (op < 0)
ndebug &= ~bit;
else if (op > 0)
ndebug |= bit;
else {
if (bit == 0) {
if (isdigit(*cp))
bit = strtoul(cp, NULL, 0);
else
errx(1, "unknown flag %.*s",
tp-cp, cp);
}
ndebug = bit;
}
} while (*(cp = tp) != '\0');
}
if (debug != ndebug) {
printf("%s: 0x%x => ", oid, debug);
if (sysctlbyname(oid, NULL, NULL, &ndebug, sizeof(ndebug)) < 0)
err(1, "sysctl-set(%s)", oid);
printf("0x%x", ndebug);
debug = ndebug;
} else
printf("%s: 0x%x", oid, debug);
sep = "<";
for (i = 0; i < N(flags); i++)
if (debug & flags[i].bit) {
printf("%s%s", sep, flags[i].name);
sep = ",";
}
printf("%s\n", *sep != '<' ? ">" : "");
return 0;
}

334
tools/tools/ath/athstats/athstats.c Normal file
View File

@ -0,0 +1,334 @@
/*-
* Copyright (c) 2002, 2003 Sam Leffler, Errno Consulting
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer,
* without modification.
* 2. Redistributions in binary form must reproduce at minimum a disclaimer
* similar to the "NO WARRANTY" disclaimer below ("Disclaimer") and any
* redistribution must be conditioned upon including a substantially
* similar Disclaimer requirement for further binary redistribution.
* 3. Neither the names of the above-listed copyright holders nor the names
* of any contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
* Alternatively, this software may be distributed under the terms of the
* GNU General Public License ("GPL") version 2 as published by the Free
* Software Foundation.
*
* NO WARRANTY
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTIBILITY
* AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
* THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY,
* OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
* IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
* THE POSSIBILITY OF SUCH DAMAGES.
*
* $FreeBSD$
*/
/*
* Simple Atheros-specific tool to inspect and monitor network traffic
* statistics.
* athstats [-i interface] [interval]
* (default interface is ath0). If interval is specified a rolling output
* a la netstat -i is displayed every interval seconds.
*
* To build: cc -o athstats athstats.c -lkvm
*/
#include <sys/types.h>
#include <sys/file.h>
#include <sys/sockio.h>
#include <sys/socket.h>
#include <net/if.h>
#include <net/if_media.h>
#include <net/if_var.h>
#include <stdio.h>
#include <signal.h>
#include "../../../../sys/contrib/dev/ath/ah_desc.h"
#include "../../../../sys/net80211/ieee80211_ioctl.h"
#include "../../../../sys/net80211/ieee80211_radiotap.h"
#include "../../../../sys/dev/ath/if_athioctl.h"
static const struct {
u_int phyerr;
const char* desc;
} phyerrdescriptions[] = {
{ HAL_PHYERR_UNDERRUN, "transmit underrun" },
{ HAL_PHYERR_TIMING, "timing error" },
{ HAL_PHYERR_PARITY, "illegal parity" },
{ HAL_PHYERR_RATE, "illegal rate" },
{ HAL_PHYERR_LENGTH, "illegal length" },
{ HAL_PHYERR_RADAR, "radar detect" },
{ HAL_PHYERR_SERVICE, "illegal service" },
{ HAL_PHYERR_TOR, "transmit override receive" },
{ HAL_PHYERR_OFDM_TIMING, "OFDM timing" },
{ HAL_PHYERR_OFDM_SIGNAL_PARITY,"OFDM illegal parity" },
{ HAL_PHYERR_OFDM_RATE_ILLEGAL, "OFDM illegal rate" },
{ HAL_PHYERR_OFDM_POWER_DROP, "OFDM power drop" },
{ HAL_PHYERR_OFDM_SERVICE, "OFDM illegal service" },
{ HAL_PHYERR_OFDM_RESTART, "OFDM restart" },
{ HAL_PHYERR_CCK_TIMING, "CCK timing" },
{ HAL_PHYERR_CCK_HEADER_CRC, "CCK header crc" },
{ HAL_PHYERR_CCK_RATE_ILLEGAL, "CCK illegal rate" },
{ HAL_PHYERR_CCK_SERVICE, "CCK illegal service" },
{ HAL_PHYERR_CCK_RESTART, "CCK restart" },
};
static void
printstats(FILE *fd, const struct ath_stats *stats)
{
#define N(a) (sizeof(a) / sizeof(a[0]))
#define STAT(x,fmt) \
if (stats->ast_##x) fprintf(fd, "%u " fmt "\n", stats->ast_##x)
int i, j;
STAT(watchdog, "watchdog timeouts");
STAT(hardware, "hardware error interrupts");
STAT(bmiss, "beacon miss interrupts");
STAT(bstuck, "stuck beacon conditions");
STAT(rxorn, "recv overrun interrupts");
STAT(rxeol, "recv eol interrupts");
STAT(txurn, "txmit underrun interrupts");
STAT(mib, "mib overflow interrupts");
STAT(intrcoal, "interrupts coalesced");
STAT(tx_mgmt, "tx management frames");
STAT(tx_discard, "tx frames discarded prior to association");
STAT(tx_qstop, "tx stopped 'cuz no xmit buffer");
STAT(tx_encap, "tx encapsulation failed");
STAT(tx_nonode, "tx failed 'cuz no node");
STAT(tx_nombuf, "tx failed 'cuz no mbuf");
STAT(tx_nomcl, "tx failed 'cuz no cluster");
STAT(tx_linear, "tx linearized to cluster");
STAT(tx_nodata, "tx discarded empty frame");
STAT(tx_busdma, "tx failed for dma resrcs");
STAT(tx_xretries, "tx failed 'cuz too many retries");
STAT(tx_fifoerr, "tx failed 'cuz FIFO underrun");
STAT(tx_filtered, "tx failed 'cuz xmit filtered");
STAT(tx_shortretry, "short on-chip tx retries");
STAT(tx_longretry, "long on-chip tx retries");
STAT(tx_badrate, "tx failed 'cuz bogus xmit rate");
STAT(tx_noack, "tx frames with no ack marked");
STAT(tx_rts, "tx frames with rts enabled");
STAT(tx_cts, "tx frames with cts enabled");
STAT(tx_shortpre, "tx frames with short preamble");
STAT(tx_altrate, "tx frames with an alternate rate");
STAT(tx_protect, "tx frames with 11g protection");
STAT(rx_nombuf, "rx setup failed 'cuz no mbuf");
STAT(rx_busdma, "rx setup failed for dma resrcs");
STAT(rx_orn, "rx failed 'cuz of desc overrun");
STAT(rx_crcerr, "rx failed 'cuz of bad CRC");
STAT(rx_fifoerr, "rx failed 'cuz of FIFO overrun");
STAT(rx_badcrypt, "rx failed 'cuz decryption");
STAT(rx_badmic, "rx failed 'cuz MIC failure");
STAT(rx_tooshort, "rx failed 'cuz frame too short");
STAT(rx_toobig, "rx failed 'cuz frame too large");
STAT(rx_mgt, "rx management frames");
STAT(rx_ctl, "rx control frames");
STAT(rx_phyerr, "rx failed 'cuz of PHY err");
if (stats->ast_rx_phyerr != 0) {
for (i = 0; i < 32; i++) {
if (stats->ast_rx_phy[i] == 0)
continue;
for (j = 0; j < N(phyerrdescriptions); j++)
if (phyerrdescriptions[j].phyerr == i)
break;
if (j == N(phyerrdescriptions))
fprintf(fd,
" %u (unknown phy error code %u)\n",
stats->ast_rx_phy[i], i);
else
fprintf(fd, " %u %s\n",
stats->ast_rx_phy[i],
phyerrdescriptions[j].desc);
}
}
STAT(be_nombuf, "beacon setup failed 'cuz no mbuf");
STAT(be_xmit, "beacons transmitted");
STAT(per_cal, "periodic calibrations");
STAT(per_calfail, "periodic calibration failures");
STAT(per_rfgain, "rfgain value change");
STAT(rate_calls, "rate control checks");
STAT(rate_raise, "rate control raised xmit rate");
STAT(rate_drop, "rate control dropped xmit rate");
if (stats->ast_tx_rssi)
fprintf(fd, "rssi of last ack: %u\n", stats->ast_tx_rssi);
if (stats->ast_rx_rssi)
fprintf(fd, "avg recv rssi: %u\n", stats->ast_rx_rssi);
STAT(ant_defswitch, "switched default/rx antenna");
STAT(ant_txswitch, "tx used alternate antenna");
fprintf(fd, "Antenna profile:\n");
for (i = 0; i < 8; i++)
if (stats->ast_ant_rx[i] || stats->ast_ant_tx[i])
fprintf(fd, "[%u] tx %8u rx %8u\n", i,
stats->ast_ant_tx[i], stats->ast_ant_rx[i]);
#undef STAT
#undef N
}
static u_int
getifrate(int s, const char* ifname)
{
#define N(a) (sizeof(a) / sizeof(a[0]))
static const int rates[] = {
0, /* IFM_AUTO */
0, /* IFM_MANUAL */
0, /* IFM_NONE */
1, /* IFM_IEEE80211_FH1 */
2, /* IFM_IEEE80211_FH2 */
1, /* IFM_IEEE80211_DS1 */
2, /* IFM_IEEE80211_DS2 */
5, /* IFM_IEEE80211_DS5 */
11, /* IFM_IEEE80211_DS11 */
22, /* IFM_IEEE80211_DS22 */
6, /* IFM_IEEE80211_OFDM6 */
9, /* IFM_IEEE80211_OFDM9 */
12, /* IFM_IEEE80211_OFDM12 */
18, /* IFM_IEEE80211_OFDM18 */
24, /* IFM_IEEE80211_OFDM24 */
36, /* IFM_IEEE80211_OFDM36 */
48, /* IFM_IEEE80211_OFDM48 */
54, /* IFM_IEEE80211_OFDM54 */
72, /* IFM_IEEE80211_OFDM72 */
};
struct ifmediareq ifmr;
int *media_list, i;
(void) memset(&ifmr, 0, sizeof(ifmr));
(void) strncpy(ifmr.ifm_name, ifname, sizeof(ifmr.ifm_name));
if (ioctl(s, SIOCGIFMEDIA, (caddr_t)&ifmr) < 0)
return 0;
return IFM_SUBTYPE(ifmr.ifm_active) < N(rates) ?
rates[IFM_SUBTYPE(ifmr.ifm_active)] : 0;
#undef N
}
static int signalled;
static void
catchalarm(int signo __unused)
{
signalled = 1;
}
int
main(int argc, char *argv[])
{
int s;
struct ifreq ifr;
s = socket(AF_INET, SOCK_DGRAM, 0);
if (s < 0)
err(1, "socket");
if (argc > 1 && strcmp(argv[1], "-i") == 0) {
if (argc < 2) {
fprintf(stderr, "%s: missing interface name for -i\n",
argv[0]);
exit(-1);
}
strncpy(ifr.ifr_name, argv[2], sizeof (ifr.ifr_name));
argc -= 2, argv += 2;
} else
strncpy(ifr.ifr_name, "ath0", sizeof (ifr.ifr_name));
if (argc > 1) {
u_long interval = strtoul(argv[1], NULL, 0);
int line, omask;
u_int rate = getifrate(s, ifr.ifr_name);
struct ath_stats cur, total;
if (interval < 1)
interval = 1;
signal(SIGALRM, catchalarm);
signalled = 0;
alarm(interval);
banner:
printf("%8s %8s %7s %7s %7s %6s %6s %5s %7s %4s %4s"
, "input"
, "output"
, "altrate"
, "short"
, "long"
, "xretry"
, "crcerr"
, "crypt"
, "phyerr"
, "rssi"
, "rate"
);
putchar('\n');
fflush(stdout);
line = 0;
loop:
if (line != 0) {
ifr.ifr_data = (caddr_t) &cur;
if (ioctl(s, SIOCGATHSTATS, &ifr) < 0)
err(1, ifr.ifr_name);
rate = getifrate(s, ifr.ifr_name);
printf("%8u %8u %7u %7u %7u %6u %6u %5u %7u %4u %3uM\n"
, cur.ast_rx_packets - total.ast_rx_packets
, cur.ast_tx_packets - total.ast_tx_packets
, cur.ast_tx_altrate - total.ast_tx_altrate
, cur.ast_tx_shortretry - total.ast_tx_shortretry
, cur.ast_tx_longretry - total.ast_tx_longretry
, cur.ast_tx_xretries - total.ast_tx_xretries
, cur.ast_rx_crcerr - total.ast_rx_crcerr
, cur.ast_rx_badcrypt - total.ast_rx_badcrypt
, cur.ast_rx_phyerr - total.ast_rx_phyerr
, cur.ast_rx_rssi
, rate
);
total = cur;
} else {
ifr.ifr_data = (caddr_t) &total;
if (ioctl(s, SIOCGATHSTATS, &ifr) < 0)
err(1, ifr.ifr_name);
rate = getifrate(s, ifr.ifr_name);
printf("%8u %8u %7u %7u %7u %6u %6u %5u %7u %4u %3uM\n"
, total.ast_rx_packets
, total.ast_tx_packets
, total.ast_tx_altrate
, total.ast_tx_shortretry
, total.ast_tx_longretry
, total.ast_tx_xretries
, total.ast_rx_crcerr
, total.ast_rx_badcrypt
, total.ast_rx_phyerr
, total.ast_rx_rssi
, rate
);
}
fflush(stdout);
omask = sigblock(sigmask(SIGALRM));
if (!signalled)
sigpause(0);
sigsetmask(omask);
signalled = 0;
alarm(interval);
line++;
if (line == 21) /* XXX tty line count */
goto banner;
else
goto loop;
/*NOTREACHED*/
} else {
struct ath_stats stats;
ifr.ifr_data = (caddr_t) &stats;
if (ioctl(s, SIOCGATHSTATS, &ifr) < 0)
err(1, ifr.ifr_name);
printstats(stdout, &stats);
}
return 0;
}

300
tools/tools/net80211/wlanstats/wlanstats.c Normal file
View File

@ -0,0 +1,300 @@
/*-
* Copyright (c) 2002, 2003 Sam Leffler, Errno Consulting
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer,
* without modification.
* 2. Redistributions in binary form must reproduce at minimum a disclaimer
* similar to the "NO WARRANTY" disclaimer below ("Disclaimer") and any
* redistribution must be conditioned upon including a substantially
* similar Disclaimer requirement for further binary redistribution.
* 3. Neither the names of the above-listed copyright holders nor the names
* of any contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
* Alternatively, this software may be distributed under the terms of the
* GNU General Public License ("GPL") version 2 as published by the Free
* Software Foundation.
*
* NO WARRANTY
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTIBILITY
* AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
* THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY,
* OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
* IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
* THE POSSIBILITY OF SUCH DAMAGES.
*
* $FreeBSD$
*/
/*
* wlanstats [-i interface]
* (default interface is ath0).
*/
#include <sys/types.h>
#include <sys/file.h>
#include <sys/sockio.h>
#include <sys/socket.h>
#include <net/if.h>
#include <net/if_media.h>
#include <net/if_var.h>
#include <net/ethernet.h>
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <err.h>
#include "../../../../sys/net80211/ieee80211_ioctl.h"
const char *progname;
static void
printstats(FILE *fd, const struct ieee80211_stats *stats)
{
#define N(a) (sizeof(a) / sizeof(a[0]))
#define STAT(x,fmt) \
if (stats->is_##x) fprintf(fd, "%u " fmt "\n", stats->is_##x)
STAT(rx_badversion, "rx frame with bad version");
STAT(rx_tooshort, "rx frame too short");
STAT(rx_wrongbss, "rx from wrong bssid");
STAT(rx_dup, "rx discard 'cuz dup");
STAT(rx_wrongdir, "rx w/ wrong direction");
STAT(rx_mcastecho, "rx discard 'cuz mcast echo");
STAT(rx_notassoc, "rx discard 'cuz sta !assoc");
STAT(rx_noprivacy, "rx w/ wep but privacy off");
STAT(rx_unencrypted, "rx w/o wep and privacy on");
STAT(rx_wepfail, "rx wep processing failed");
STAT(rx_decap, "rx decapsulation failed");
STAT(rx_mgtdiscard, "rx discard mgt frames");
STAT(rx_ctl, "rx discard ctrl frames");
STAT(rx_beacon, "rx beacon frames");
STAT(rx_rstoobig, "rx rate set truncated");
STAT(rx_elem_missing, "rx required element missing");
STAT(rx_elem_toobig, "rx element too big");
STAT(rx_elem_toosmall, "rx element too small");
STAT(rx_elem_unknown, "rx element unknown");
STAT(rx_badchan, "rx frame w/ invalid chan");
STAT(rx_chanmismatch, "rx frame chan mismatch");
STAT(rx_nodealloc, "nodes allocated (rx)");
STAT(rx_ssidmismatch, "rx frame ssid mismatch");
STAT(rx_auth_unsupported,"rx w/ unsupported auth alg");
STAT(rx_auth_fail, "rx sta auth failure");
STAT(rx_auth_countermeasures,
"rx sta auth failure 'cuz of TKIP countermeasures");
STAT(rx_assoc_bss, "rx assoc from wrong bssid");
STAT(rx_assoc_notauth, "rx assoc w/o auth");
STAT(rx_assoc_capmismatch,"rx assoc w/ cap mismatch");
STAT(rx_assoc_norate, "rx assoc w/ no rate match");
STAT(rx_assoc_badwpaie, "rx assoc w/ bad WPA IE");
STAT(rx_deauth, "rx deauthentication");
STAT(rx_disassoc, "rx disassociation");
STAT(rx_badsubtype, "rx frame w/ unknown subtype");
STAT(rx_nobuf, "rx failed for lack of sk_buffer");
STAT(rx_decryptcrc, "rx decrypt failed on crc");
STAT(rx_ahdemo_mgt,
"rx discard mgmt frame received in ahdoc demo mode");
STAT(rx_bad_auth, "rx bad authentication request");
STAT(rx_unauth, "rx discard 'cuz port unauthorized");
STAT(rx_badkeyid, "rx w/ incorrect keyid");
STAT(rx_ccmpreplay, "rx seq# violation (CCMP)");
STAT(rx_ccmpformat, "rx format bad (CCMP)");
STAT(rx_ccmpmic, "rx MIC check failed (CCMP)");
STAT(rx_tkipreplay, "rx seq# violation (TKIP)");
STAT(rx_tkipformat, "rx format bad (TKIP)");
STAT(rx_tkipmic, "rx MIC check failed (TKIP)");
STAT(rx_tkipicv, "rx ICV check failed (TKIP)");
STAT(rx_badcipher, "rx failed 'cuz bad cipher/key type");
STAT(rx_nocipherctx, "rx failed 'cuz key/cipher ctx not setup");
STAT(rx_acl, "rx discard 'cuz acl policy");
STAT(tx_nobuf, "tx failed for lack of sk_buffer");
STAT(tx_nonode, "tx failed for no node");
STAT(tx_unknownmgt, "tx of unknown mgt frame");
STAT(tx_badcipher, "tx failed 'cuz bad ciper/key type");
STAT(tx_nodefkey, "tx failed 'cuz no defkey");
STAT(tx_noheadroom, "tx failed 'cuz no space for crypto hdrs");
STAT(tx_fragframes, "tx frames fragmented");
STAT(tx_frags, "tx frags generated");
STAT(scan_active, "active scans started");
STAT(scan_passive, "passive scans started");
STAT(node_timeout, "nodes timed out inactivity");
STAT(crypto_nomem, "cipher context malloc failed");
STAT(crypto_tkip, "tkip crypto done in s/w");
STAT(crypto_tkipenmic, "tkip tx MIC done in s/w");
STAT(crypto_tkipdemic, "tkip rx MIC done in s/w");
STAT(crypto_tkipcm, "tkip dropped frames 'cuz of countermeasures");
STAT(crypto_ccmp, "ccmp crypto done in s/w");
STAT(crypto_wep, "wep crypto done in s/w");
STAT(crypto_setkey_cipher,"setkey failed 'cuz cipher rejected data");
STAT(crypto_setkey_nokey,"setkey failed 'cuz no key index");
STAT(crypto_delkey, "driver key delete failed");
STAT(crypto_badcipher, "setkey failed 'cuz unknown cipher");
STAT(crypto_nocipher, "setkey failed 'cuz cipher module unavailable");
STAT(crypto_attachfail, "setkey failed 'cuz cipher attach failed");
STAT(crypto_swfallback, "crypto fell back to s/w implementation");
STAT(crypto_keyfail, "setkey failed 'cuz driver key alloc failed");
STAT(crypto_enmicfail, "enmic failed (may be mbuf exhaustion)");
STAT(ibss_capmismatch, "ibss merge faied 'cuz capabilities mismatch");
STAT(ibss_norate, "ibss merge faied 'cuz rate set mismatch");
STAT(ps_unassoc, "ps-poll received for unassociated station");
STAT(ps_badaid, "ps-poll received with invalid association id");
STAT(ps_qempty, "ps-poll received with nothing to send");
STAT(ff_badhdr, "fast frame rx'd w/ bad hdr");
STAT(ff_tooshort, "fast frame rx decap error");
STAT(ff_split, "fast frame rx split error");
STAT(ff_decap, "fast frames decap'd");
STAT(ff_encap, "fast frames encap'd for tx");
#undef STAT
#undef N
}
struct ifreq ifr;
int s;
static void
print_sta_stats(FILE *fd, const u_int8_t macaddr[IEEE80211_ADDR_LEN])
{
#define STAT(x,fmt) \
if (ns->ns_##x) { fprintf(fd, "%s" #x " " fmt, sep, ns->ns_##x); sep = " "; }
struct ieee80211req ireq;
struct ieee80211req_sta_stats stats;
const struct ieee80211_nodestats *ns = &stats.is_stats;
const char *sep;
(void) memset(&ireq, 0, sizeof(ireq));
(void) strncpy(ireq.i_name, ifr.ifr_name, sizeof(ireq.i_name));
ireq.i_type = IEEE80211_IOC_STA_STATS;
ireq.i_data = &stats;
ireq.i_len = sizeof(stats);
memcpy(stats.is_u.macaddr, macaddr, IEEE80211_ADDR_LEN);
if (ioctl(s, SIOCG80211, &ireq) < 0)
err(1, "unable to get station stats for %s",
ether_ntoa((const struct ether_addr*) macaddr));
fprintf(fd, "%s:\n", ether_ntoa((const struct ether_addr*) macaddr));
sep = "\t";
STAT(rx_data, "%u");
STAT(rx_mgmt, "%u");
STAT(rx_ctrl, "%u");
STAT(rx_beacons, "%u");
STAT(rx_proberesp, "%u");
STAT(rx_ucast, "%u");
STAT(rx_mcast, "%u");
STAT(rx_bytes, "%llu");
STAT(rx_dup, "%u");
STAT(rx_noprivacy, "%u");
STAT(rx_wepfail, "%u");
STAT(rx_demicfail, "%u");
STAT(rx_decap, "%u");
STAT(rx_defrag, "%u");
STAT(rx_disassoc, "%u");
STAT(rx_deauth, "%u");
STAT(rx_decryptcrc, "%u");
STAT(rx_unauth, "%u");
STAT(rx_unencrypted, "%u");
fprintf(fd, "\n");
sep = "\t";
STAT(tx_data, "%u");
STAT(tx_mgmt, "%u");
STAT(tx_probereq, "%u");
STAT(tx_ucast, "%u");
STAT(tx_mcast, "%u");
STAT(tx_bytes, "%llu");
STAT(tx_novlantag, "%u");
STAT(tx_vlanmismatch, "%u");
fprintf(fd, "\n");
sep = "\t";
STAT(tx_assoc, "%u");
STAT(tx_assoc_fail, "%u");
STAT(tx_auth, "%u");
STAT(tx_auth_fail, "%u");
STAT(tx_deauth, "%u");
STAT(tx_deauth_code, "%llu");
STAT(tx_disassoc, "%u");
STAT(tx_disassoc_code, "%u");
fprintf(fd, "\n");
#undef STAT
}
int
main(int argc, char *argv[])
{
int c, len;
struct ieee80211req_sta_info *si;
uint8_t buf[24*1024], *cp;
struct ieee80211req ireq;
int allnodes = 0;
progname = argv[0];
s = socket(AF_INET, SOCK_DGRAM, 0);
if (s < 0)
err(1, "socket");
strncpy(ifr.ifr_name, "ath0", sizeof (ifr.ifr_name));
while ((c = getopt(argc, argv, "ai:")) != -1)
switch (c) {
case 'a':
allnodes++;
break;
case 'i':
strncpy(ifr.ifr_name, optarg, sizeof (ifr.ifr_name));
break;
default:
errx(1, "usage: %s [-a] [-i device] [mac...]\n", progname);
/*NOTREACHED*/
}
if (argc == optind && !allnodes) {
struct ieee80211_stats stats;
/* no args, just show global stats */
ifr.ifr_data = (caddr_t) &stats;
if (ioctl(s, SIOCG80211STATS, &ifr) < 0)
err(1, ifr.ifr_name);
printstats(stdout, &stats);
return 0;
}
if (allnodes) {
/*
* Retrieve station/neighbor table and print stats for each.
*/
(void) memset(&ireq, 0, sizeof(ireq));
(void) strncpy(ireq.i_name, ifr.ifr_name, sizeof(ireq.i_name));
ireq.i_type = IEEE80211_IOC_STA_INFO;
ireq.i_data = buf;
ireq.i_len = sizeof(buf);
if (ioctl(s, SIOCG80211, &ireq) < 0)
err(1, "unable to get station information");
len = ireq.i_len;
if (len >= sizeof(struct ieee80211req_sta_info)) {
cp = buf;
do {
si = (struct ieee80211req_sta_info *) cp;
print_sta_stats(stdout, si->isi_macaddr);
cp += si->isi_len, len -= si->isi_len;
} while (len >= sizeof(struct ieee80211req_sta_info));
}
} else {
/*
* Print stats for specified stations.
*/
for (c = optind; c < argc; c++) {
const struct ether_addr *ea = ether_aton(argv[c]);
if (ea != NULL)
print_sta_stats(stdout, ea->octet);
}
}
}

184
usr.bin/netstat/pfkey.c Normal file
View File

@ -0,0 +1,184 @@
/* $FreeBSD$ */
/* $NetBSD: inet.c,v 1.35.2.1 1999/04/29 14:57:08 perry Exp $ */
/* $KAME: ipsec.c,v 1.25 2001/03/12 09:04:39 itojun Exp $ */
/*
* Copyright (C) 1995, 1996, 1997, 1998, and 1999 WIDE Project.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. Neither the name of the project nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
/*
* Copyright (c) 1983, 1988, 1993
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
#include <sys/cdefs.h>
#ifndef lint
/*
static char sccsid[] = "@(#)inet.c 8.5 (Berkeley) 5/24/95";
*/
static const char rcsid[] =
"$FreeBSD$";
#endif /* not lint */
#include <sys/param.h>
#include <sys/queue.h>
#include <sys/socket.h>
#include <netinet/in.h>
#if defined(IPSEC) && !defined(FAST_IPSEC)
#include <netkey/keysock.h>
#endif
#ifdef FAST_IPSEC
#include <netipsec/keysock.h>
#endif
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include "netstat.h"
#ifdef IPSEC
static const char *pfkey_msgtypenames[] = {
"reserved", "getspi", "update", "add", "delete",
"get", "acquire", "register", "expire", "flush",
"dump", "x_promisc", "x_pchange", "x_spdupdate", "x_spdadd",
"x_spddelete", "x_spdget", "x_spdacquire", "x_spddump", "x_spdflush",
"x_spdsetidx", "x_spdexpire", "x_spddelete2"
};
static const char *pfkey_msgtype_names (int);
static const char *
pfkey_msgtype_names(int x)
{
const int max =
sizeof(pfkey_msgtypenames)/sizeof(pfkey_msgtypenames[0]);
static char buf[20];
if (x < max && pfkey_msgtypenames[x])
return pfkey_msgtypenames[x];
snprintf(buf, sizeof(buf), "#%d", x);
return buf;
}
void
pfkey_stats(u_long off, const char *name, int af __unused)
{
struct pfkeystat pfkeystat;
unsigned first, type;
if (off == 0)
return;
printf ("%s:\n", name);
kread(off, (char *)&pfkeystat, sizeof(pfkeystat));
#define p(f, m) if (pfkeystat.f || sflag <= 1) \
printf(m, (unsigned long long)pfkeystat.f, plural(pfkeystat.f))
/* userland -> kernel */
p(out_total, "\t%llu request%s sent from userland\n");
p(out_bytes, "\t%llu byte%s sent from userland\n");
for (first = 1, type = 0;
type < sizeof(pfkeystat.out_msgtype)/sizeof(pfkeystat.out_msgtype[0]);
type++) {
if (pfkeystat.out_msgtype[type] <= 0)
continue;
if (first) {
printf("\thistogram by message type:\n");
first = 0;
}
printf("\t\t%s: %llu\n", pfkey_msgtype_names(type),
(unsigned long long)pfkeystat.out_msgtype[type]);
}
p(out_invlen, "\t%llu message%s with invalid length field\n");
p(out_invver, "\t%llu message%s with invalid version field\n");
p(out_invmsgtype, "\t%llu message%s with invalid message type field\n");
p(out_tooshort, "\t%llu message%s too short\n");
p(out_nomem, "\t%llu message%s with memory allocation failure\n");
p(out_dupext, "\t%llu message%s with duplicate extension\n");
p(out_invexttype, "\t%llu message%s with invalid extension type\n");
p(out_invsatype, "\t%llu message%s with invalid sa type\n");
p(out_invaddr, "\t%llu message%s with invalid address extension\n");
/* kernel -> userland */
p(in_total, "\t%llu request%s sent to userland\n");
p(in_bytes, "\t%llu byte%s sent to userland\n");
for (first = 1, type = 0;
type < sizeof(pfkeystat.in_msgtype)/sizeof(pfkeystat.in_msgtype[0]);
type++) {
if (pfkeystat.in_msgtype[type] <= 0)
continue;
if (first) {
printf("\thistogram by message type:\n");
first = 0;
}
printf("\t\t%s: %llu\n", pfkey_msgtype_names(type),
(unsigned long long)pfkeystat.in_msgtype[type]);
}
p(in_msgtarget[KEY_SENDUP_ONE],
"\t%llu message%s toward single socket\n");
p(in_msgtarget[KEY_SENDUP_ALL],
"\t%llu message%s toward all sockets\n");
p(in_msgtarget[KEY_SENDUP_REGISTERED],
"\t%llu message%s toward registered sockets\n");
p(in_nomem, "\t%llu message%s with memory allocation failure\n");
#undef p
}
#endif /* IPSEC */