mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-30 14:07:59 +00:00
Code Issues Releases Wiki Activity

updated internet drafts

Browse Source
This commit is contained in:
Andreas Gustafsson 2000-04-26 05:25:14 +00:00
parent 6d3c9cdf1a
commit 18657d332b
17 changed files with 275 additions and 4480 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

905
doc/draft/draft-duerst-dns-i18n-02.txt
View File

@ -1,905 +0,0 @@
Internet Draft M. Duerst
<draft-duerst-dns-i18n-02.txt> Keio University
Expires in six months July 1998
Internationalization of Domain Names
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress".
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Distribution of this document is unlimited. Please send comments to
the author at <mduerst@w3.org>.
Abstract
Internet domain names are currently limited to a very restricted
character set. This document proposes the introduction of a new
"zero-level" domain (ZLD) to allow the use of arbitrary characters
from the Universal Character Set (ISO 10646/Unicode) in domain names.
The proposal is fully backwards compatible and does not need any
changes to DNS. Version 02 is reissued without changes just to
keep this draft available.
Table of contents
0. Change History ................................................. 2
0.8 Changes Made from Version 01 to Version 02 .................. 2
0.9 Changes Made from Version 00 to Version 01 .................. 2
1. Introduction ................................................... 3
1.1 Motivation .................................................. 3
Expires End of January 1998 [Page 1]
Internet Draft Internationalization of Domain Names July 1997
1.2 Notational Conventions ...................................... 4
2. The Hidden Zero Level Domain ................................... 4
3. Encoding International Characters .............................. 5
3.1 Encoding Requirements ....................................... 5
3.2 Encoding Definition ......................................... 5
3.3 Encoding Example ............................................ 7
3.4 Length Considerations ....................................... 8
4. Usage Considerations ........................................... 8
4.1 General Usage ............................................... 8
4.2 Usage Restrictions .......................................... 9
4.3 Domain Name Creation ....................................... 10
4.4 Usage in URLs .............................................. 12
5. Alternate Proposals ........................................... 13
5.1 The Dillon Proposal ........................................ 13
5.2 Using a Separate Lookup Service ............................ 13
6. Generic Considerations ........................................ 14
5.1 Security Considerations .................................... 14
5.2 Internationalization Considerations ........................ 14
Acknowledgements ................................................. 14
Bibliography ..................................................... 15
Author's Address .................................................=
16
0. Change History
0.8 Changes Made from Version 01 to Version 02
No significant changes; reissued to make it available officially.
Changed author's address.
Changes deferred to future versions (if ever):
- Decide on ZLD name (.i or .i18n.int or something else)
- Decide on casing solution
- Decide on exact syntax
- Proposals for experimental setup
0.9 Changes Made from Version 00 to Version 01
Expires End of January 1998 [Page 2]
Internet Draft Internationalization of Domain Names July 1997
- Minor rewrites and clarifications
- Added the following references: [RFC1730], [Kle96], [ISO3166],
[iNORM]
- Slightly expanded discussion about casing
- Added some variant proposals for syntax
- Added some explanations about different kinds of name parallelism
- Added some explanation about independent addition of internation-
alized names in subdomains without bothering higher-level domains
- Added some explanations about tools needed for support, and the
MX/CNAME problem
- Change to RFC1123 (numbers allowed at beginning of labels)
1. Introduction
1.1 Motivation
The lower layers of the Internet do not discriminate any language or
script. On the application level, however, the historical dominance
of the US and the ASCII character set [ASCII] as a lowest common
denominator have led to limitations. The process of removing these
limitations is called internationalization (abbreviated i18n). One
example of the abovementioned limitations are domain names [RFC1034,
RFC1035], where only the letters of the basic Latin alphabet (case-
insensitive), the decimal digits, and the hyphen are allowed.
While such restrictions are convenient if a domain name is intended
to be used by arbitrary people around the globe, there may be very
good reasons for using aliases that are more easy to remember or type
in a local context. This is similar to traditional mail addresses,
where both local scripts and conventions and the Latin script can be
used.
There are many good reasons for domain name i18n, and some arguments
that are brought forward against such an extension. This document,
however, does not discuss the pros and cons of domain name i18n. It
proposes and discusses a solution and therefore eliminates one of the
Expires End of January 1998 [Page 3]
Internet Draft Internationalization of Domain Names July 1997
most often heard arguments agains, namely "it cannot be done".
The solution proposed in this document consists of the introduction
of a new "zero-level" domain building the root of a new domain
branch, and an encoding of the Universal Character Set (UCS)
[ISO10646] into the limited character set of domain names.
1.2 Notational Conventions
In the domain name examples in this document, characters of the basic
Latin alphabet (expressible in ASCII) are denoted with lower case
letters. Upper case letters are used to represent characters outside
ASCII, such as accented characters of the Latin alphabet, characters
of other alphabets and syllabaries, ideographic characters, and vari-
ous signs.
2. The Hidden Zero Level Domain
The domain name system uses the domain "in-addr.arpa" to convert
internet addresses back to domain names. One way to view this is to
say that in-addr.arpa forms the root of a separate hierarchy. This
hierarchy has been made part of the main domain name hierarchy just
for implementation convenience. While syntactically, in-addr.arpa is
a second level domain (SLD), functionally it is a zero level domain
(ZLD) in the same way as "." is a ZLD. A similar example of a ZLD is
the domain tpc.int, which provides a hierarchy of the global phone
numbering system [RFC1530] for services such as paging and printing
to fax machines.
For domain name i18n to work inside the tight restrictions of domain
name syntax, one has to define an encoding that maps strings of UCS
characters to strings of characters allowable in domain names, and a
means to distinguish domain names that are the result of such an
encoding from ordinary domain names.
This document proposes to create a new ZLD to distinguish encoded
i18n domain names from traditional domain names. This domain would
be hidden from the user in the same way as a user does not see in-
addr.arpa. This domain could be called "i18n.arpa" (although the use
of arpa in this context is definitely not appropriate), simply
"i18n", or even just "i". Below, we are using "i" for shortness,
while we leave the decision on the actual name to further=
discussion.
Expires End of January 1998 [Page 4]
Internet Draft Internationalization of Domain Names July=
1997
3. Encoding International Characters
3.1 Encoding Requirements
Until quite recently, the thought of going beyond ASCII for something
such as domain names failed because of the lack of a single encom-
passing character set for the scripts and languages of the world.
Tagging techniques such as those used in MIME headers [RFC1522] would
be much too clumsy for domain names.
The definition of ISO 10646 [ISO10646], codepoint by codepoint iden-
tical with Unicode [Unicode], provides a single Universal Character
Set (UCS). A recent report [RFCIAB] clearly recommends to base the
i18n of the Internet on these standards.
An encoding for i18n domain names therefore has to take the charac-
ters of ISO 10646/Unicode as a starting point. The full four-byte
(31 bit) form of UCS, called UCS4, should be used. A limitation to
the two-byte form (UCS2), which allows only for the encoding of the
Base Multilingual Plane, is too restricting.
For the mapping between UCS4 and the strongly limited character set
of domain names, the following constraints have to be considered:
- The structure of domain names, and therefore the "dot", have to be
conserved. Encoding is done for individual labels.
- Individual labels in domain names allow the basic Latin alphabet
(monocase, 26 letters), decimal digits, and the "-" inside the
label. The capacity per octet is therefore limited to somewhat
above 5 bits.
- There is no need nor possibility to preserve any characters.
- Frequent characters (i.e. ASCII, alphabetic, UCS2, in that order)
should be encoded relatively compactly. A variable-length encoding
(similar to UTF-8) seems desirable.
3.2 Encoding Definition
Several encodings for UCS, so called UCS Transform Formats, exist
Expires End of January 1998 [Page 5]
Internet Draft Internationalization of Domain Names July 1997
already, namely UTF-8 [RFC2044], UTF-7 [RFC1642], and UTF-16 [Uni-
code]. Unfortunately, none of them is suitable for our purposes. We
therefore use the following encoding:
- To accommodate the slanted probability distribution of characters
in UCS4, a variable-length encoding is used.
- Each target letter encodes 5 bits of information. Four bits of
information encode character data, the fifth bit is used to indi-
cate continuation of the variable-length encoding.
- Continuation is indicated by distinguishing the initial letter
from the subsequent letter.
- Leading four-bit groups of binary value 0000 of UCS4 characters
are discarded, except for the last TWO groups (i.e. the last
octet). This means that ASCII and Latin-1 characters need two
target letters, the main alphabets up to and including Tibetan
need three target letters, the rest of the characters in the BMP
need four target letters, all except the last (private) plane in
the UTF-16/Surrogates area [Unicode] need five target letters, and
so on.
- The letters representing the various bit groups in the various
positions are chosen according to the following table:
Nibble Value Initial Subsequent
Hex Binary
0 0000 G 0
1 0001 H 1
2 0010 I 2
3 0011 J 3
4 0100 K 4
5 0101 L 5
6 0110 M 6
7 0111 N 7
8 1000 O 8
9 1001 P 9
A 1010 Q A
B 1011 R B
C 1100 S C
D 1101 T D
E 1110 U E
F 1111 V F
[Should we try to eliminate "I" and "O" from initial? "I" might be
Expires End of January 1998 [Page 6]
Internet Draft Internationalization of Domain Names July 1997
eliminated because then an algorithm can more easily detect ".i". "O"
could lead to some confusion with "0". What other protocols are
there that might be able to use a similar solution, but that might
have other restrictions for the initial letters? Proposal to run ini-
tial range from H to X. Extracting the initial bits then becomes ^
'H'. Proposal to have a special convention for all-ASCII labels
(start label with one of the letters not used above).]
Please note that this solution has the following interesting proper-
ties:
- For subsequent positions, there is an equivalence between the hex-
adecimal value of the character code and the target letter used.
This assures easy conversion and checking.
- The absence of digits from the "initial" column, and the fact that
the hyphen is not used, assures that the resulting string conforms
to domain name syntax.
- Raw sorting of encoded and unencoded domain names is equivalent.
- The boundaries of characters can always be detected easily.
(While this is important for representations that are used inter-
nally for text editing, it is actually not very important here,
because tools for editing can be assumed to use a more straight-
forward representation internally.)
- Unless control characters are allowed, the target string will
never actually contain a G.
3.3 Encoding Example
As an example, the current domain
is.s.u-tokyo.ac.jp
with the components standing for information science, science, the
University of Tokyo, academic, and Japan, might in future be repre-
sented by
JOUHOU.RI.TOUDAI.GAKU.NIHON
(a transliteration of the kanji that might probably be chosen to rep-
resent the same domain). Writing each character in U+HHHH notation as
in [Unicode], this results in the following (given for reference
Expires End of January 1998 [Page 7]
Internet Draft Internationalization of Domain Names July 1997
only, not the actual encoding or something being typed in by the
user):
U+60c5U+5831.U+7406.U+6771U+5927.U+5b66.U+65e5U+672c
The software handling internationalized domain names will translate
this, according to the above specifications, before submitting it to
the DNS resolver, to:
M0C5L831.N406.M771L927.LB66.M5E5M72C.i
3.4 Length Considerations
DNS allows for a maximum of 63 positions in each part, and for 255
positions for the overall domain name including dots. This allows up
to 15 ideographs, or up to 21 letters e.g. from the Hebrew or Arabic
alphabet, in a label. While this does not allow for the same margin
as in the case of ASCII domain names, it should still be quite suffi-
cient. [Problems could only surface for languages that use very long
words or terms and don't know any kind of abbreviations or similar
shortening devices. Do these exist? Islandic expert asserted
Islandic is not a problem.] DNS contains a compression scheme that
avoids sending the same trailing portion of a domain name twice in
the same transmission. Long domain names are therefore not that much
of a concern.
4. Usage Considerations
4.1 General Usage
To implement this proposal, neither DNS servers nor resolvers need
changes. These programs will only deal with the encoded form of the
domain name with the .i suffix. Software that wants to offer an
internationalized user interface (for example a web browser) is
responsible for the necessary conversions. It will analyze the domain
name, call the resolver directly if the domain name conforms to the
domain name syntax restrictions, and otherwise encode the name
according to the specifications of Section 3.2 and append the .i suf-
fix before calling the resolver. New implementations of resolvers
will of course offer a companion function to gethostbyname accepting
a ISO10646/Unicode string as input.
Expires End of January 1998 [Page 8]
Internet Draft Internationalization of Domain Names July 1997
For domain name administrators, them main tool that will be needed is
a program to compile files configuring zones from an UTF-8 notation
(or any other suitable encoding) to the encoding described in Section
3.3. Utility tools will include a corresponding decompiler, checkers
for various kinds of internationalization-related errors, and tools
for managing syntactic parallelism (see Section 4.3).
4.2 Usage Restrictions
While this proposal in theory allows to have control characters such
as BEL or NUL or symbols such as arrows and smilies in domain names,
such characters should clearly be excluded from domain names. Whether
this has to be explicitly specified or whether the difficulty to type
these characters on any keyboard of the world will limit their use
has to be discussed. One approach is to start with a very restricted
subset and gradually relax it; the other is to allow almost anything
and to rely on common sense. Anyway, such specifications should go
into a separate document to allow easy updates.
A related point is the question of equivalence. For historical rea-
sons, ISO 10646/Unicode contain considerable number of compatibility
characters and allow more than one representation for characters with
diacritics. To guarantee smooth interoperability in these and related
cases, additional restrictions or the definition of some form of nor-
malization seem necessary. However, this is a general problem
affecting all areas where ISO 10646/Unicode is used in identifiers,
and should therefore be addressed in a generic way. See [iNORM] for
an initial proposal.
Equally related is the problem of case equivalence. Users can very
well distinguish between upper case and lower case. Also, casing in
an i18n context is not as straightforward as for ASCII, so that case
equivalence is best avoided. Problems therefore result not from the
fact that case is distinguished for i18n domain names, but from the
fact that existing domain names do not distinguish case. Where it is
impossible to distinguish between next.com and NeXT.com, the same two
subdomains would easily be distinguishable if subordinate to a i18n
domain. There are several possible solutions. One is to try to grad-
ually migrate from a case-insensitive solution to a case-sensitive
solution even for ASCII. Another is to allow case-sensitivity only
beyond ASCII. Another is to restrict anything beyond ASCII to lower-
case only (lowercase distinguishes better than uppercase, and is also
generally used for ASCII domain names).
A problem that also has to be discussed and solved is bidirectional-
ity. Arabic and Hebrew characters are written right-to-left, and the
Expires End of January 1998 [Page 9]
Internet Draft Internationalization of Domain Names July 1997
mixture with other characters results in a divergence between logical
and graphical sequence. See [HTML-I18N] for more explanations. The
proposal of [Yer96] for dealing with bidirectionality in URLs could
probably be applied to domain names. Anyway, there should be a gen-
eral solution for identifiers, not a DNS-specific solution.
4.3 Domain Name Creation
The ".i" ZLD should be created as such to allow the internationaliza-
tion of domain names. Rules for creating subdomains inside ".i"
should follow the established rules for the creation of functionally
equivalent domains in the existing domain hierarchy, and should
evolve in parallel.
For the actual domain hierarchy, the amount of parallelism between
the current ASCII-oriented hierarchy and some internationalized hier-
archy depends on various factors. In some cases, two fully parallel
hierarchies may emerge. In other cases, if more than one script or
language is used locally, more than two parallel hierarchies may
emerge. Some nodes, e.g. in intranets, may only appear in an i18n
hierarchy, whereas others may only appear in the current hierarchy.
In some cases, the pecularities of scripts, languages, cultures, and
the local marketplace may lead to completely different hierarchies.
Also, one has to be aware that there may be several kinds of paral-
lelisms. The first one is called syntactic parallelism. If there is
a domain XXXX.yy.zz and a domain vvvv.yy.zz, then the domain yy.zz
will have to exist both in the traditional DNS hierarchy as well as
within the hierarchy starting at the .i ZLD, with appropriate encod-
ing.
The second type of parallelism is called transcription parallelism.
It results by transcribing or transliterating relations between ASCII
domain names and domain names in other scripts.
The third type of parallelism is called semantic parallelism. It
results from translating elements of a domain name from one language
to another, possibly also changing the script or set of used charac-
ters.
On the host level, parallelism means that there are two names for the
same host. Conventions should exist to decide whether the parallel
names should have separate IP addresses or not (A record or CNAME
record). With separate IP addresses, address to name lookup is easy,
otherwise it needs special precautions to be able to find all names
corresponding to a given host address. Another detail entering this
Expires End of January 1998 [Page 10]
Internet Draft Internationalization of Domain Names July 1997
consideration is that MX records only work for hostnames/domains,
not for CNAME aliases. This at least has the consequence that alias
resolution for internationalized mail addresses has to occur before
MX record lookup.
When discussing and applying the rules for creating domain names,
some peculiarities of i18n domain names should be carefully consid-
ered:
- Depending on the script, reasonable lengths for domain name parts
may differ greatly. For ideographic scripts, a part may often be
only a one-letter code. Established rules for lengths may need
adaptation. For example, a rule for country TLDs could read: one
ideographic character or two other characters.
- If the number of generic TLDs (.com, .edu, .org, .net) is kept
low, then it may be feasible to restrict i18n TLDs to country
TLDs.
- There are no ISO 3166 [ISO3166] two-letter codes in scripts other
than Latin. I18n domain names for countries will have to be
designed from scratch.
- The names of some countries or regions may pose greater political
problems when expressed in the native script than when expressed
in 2-letter ISO 3166 codes.
- I18n country domain names should in principle only be created in
those scripts that are used locally. There is probably little use
in creating an Arabic domain name for China, for example.
- In those cases where domain names are open to a wide range of
applicants, a special procedure for accepting applications should
be used so that a reasonable-quality fit between ASCII domain
names and i18n domain names results where desired. This would
probably be done by establishing a period of about a month for
applications inside a i18n domain newly created as a parallel for
an existing domain, and resolving the detected conflicts. For
syntactically parallel domain names, the owners should always be
the same. Administration may be split in some cases to account for
the necessary linguistic knowledge. For domain names with tran-
scription parallelism and semantic parallelism, the question of
owner identity should depend on the real-life situation (trade-
marks,...).
- It will be desirable to have internationalized subdomains in non-
internationalized TLDs. As an example, many companies in France
may want to register an accented version of their company name,
Expires End of January 1998 [Page 11]
Internet Draft Internationalization of Domain Names July 1997
while remaining under the .fr TLD. For this, .fr would have to be
reregistered as .M6N2.i. Accented and other internationalized sub-
domains would go below .M6N2.i, whereas unaccented ones would go
below .fr in its plain form.
- To generalize the above case, one may need to create a requirement
that any domain name registry would have to register and manage
syntactically parallel domain names below the .i ZLD upon request
to allow registration of i18n domain names in arbitrary subdo-
mains. An alternative to this is to organize domain name search
so that e.g. in a search for XXXXXX.fr, if M6N2.i is not found in
.i, the name server for .fr is queried for XXXXXX.M6N2.i (with
XXXXXX appropriately encoded). This convention would allow lower-
level domains to introduce internationalized subdomains without
depending on higher-level domains.
4.4 Usage in URLs
According to current definitions, URLs encode sequences of octets
into a sequence of characters from a character set that is almost as
limited as the character set of domain names [RFC1738]. This is
clearly not satisfying for i18n.
Internationalizing URLs, i.e. assigning character semantics to the
encoded octets, can either be done separately for each part and/or
scheme, or in an uniform way. Doing it separately has the serious
disadvantage that software providing user interfaces for URLs in gen-
eral would have to know about all the different i18n solutions of the
different parts and schemes. Many of these solutions may not even be
known yet.
It is therefore definitely more advantageous to decide on a single
and consistent solution for URL internationalization. The most valu-
able candidate [Yer96], for many reasons, is UTF-8 [RFC2044], an
ASCII-compatible encoding of UCS4.
Therefore, an URL containing the domain name of the example of Sec-
tion 3.3 should not be written as:
ftp://M0C5L831.N406.M771L927.LB66.M5E5M72C.i
(although this will also work) but rather
ftp://%e6%83%85%e5%a0%b1.%e7%90%86.%e6%9d%b1%e5%a4%a7.
%e5%ad%a6.%e6%97%a5%e6%9c%ac
Expires End of January 1998 [Page 12]
Internet Draft Internationalization of Domain Names July 1997
In this canonical form, the trailing .i is absent, and the octets can
be reconstructed from the %HH-encoding and interpreted as UTF-8 by
generic URL software. The software part dealing with domain names
will carry out the conversion to the .i form.
5. Alternate Proposals
5.1 The Dillon Proposal
The proposal of Michael Dillon [Dillon96] is also based on encoding
Unicode into the limited character set of domain names. Distinction
is done for each part, using the hyphen in initial position. Because
this does not fully conform to the syntax of existing domain names,
it is questionable whether it is backwards-compatible. On the other
hand, this has the advantage that local i18n domain names can be
installed easily without cooperation by the manager of the superdo-
main.
A variable-length scheme with base 36 is used that can encode up to
1610 characters, absolutely insufficient for Chinese or Japanese.
Characters assumed not to be used in i18n domain names are excluded,
i.e. only one case is allowed for basic Latin characters. This means
that large tables have to be worked out carefully to convert between
ISO 10646/Unicode and the actual number that is encoded with base=
36.
5.2 Using a Separate Lookup Service
Instead of using a special encoding and burdening DNS with i18n, one
could build and use a separate lookup service for i18n domain names.
Instead of converting to UCS4 and encoding according to Section 3.2,
and then calling the DNS resolver, a program would contact this new
service when seeing a domain name with characters outside the allowed
range.
Such solutions have various problems. There are many directory ser-
vices and proposals for how to use them in a way similar to DNS. For
an overview and a specific proposal, see [Kle96]. However, while
there are many proposals, a real service containing the necessary
data and providing the wide installed base and distributed updating
is in DNS does not exist.
Most directory service proposals also do not offer uniqueness.
Defining unique names again for a separate service will duplicate
much of the work done for DNS. If uniqueness is not guaranteed, the
Expires End of January 1998 [Page 13]
Internet Draft Internationalization of Domain Names July 1997
user is bundened with additional selection steps.
Using a separate lookup service for the internationalization of
domain names also results in more complex implementations than the
proposal made in this draft. Contrary to what some people might
expect, the use of a separate lookup service also does not solve a
capacity problem with DNS, because there is no such problem, nor will
one be created with the introduction of i18n domain names.
6. Generic Considerations
6.1 Security Considerations
This proposal is believed not to raise any other security considera-
tions than the current use of the domain name system.
6.2 Internationalization Considerations
This proposal addresses internationalization as such. The main addi-
tional consideration with respect to internationalization may be the
indication of language. However, for concise identifiers such as
domain names, language tagging would be too much of a burden and
would create complex dependencies with semantics.
NOTE -- This section is introduced based on a recommenda-
tion in [RFCIAB]. A similar section addressing internation-
alization should be included in all application level
internet drafts and RFCs.
Acknowledgements
I am grateful in particular to the following persons for their advice
or criticism: Bert Bos, Lori Brownell, Michael Dillon, Donald E.
Eastlake 3rd, David Goldsmith, Larry Masinter, Ryan Moats, Keith
Moore, Thorvardur Kari Olafson, Erik van der Poel, Jurgen Schwertl,
Paul A. Vixie, Francois Yergeau, and others.
Expires End of January 1998 [Page 14]
Internet Draft Internationalization of Domain Names July=
1997
Bibliography
[ASCII] Coded Character Set -- 7-Bit American Standard Code
for Information Interchange, ANSI X3.4-1986.
[Dillon96] M. Dillon, "Multilingual Domain Names", Memra Software
Inc., November 1996 (circulated Dec. 6, 1996 on iahc-
discuss@iahc.org).
[HTML-I18N] F. Yergeau, G. Nicol, G. Adams, and M. Duerst, "Inter-
nationalization of the Hypertext Markup Language",
Work in progress (draft-ietf-html-i18n-05.txt), August
1996.
[iNORM] M. Duerst, "Normalization of Internationalized Identi-
fiers", draft-duerst-i18n-norm-00.txt, July 1997.
[ISO3166] ISO 3166, "Code for the representation of names of
countries", ISO 3166:1993.
[ISO10646] ISO/IEC 10646-1:1993. International standard -- Infor-
mation technology -- Universal multiple-octet coded
character Set (UCS) -- Part 1: Architecture and basic
multilingual plane.
[Kle96] J. Klensin and T. Wolf, Jr., "Domain Names and Company
Name Retrieval", Work in progress (draft-klensin-tld-
whois-01.txt), November 1996.
[RFC1034] P. Mockapetris, "Domain Names - Concepts and Facili-
ties", ISI, Nov. 1987.
[RFC1035] P. Mockapetris, "Domain Names - Implementation and
Specification", ISI, Nov. 1987.
[RFC1522] K. Moore, "MIME (Multipurpose Internet Mail Exten-
sions) Part Two: Message Header Extensions for Non-
ASCII Text", University of Tennessee, September 1993.
[RFC1642] D. Goldsmith, M. Davis, "UTF-7: A Mail-safe Transfor-
mation Format of Unicode", Taligent Inc., July 1994.
[RFC1730] C. Malamud and M. Rose, "Principles of Operation for
the TPC.INT Subdomain: General Principles and Policy",
Internet Multicasting Service, October 1993.
[RFC1738] T. Berners-Lee, L. Masinter, and M. McCahill,
"Uniform Resource Locators (URL)", CERN, Dec. 1994.
Expires End of January 1998 [Page 15]
Internet Draft Internationalization of Domain Names July 1997
[RFC2044] F. Yergeau, "UTF-8, A Transformation Format of Unicode
and ISO 10646", Alis Technologies, October 1996.
[RFCIAB] C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R.
Atkinson, M. Crispin, P. Svanberg, "Report from the
IAB Character Set Workshop", October 1996 (currently
available as draft-weider-iab-char-wrkshop-00.txt).
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
2.0", Addison-Wesley, Reading, MA, 1996.
[Yer96] F. Yergeau, "Internationalization of URLs", Alis Tech-
nologies,
=
<http://www.alis.com:8085/~yergeau/url-00.html>.
Author's Address
Martin J. Duerst
World Wide Web Consortium
Keio Research Institute at SFC
Keio University
5322 Endo
Fujisawa
252-8520 Japan
Tel: +81 466 49 11 70
E-mail: mduerst@w3.org
NOTE -- Please write the author's name with u-Umlaut wherever
possible, e.g. in HTML as D&uuml;rst.
Expires End of January 1998 [Page 16]

5
doc/draft/draft-duerst-dns-i18n-03.txt Normal file
View File

@ -0,0 +1,5 @@
This Internet-Draft has expired and is no longer available.
Unrevised documents placed in the Internet-Drafts directories have a
maximum life of six months. After that time, they must be updated, or
they will be deleted. This document was deleted on March 20, 2000.

204
doc/draft/draft-ietf-dnsext-sig-zero-00.txt → doc/draft/draft-ietf-dnsext-sig-zero-01.txt
View File

@ -1,24 +1,23 @@
INTERNET-DRAFT Donald E. Eastlake 3rd
UPDATES RFC 2535 Motorola
Expires: September 2000 March 2000
Expires: October 2000 April 2000
DNS Request and Transaction Signatures ( SIG(0)s )
--- ------- --- ----------- ---------- - ------- -
draft-ietf-dnsext-sig-zero-00.txt
<draft-ietf-dnsext-sig-zero-01.txt>
Status of This Document
This draft, file name draft-ietf-dnsext-sig-zero-00.txt, is intended
to become a Proposed Standard RFC updating Proposed Standard [RFC
2535]. Distribution of this document is unlimited. Comments should
be sent to the DNS Working Group mailing list
<namedroppers@internic.net> or to the author. [This is the successor
to draft-ietf-dnsind-sig-zero-01.txt.]
This draft is intended to become a Proposed Standard RFC updating
Proposed Standard [RFC 2535]. Distribution of this document is
unlimited. Comments should be sent to the DNS Working Group mailing
list <namedroppers@internic.net> or to the author.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
@ -26,10 +25,11 @@ Status of This Document
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."
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
@ -57,7 +57,7 @@ Abstract
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT DNS SIG(0) March 2000
INTERNET-DRAFT DNS SIG(0) April 2000
Acknowledgments
@ -67,6 +67,7 @@ Acknowledgments
acknowledged:
Olafur Gudmundsson
Ed Lewis
Brian Wellington
@ -111,11 +112,10 @@ Table of Contents
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT DNS SIG(0) March 2000
INTERNET-DRAFT DNS SIG(0) April 2000
1. Introduction
@ -127,8 +127,8 @@ INTERNET-DRAFT DNS SIG(0) March 2000
transactions / responses. Such a resource record, because it has a
type covered field of zero, is frequently called a SIG(0). The
changes are based on implementation and attempted implementation
experience with TSIG [draft-ietf-{dnsind|dnsext}-tsig-*.txt] and the
[RFC 2535] specification for SIG(0).
experience with TSIG [draft-ietf-dnsext-tsig-*.txt] and the [RFC
2535] specification for SIG(0).
Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2
and 4.3. No changes are made herein related to the KEY or NXT RRs or
@ -143,17 +143,14 @@ INTERNET-DRAFT DNS SIG(0) March 2000
2. SIG(0) Design Rationale
The authenticated data origin and data existence denial services of
secure DNS protect only regular data resource records (RRs) or
authenticatably deny their nonexistence. These services provide no
protection for glue records, DNS requests, no protection for message
headers on requests or responses, and no protection of the overall
integrity of a response.
If header bits are falsely set or the like by a bad server, there is
little that can be done. However, it is possible to add transaction
and query authentication to be sure that queries and responses and
not tampered with in transit.
SIG(0) provides protection for DNS transactions and requests that is
not provided by the regular SIG, KEY, and NXT RRs specified in [RFC
2535]. The authenticated data origin services of secure DNS either
provide protected data resource records (RRs) or authenticatably deny
their nonexistence. These services provide no protection for glue
records, DNS requests, no protection for message headers on requests
or responses, and no protection of the overall integrity of a
response.
@ -161,19 +158,22 @@ INTERNET-DRAFT DNS SIG(0) March 2000
Transaction authentication means that a requester can be sure it is
at least getting the messages from the server it queried and that the
response is from the request it sent (i.e., that these messages have
not been diddled in transit). This is accomplished by optionally
adding either a TSIG RR [draft-ietf-{dnsind|dnsext}-tsig-*.txt] or,
as described herein, a SIG(0) resource record at the end of the
response which digitally signs the concatenation of the server's
response and the corresponding resolver query.
received messages are in response to me query it sent. This is
accomplished by optionally adding either a TSIG RR [draft-ietf-
dnsext-tsig-*.txt] or, as described herein, a SIG(0) resource record
at the end of the response which digitally signs the concatenation of
the server's response and the corresponding resolver query.
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT DNS SIG(0) March 2000
INTERNET-DRAFT DNS SIG(0) April 2000
2.2 Request Authentication
@ -214,43 +214,41 @@ INTERNET-DRAFT DNS SIG(0) March 2000
Because TSIG involves secret keys installed at both the requester and
server the presence of such a key implies that the other party
understands TSIG and likely has the same key installed. Furthermore,
TSIG uses keyed hash authentication codes which are relatively
inexpensive to compute. Thus it is common to authenticate requests
with TSIG and responses are authenticated with TSIG if the
understands TSIG and very likely has the same key installed.
Furthermore, TSIG uses keyed hash authentication codes which are
relatively inexpensive to compute. Thus it is common to authenticate
requests with TSIG and responses are authenticated with TSIG if the
corresponding request is authenticated.
SIG(0) on the other hand, uses public key authentication, where the
public keys are stored in DNS as KEY RRs. Thus, existence of such a
KEY RR does not necessarily imply implementation of SIG(0). In
addition, SIG(0) involves relatively expensive public key
cryptographic operations that should be minimized and the
verification of a SIG(0) involves obtaining and verifying the
public keys are stored in DNS as KEY RRs and a private key is stored
at the signer. Existence of such a KEY RR does not necessarily imply
implementation of SIG(0). In addition, SIG(0) involves relatively
expensive public key cryptographic operations that should be
minimized and the verification of a SIG(0) involves obtaining and
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT DNS SIG(0) March 2000
INTERNET-DRAFT DNS SIG(0) April 2000
corresponding KEY which can be an expensive and lengthy operation.
Indeed, a policy of using SIG(0) on all requests and verifying it
before responding would, for some configurations, lead to a deadly
embrace with the attempt to obtain and verify the KEY needed to
authenticate the request SIG(0) resulting in additional requests
accompanied by a SIG(0) leading to further requests accompanied by a
SIG(0), etc. Furthermore, omitting SIG(0)s when not required on
requests halves the number of public key operations required by the
transaction.
verifying the corresponding KEY which can be an expensive and lengthy
operation. Indeed, a policy of using SIG(0) on all requests and
verifying it before responding would, for some configurations, lead
to a deadly embrace with the attempt to obtain and verify the KEY
needed to authenticate the request SIG(0) resulting in additional
requests accompanied by a SIG(0) leading to further requests
accompanied by a SIG(0), etc. Furthermore, omitting SIG(0)s when not
required on requests halves the number of public key operations
required by the transaction.
For these reasons, SIG(0)s SHOULD only be used on requests when
necessary to authenticate that the requester has some required
privilege or identity. SIG(0)s on replies are defined in such a way
as to not require a SIG(0) on the corresponding request and still
provide transaction protection. Some responses, such as those
involving TKEY [draft-ietf-dnsext-tkey-*.txt], MUST be authenticated
with TSIG or SIG(0). For other replies, whether they are
provide transaction protection. For other replies, whether they are
authenticated by the server or required to be authenticated by the
requester SHOULD be a local configuration option.
@ -265,14 +263,15 @@ INTERNET-DRAFT DNS SIG(0) March 2000
2535] and this document concerning SIG(0) RRs should be resolved in
favor of this document.
For all transaction SIG(0)s, the signer field MUST be the name of the
originating server host and there MUST be a KEY RR at that name with
the public key corresponding to the private key used to calculate the
signature. (The inverse IP address mapping name for an IP address of
the server MAY be used if the relevant KEY is stored there.)
For all transaction SIG(0)s, the signer field MUST be a name of the
originating host and there MUST be a KEY RR at that name with the
public key corresponding to the private key used to calculate the
signature. (The host domain name used may be the inverse IP address
mapping name for an IP address of the host if the relevant KEY is
stored there.)
For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are
meaningless. The TTL fields SHOULD be zero and the CLASS filed
meaningless. The TTL fields SHOULD be zero and the CLASS field
SHOULD be ANY. To conserve space, the owner name SHOULD be root (a
single zero octet). When SIG(0) authentication on a response is
desired, that SIG RR must be considered the highest priority of any
@ -286,32 +285,29 @@ INTERNET-DRAFT DNS SIG(0) March 2000
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT DNS SIG(0) March 2000
INTERNET-DRAFT DNS SIG(0) April 2000
3.1 Calculating Request and Transaction SIGs
A DNS request may be optionally signed by including one or more
SIG(0)s at the end of the query additional information section. Such
SIGs are identified by having a "type covered" field of zero. They
sign the preceding DNS request message including DNS header but not
including the UDP/IP header or any request SIG(0)s at the end and
before the request RR counts have been adjusted for the inclusions of
any request SIG(0)s.
A DNS request may be optionally signed by including one SIG(0)s at
the end of the query additional information section. Such a SIG is
identified by having a "type covered" field of zero. It signs the
preceding DNS request message including DNS header but not including
the UDP/IP header and before the request RR counts have been adjusted
for the inclusions of the request SIG(0).
Note: requests and response can either have a single TSIG or one or
more SIG(0)s but not both a TSIG and a SIG(0).
It is calculated by using a "data" (see [RFC 2535], Section 4.1.8) of
(1) the SIG's RDATA section omitting the signature subfield itself,
(2) the entire DNS query messages, including DNS header, but not the
UDP/IP header and before the reply RR counts have been adjusted for
the inclusion of the SIG(0). That is
They are calculated by using a "data" (see [RFC 2535], Section 4.1.8)
of (1) the SIG's RDATA section omitting the signature subfield
itself, (2) the entire DNS query messages, including DNS header, but
not the UDP/IP header or any SIG(0) and before the reply RR counts
have been adjusted for the inclusion of any SIG(0). That is
data = RDATA | request - SIG(0)s
data = RDATA | request - SIG(0)
where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
calculated less the signature itself.
@ -320,14 +316,14 @@ INTERNET-DRAFT DNS SIG(0) March 2000
that produced it. Such transaction signatures are calculated by
using a "data" of (1) the SIG's RDATA section omitting the signature
itself, (2) the entire DNS query message that produced this response,
including the query's DNS header and any SIG(0)s but not its UDP/IP
header, and (3) the entire DNS response message, including DNS header
but not the UDP/IP header or any SIG(0) and before the response RR
counts have been adjusted for the inclusion of any SIG(0).
including the query's DNS header but not its UDP/IP header, and (3)
the entire DNS response message, including DNS header but not the
UDP/IP header and before the response RR counts have been adjusted
for the inclusion of the SIG(0).
That is
data = RDATA | full query | response - SIG(0)s
data = RDATA | full query | response - SIG(0)
where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
calculated less the signature itself.
@ -342,24 +338,28 @@ INTERNET-DRAFT DNS SIG(0) March 2000
packet is calculated with "data" as above and for each subsequent
packet, it is calculated as follows:
data = RDATA | DNS payload - SIG(0) | previous packet
where "|" is concatenations, RDATA is as above, and previous packet
is the previous DNS payload including DNS header and the SIG(0) but
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT DNS SIG(0) March 2000
INTERNET-DRAFT DNS SIG(0) April 2000
data = RDATA | DNS payload - SIG(0)s | previous packet
where "|" is concatenations, RDATA is as above, and previous packet
is the previous DNS payload including DNS header and any SIG(0)s but
not the TCP/IP header. Support of SIG(0) for TCP is OPTIONAL. As an
alternative, TSIG may be used after, if necessary, setting up a key
with TKEY [draft-ietf-dnsext-tkey-*.txt].
Except where needed to authenticate an update, TKEY, or similar
privileged request, servers are not required to check request SIGs.
privileged request, servers are not required to check a request
SIG(0).
Note: requests and response can either have a single TSIG or one
SIG(0) but not both a TSIG and a SIG(0).
@ -373,7 +373,7 @@ INTERNET-DRAFT DNS SIG(0) March 2000
mode in use. For all other responses, it MAY be checked and the
message rejected if the checks fail.
If a response SIG(0) checks succeed, such a transaction
If a responses SIG(0) check succeed, such a transaction
authentication SIG does NOT directly authenticate the validity any
data-RRs in the message. However, it authenticates that they were
sent by the queried server and have not been diddled. (Only a proper
@ -405,7 +405,7 @@ INTERNET-DRAFT DNS SIG(0) March 2000
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT DNS SIG(0) March 2000
INTERNET-DRAFT DNS SIG(0) April 2000
The inclusion of the SIG(0) inception and expiration time under the
@ -415,7 +415,8 @@ INTERNET-DRAFT DNS SIG(0) March 2000
5. IANA Considerations
No new fields are created or field values assigned by the document.
No new parameters are created or parameter values assigned by the
document.
@ -433,13 +434,12 @@ References
[RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
[draft-ietf-{dnsind|dnsext}-tsig-*.txt] - P. Vixie, O. Gudmundsson,
D. Eastlake, B. Wellington, "Secret Key Transaction Signatures for
DNS (TSIG)".
[draft-ietf-dnsext-tsig-*.txt] - P. Vixie, O. Gudmundsson, D.
Eastlake, B. Wellington, "Secret Key Transaction Signatures for DNS
(TSIG)".
[draft-ietf-dnsext-tkey-*.txt] - D. Eastlake, "Secret Key
Establishment for DNS (RR)"
Establishment for DNS (RR)".
@ -463,7 +463,7 @@ References
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT DNS SIG(0) March 2000
INTERNET-DRAFT DNS SIG(0) April 2000
Author's Address
@ -483,9 +483,9 @@ Author's Address
Expiration and File Name
This draft expires September 2000.
This draft expires October 2000.
Its file name is draft-ietf-dnsext-sig-zero-00.txt.
Its file name is draft-ietf-dnsext-sig-zero-01.txt.

277
doc/draft/draft-ietf-dnsext-tkey-01.txt → doc/draft/draft-ietf-dnsext-tkey-02.txt
View File

@ -1,24 +1,22 @@
DNSEXT Working Group Donald E. Eastlake, 3rd
INTERNET-DRAFT Motorola
Expires: September 2000 March 2000
Expires: October 2000 April 2000
Secret Key Establishment for DNS (TKEY RR)
------ --- ------------- --- --- ----- ---
draft-ietf-dnsext-tkey-01.txt
Donald E. Eastlake 3rd
<draft-ietf-dnsext-tkey-02.txt>
Status of This Document
This draft, file name draft-ietf-dnsext-tkey-01.txt, is intended to
be become a Proposed Standard RFC. Distribution of this document is
unlimited. Comments should be sent to the DNS working group mailing
list <namedroppers@ops.ietf.org> or to the author.
This draft is intended to be become a Proposed Standard RFC.
Distribution of this document is unlimited. Comments should be sent
to the DNS working group mailing list <namedroppers@ops.ietf.org> or
to the author.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
@ -26,10 +24,11 @@ Status of This Document
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."
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
@ -55,21 +54,21 @@ Status of This Document
Donald E. Eastlake 3rd [Page 1]
Donald Eastlake 3rd [Page 1]
INTERNET-DRAFT The DNS TKEY RR March 2000
INTERNET-DRAFT The DNS TKEY RR April 2000
Abstract
[draft-ietf-{dnsind|dnsext}-tsig-*.txt] provides a means of
authenticating Domain Name System (DNS) queries and responses using
shared secret keys via the TSIG resource record (RR). However, it
provides no mechanism for setting up such keys other than manual
exchange. This document describes a TKEY RR that can be used in a
number of different modes to establish shared secret keys between a
DNS resolver and server.
[draft-ietf-dnsext-tsig-*.txt] provides a means of authenticating
Domain Name System (DNS) queries and responses using shared secret
keys via the TSIG resource record (RR). However, it provides no
mechanism for setting up such keys other than manual exchange. This
document describes a TKEY RR that can be used in a number of
different modes to establish shared secret keys between a DNS
resolver and server.
@ -113,10 +112,10 @@ Acknowledgments
Donald E. Eastlake 3rd [Page 2]
Donald Eastlake 3rd [Page 2]
INTERNET-DRAFT The DNS TKEY RR March 2000
INTERNET-DRAFT The DNS TKEY RR April 2000
Table of Contents
@ -148,7 +147,6 @@ Table of Contents
4.5 Query for Resolver Assigned Keying....................12
5. Spontaneous Server Inclusion...........................13
5.1 Spontaneous Server Key Deletion.......................13
5.2 Spontaneous GSS-API Exchange..........................14
6. Methods of Encryption..................................14
7. IANA Considerations....................................14
8. Security Considerations................................15
@ -171,10 +169,11 @@ Table of Contents
Donald E. Eastlake 3rd [Page 3]
Donald Eastlake 3rd [Page 3]
INTERNET-DRAFT The DNS TKEY RR March 2000
INTERNET-DRAFT The DNS TKEY RR April 2000
1. Introduction
@ -186,12 +185,12 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
security and dynamic update [RFC 2535, RFC 2136]. Familiarity with
these RFCs is assumed.
[draft-ietf-{dnsind|dnsext}-tsig-*.txt] provides a means of
efficiently authenticating DNS messages using shared secret keys via
the TSIG resource record (RR) but provides no mechanism for setting
up such keys other than manual exchange. This document specifies a
TKEY RR that can be used in a number of different modes to establish
and delete such shared secret keys between a DNS resolver and server.
[draft-ietf-dnsext-tsig-*.txt] provides a means of efficiently
authenticating DNS messages using shared secret keys via the TSIG
resource record (RR) but provides no mechanism for setting up such
keys other than manual exchange. This document specifies a TKEY RR
that can be used in a number of different modes to establish and
delete such shared secret keys between a DNS resolver and server.
Note that TKEY established keying material and TSIGs that use it are
associated with DNS servers or resolvers. They are not associated
@ -229,13 +228,13 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
Section 5 discusses spontaneous inclusion of TKEY RRs in responses by
Donald E. Eastlake 3rd [Page 4]
Donald Eastlake 3rd [Page 4]
INTERNET-DRAFT The DNS TKEY RR March 2000
INTERNET-DRAFT The DNS TKEY RR April 2000
servers.
servers which is currently used only for key deletion.
Section 6 describes encryption methods for transmitting secret key
information. In this document these are used only for the server
@ -287,10 +286,10 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
For a TKEY with a non-root name appearing in a query, the TKEY RR
Donald E. Eastlake 3rd [Page 5]
Donald Eastlake 3rd [Page 5]
INTERNET-DRAFT The DNS TKEY RR March 2000
INTERNET-DRAFT The DNS TKEY RR April 2000
name SHOULD be a domain locally unique at the resolver, less than 128
@ -305,30 +304,30 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
its owner name, then the server SHOULD create a globally unique
domain name, to be the key name, by suffixing a pseudo-random
[RFC 1750] label with a domain name of the server. For example
89n3mDgX072pp.server.example.com. If generation of a new
89n3mDgX072pp.server1.example.com. If generation of a new
pseudo-random name in each case is an excessive computation load
or entropy drain, a serial number prefix can be added to a fixed
pseudo-random name generated an DNS server start time, such as
1001.89n3mDgX072pp.server.example.com.
1001.89n3mDgX072pp.server1.example.com.
If the key is generated as the result of a query with a non-root
name, say 789.resolver.example.net, then use the concatenation
of that with a name of the server. For example
789.resolver.example.net.server.example.com.
789.resolver.example.net.server1.example.com.
2.2 The TTL Field
The TTL field is meaningless. It SHOULD always be zero to be sure
that older DNS implementations do not cache TKEY RRs.
The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to
be sure that older DNS implementations do not cache TKEY RRs.
2.3 The Algorithm Field
The algorithm name is in the form of a domain name with the same
meaning as in [draft-ietf-{dnsind|dnsext}-tsig-*.txt]. The algorithm
meaning as in [draft-ietf-dnsext-tsig-*.txt]. The algorithm
determines how the secret keying material agreed to using the TKEY RR
is actually used to derive the algorithm specific key.
@ -345,10 +344,10 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
material provided.
Donald E. Eastlake 3rd [Page 6]
Donald Eastlake 3rd [Page 6]
INTERNET-DRAFT The DNS TKEY RR March 2000
INTERNET-DRAFT The DNS TKEY RR April 2000
To avoid different interpretations of the inception and expiration
@ -403,10 +402,10 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
possible if a TKEY is spontaneously included in a response the TKEY
Donald E. Eastlake 3rd [Page 7]
Donald Eastlake 3rd [Page 7]
INTERNET-DRAFT The DNS TKEY RR March 2000
INTERNET-DRAFT The DNS TKEY RR April 2000
RR and DNS header error field could have unrelated non-zero error
@ -418,7 +417,7 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
The key data size field is an unsigned 16 bit integer in network
order which specifies the size of the key exchange data field in
octets. The meaning of the key data depends on the mode.
octets. The meaning of this data depends on the mode.
@ -461,10 +460,10 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
Donald E. Eastlake 3rd [Page 8]
Donald Eastlake 3rd [Page 8]
INTERNET-DRAFT The DNS TKEY RR March 2000
INTERNET-DRAFT The DNS TKEY RR April 2000
TKEY queries MUST be authenticated for all modes except GSS-API and,
@ -478,6 +477,9 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
a public (SIG(0)) key signature. It MUST NOT use any key that the
query is itself providing.
In the absence of required TKEY authentication, a NOTAUTH error MUST
be returned.
To avoid replay attacks, it is necessary that a TKEY response or
query not be valid if replayed on the order of 2**32 second (about
136 years), or a multiple thereof, later. To accomplish this, the
@ -514,17 +516,17 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
the additional information section specifying the Diffie-Hellman mode
and accompanied by a KEY RR also in the additional information
section specifying a resolver Diffie-Hellman key. The TKEY RR
Donald Eastlake 3rd [Page 9]
INTERNET-DRAFT The DNS TKEY RR April 2000
algorithm field is set to the authentication algorithm the resolver
plans to use. The "key data" provided in the TKEY is used as a random
[RFC 1750] nonce to avoid always deriving the same keying material
Donald E. Eastlake 3rd [Page 9]
INTERNET-DRAFT The DNS TKEY RR March 2000
for the same pair of DH KEYs.
The server response contains a TKEY in its answer section with the
@ -572,17 +574,17 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
toss keys, although it may have to go through another key exchange if
it later needs one. Similarly, the server can discard keys although
that will result in an error on receiving a query with a TSIG using
Donald Eastlake 3rd [Page 10]
INTERNET-DRAFT The DNS TKEY RR April 2000
the discarded key.
To avoid attempted reliance in requests on keys no longer in effect,
Donald E. Eastlake 3rd [Page 10]
INTERNET-DRAFT The DNS TKEY RR March 2000
servers MUST implement key deletion whereby the server "discards" a
key on receipt from a resolver of an authenticated delete request for
a TKEY RR with the key's name. If the server has no record of a key
@ -605,8 +607,7 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
should be seen for the full description. Basically the resolver and
server can exchange queries and responses for type TKEY with a TKEY
RR specifying the GSS-API mode in the additional information section
and a GSS-API token in the key data portion of the TKEY RR. See also
section 5.2.
and a GSS-API token in the key data portion of the TKEY RR.
Any issues of possible encryption of parts the GSS-API token data
being transmitted are handled by the GSS-API level. In addition, the
@ -631,23 +632,23 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
algorithm the resolver plans to use. It is RECOMMENDED that any "key
data" provided in the query TKEY RR by the resolver be strongly mixed
by the server with server generated randomness [RFC 1750] to derive
the keying material to be used. The KEY RR that appears in the query
need not be accompanied by a SIG(KEY) RR. If the query is
Donald E. Eastlake 3rd [Page 11]
Donald Eastlake 3rd [Page 11]
INTERNET-DRAFT The DNS TKEY RR March 2000
INTERNET-DRAFT The DNS TKEY RR April 2000
authenticated by the resolver with a TSIG RR [draft-ietf-
{dnsind|dnsext}-tsig-*.txt] or SIG(0) RR and that authentication is
verified, then any SIG(KEY) provided in the query SHOULD be ignored.
The KEY RR in such a query SHOULD have a name that corresponds to the
resolver but it is only essential that it be a public key for which
the resolver has the corresponding private key so it can decrypt the
response data.
the keying material to be used. The KEY RR that appears in the query
need not be accompanied by a SIG(KEY) RR. If the query is
authenticated by the resolver with a TSIG RR [draft-ietf-dnsext-
tsig-*.txt] or SIG(0) RR and that authentication is verified, then
any SIG(KEY) provided in the query SHOULD be ignored. The KEY RR in
such a query SHOULD have a name that corresponds to the resolver but
it is only essential that it be a public key for which the resolver
has the corresponding private key so it can decrypt the response
data.
The server response contains a TKEY RR in its answer section with the
server assigned mode and echoes the KEY RR provided in the query in
@ -689,19 +690,19 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
section. The name of the key and the keying data are completely
controlled by the sending resolver so a globally unique key name
SHOULD be used. The KEY RR used MUST be one for which the server has
the corresponding private key, or it will not be able to decrypt the
keying material and will return a FORMERR, and no untrusted party
Donald E. Eastlake 3rd [Page 12]
Donald Eastlake 3rd [Page 12]
INTERNET-DRAFT The DNS TKEY RR March 2000
INTERNET-DRAFT The DNS TKEY RR April 2000
(preferably no other party than the server) has the private key, or
the untrusted private key holder can capture the messages to the
server, learn the shared secret, and spoof valid TSIGs.
the corresponding private key, or it will not be able to decrypt the
keying material and will return a FORMERR, and for which no untrusted
party (preferably no other party than the server) has the private
key, or the untrusted private key holder can capture the messages to
the server, learn the shared secret, and spoof valid TSIGs.
The query TKEY RR inception and expiry give the time period the
querier intends to consider the keying material valid. The server
@ -720,16 +721,17 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
A DNS server may include a TKEY RR spontaneously as additional
information in responses. This SHOULD only be done if the server
knows the querier understands TKEY and has this option implemented.
This technique can be used for GSS-API exchange, and to delete a key.
A disadvantage of this technique is that there is no way for the
server to get any error or success indication back and, in the case
of UDP, no way to even know if the DNS response reached the resolver.
This technique can be used to delete a key and may be specified for
modes defined in the future. A disadvantage of this technique is
that there is no way for the server to get any error or success
indication back and, in the case of UDP, no way to even know if the
DNS response reached the resolver.
5.1 Spontaneous Server Key Deletion
A server can optionally tell a client that it has deleted a symmetric
A server can optionally tell a client that it has deleted a secret
key by spontaneously including a TKEY RR in the additional
information section of a response with the key's name and specifying
the key deletion mode. Such a response SHOULD be authenticated. If
@ -748,28 +750,10 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
Donald E. Eastlake 3rd [Page 13]
Donald Eastlake 3rd [Page 13]
INTERNET-DRAFT The DNS TKEY RR March 2000
5.2 Spontaneous GSS-API Exchange
A server can spontaneously include in the additional information
section of a response, a GSS-API mode TKEY RR. The information in
the key data section of such a TKEY is a GSS-API token which SHOULD
be fed by the resolver to its local GSS-API implementation. If such
a response is authenticated, the authentication MAY be verify before
processing the data. To the extent that GSS-API provides its own
security, such a response need not be authenticated. To the extent
that GSS-API handles duplicated messages, such a spontaneous TKEY
could be sent repeatedly, until, for example, a response via a GSS-
API mode TKEY query is received. See also section 4.3.
INTERNET-DRAFT The DNS TKEY RR April 2000
6. Methods of Encryption
@ -788,16 +772,17 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
symmetric algorithms.
If the KEY RR specifies the RSA algorithm, then the keying material
is encrypted as per the description of RSA encryption in PKCS#1 [RFC
2437]. (Note, the secret keying material being sent is directly RSA
encrypted in PKCS#1 format, It is not "enveloped" under some other
symmetric algorithm.) In the unlikely event that the keying material
will not fit within one RSA modulus of the chosen public key,
additional RSA encryption blocks are included. The length of each
block is clear from the public RSA key specified and the PKCS#1
padding makes it clear what part of the encrypted data is actually
keying material and what part is formatting or the required at least
eight bytes of random [RFC 1750] padding.
is encrypted as per the description of RSAES-PKCS1-v1_5 encryption in
PKCS#1 [RFC 2437]. (Note, the secret keying material being sent is
directly RSA encrypted in PKCS#1 format. It is not "enveloped" under
some other symmetric algorithm.) In the unlikely event that the
keying material will not fit within one RSA modulus of the chosen
public key, additional RSA encryption blocks are included. The
length of each block is clear from the public RSA key specified and
the RSAES-PKCS1-v1_5 padding makes it clear what part of the
encrypted data is actually keying material and what part is
formatting or the required at least eight bytes of random [RFC 1750]
padding.
@ -807,14 +792,6 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
Mode field values 0x0000 through 0x00FF, and 0XFF00 through 0XFFFF
can only be assigned by an IETF standards action. Special
Donald E. Eastlake 3rd [Page 14]
INTERNET-DRAFT The DNS TKEY RR March 2000
consideration should be given before the allocation of meaning for
Mode field values 0x0000 and 0xFFFF.
@ -829,6 +806,14 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
Standard should not be changed later just because that standard's
status is changed to Proposed.
Donald Eastlake 3rd [Page 14]
INTERNET-DRAFT The DNS TKEY RR April 2000
The following assignments are documented herein:
RR Type 249 for TKEY.
@ -844,7 +829,7 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
The entirety of this specification is concerned with the secure
establishment of a shared secret between DNS clients and servers in
support of TSIG.
support of TSIG [draft-ietf-dnsext-tsig-*.txt].
Protection against denial of service via the use of TKEY is not
provided.
@ -867,10 +852,24 @@ INTERNET-DRAFT The DNS TKEY RR March 2000
Donald E. Eastlake 3rd [Page 15]
Donald Eastlake 3rd [Page 15]
INTERNET-DRAFT The DNS TKEY RR March 2000
INTERNET-DRAFT The DNS TKEY RR April 2000
References
@ -917,7 +916,7 @@ References
RFC 2539 - D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
Name System (DNS)", March 1999.
draft-ietf-{dnsind|dnsext}-tsig-*.txt - P. Vixie, O. Gudmundsson, D.
draft-ietf-dnsext-tsig-*.txt - P. Vixie, O. Gudmundsson, D.
Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)".
@ -925,10 +924,10 @@ References
Donald E. Eastlake 3rd [Page 16]
Donald Eastlake 3rd [Page 16]
INTERNET-DRAFT The DNS TKEY RR March 2000
INTERNET-DRAFT The DNS TKEY RR April 2000
Author's Address
@ -940,16 +939,16 @@ Author's Address
Telephone: +1 914-276-2668 (h)
+1 508-261-5434 (w)
FAX: +1 914-276-2947 (h)
FAX: +1 508-261-4447 (w)
email: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires August 2000.
This draft expires October 2000.
Its file name is draft-ietf-dnsext-tkey-01.txt.
Its file name is draft-ietf-dnsext-tkey-02.txt.
@ -983,5 +982,5 @@ Expiration and File Name
Donald E. Eastlake 3rd [Page 17]
Donald Eastlake 3rd [Page 17]

580
doc/draft/draft-ietf-dnsext-zone-status-00.txt
View File

@ -1,580 +0,0 @@
DNSEXT WG Edward Lewis
INTERNET DRAFT NAI Labs
Category:I-D Feburary 1, 2000
DNS Security Extension Clarification on Zone Status
<draft-ietf-dnsext-zone-status-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Comments should be sent to the authors or the DNSIND WG mailing list
namedroppers@internic.net.
This draft expires on August 1, 2000.
Copyright Notice
Copyright (C) The Internet Society (1999, 2000). All rights reserved.
Abstract
The definition of a secured zone is presented, updating RFC 2535. The
new definition has consequences which alter the interpretation of the
NXT record, obsolete NULL keys, and the designation of "experimentally
secure."
1 Introduction
Whether a DNS zone is "secured" or not is a question asked in at least
four contexts. A zone administrator asks the question when
configuring a zone to use DNSSEC. A dynamic update server asks the
question when an update request arrives, which may require DNSSEC
processing. A delegating zone asks the question of a child zone when
the parent enters data indicating the status the child. A resolver
asks the question upon receipt of data belonging to the zone.
A zone administrator needs to be able to determine what steps are
needed to make the zone as secure as it can be. Realizing that due to
Expires August 1, 2000 [Page 1]
DNS Security Extension Clarification on Zone Status February 1, 2000
the distributed nature of DNS and its administration, any single zone
is at the mercy of other zones when it comes to the appearance of
security. This document will define what makes a zone qualify as
secure (absent interaction with other zones).
A name server performing dynamic updates needs to know whether a zone
being updated is to have signatures added to the updated data, NXT
records applied, and other required processing. In this case, it is
conceivable that the name server is configured with the knowledge, but
being able to determine the status of a zone by examining the data is
a desirable alternative to configuration parameters.
A delegating zone is required to indicate whether a child zone is
secured. The reason for this requirement lies in the way in which a
resolver makes its own determination about a zone (next paragraph). To
shorten a long story, a parent needs to know whether a child should be
considered secured. This is a two part question, what does a parent
consider a secure child to be, and how does a parent know if the child
conforms?
A resolver needs to know if a zone is secured when the resolver is
processing data from the zone. Ultimately, a resolver needs to know
whether or not to expect a usable signature covering the data. How
this determination is done is out of the scope of this document,
except that, in some cases, the resolver will need to contact the
parent of the zone to see if the parent states that the child is
secured.
This document updates several sections of RFC 2535. The definition of
a secured zone is an update to section 3.4 of the RFC. The document
updates section 2.3.4, by specifying a replacement for the NULL zone
keys. The document also updates section 3.4 to eliminate the
definition of experimental keys and illustrate a way to still achieve
the functionality they were designed to provide.
2 Status of a Zone
In this section, rules governing a zone's DNSSEC status are presented.
There are three levels of security defined; full, private, and
unsecured. A zone is fully secure when it complies with the strictest
set of DNSSEC processing rules. A zone is privately secured when it
is configured in such a way that only resolvers that are appropriately
configured see the zone as secured. All other zones are unsecured.
Note: there currently is no other document completely defining DNSSEC
processing rules. For the purposes of this document, the strictest
rules are assumed to state that the verification chain of zone keys
parallels the delegation tree up to the root zone. This is not
intended to disallow alternate verification paths, just to establish a
baseline definition.
To avoid repetition in the rules below, the following term is defined.
2.a. Zone signing KEY RR - A KEY RR whose flag field has the value 01
Expires August 1, 2000 [Page 2]
DNS Security Extension Clarification on Zone Status February 1, 2000
for name type (indicating a zone key) and either value 00 or value 01
for key type (indicating a key permitted to authenticate data). (See
RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value
of DNSSEC (3) or All (255).
2.1 Fully Secured
A fully secured zone, in a nutshell, is a zone that uses only
mandatory to implement algorithms (RFC 2535, section 3.2) and relies
on a key certification chain that parallels the delegation tree. Fully
secured zones are defined by the following rules.
2.1.a. The zone's apex MUST have a KEY RR set. There MUST be at least
one zone signing KEY RR (2.a) of a mandatory to implement algorithm in
the set.
2.1.b. The zone's apex KEY RR set MUST be signed by a private key
belonging to the parent zone. The private key's public companion MUST
be a zone signing KEY RR (2.a) of a mandatory to implement algorithm
and owned by the parent's apex.
If a zone cannot get a conforming signature from the parent zone, the
child zone cannot be considered fully secured.
2.1.c. NXT records MUST be deployed throughout the zone. (Updates RFC
2535, section 2.3.2.) Note: there is some operational discomfort with
the current NXT record. This requirement is open to modification when
two things happen. First, an alternate mechanism to the NXT is
defined and second, a means by which a zone can indicate that it is
using an alternate method.
2.1.d. Each RR set that qualifies for zone membership MUST be signed
by a key that is in the apex's KEY RR set and is a zone signing KEY RR
(2.a) of a mandatory to implement algorithm. (Updates 2535, section
2.3.1.)
2.2 Privately Secured
A privately secured zone is a zone that complies with rules like those
for fully secured, with the following exceptions. The signing keys
may be of an algorithm that is not mandatory to implement and/or the
verification of the zone keys in use may rely on a verification chain
that is not parallel to the delegation tree.
2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at least
one zone signing KEY RR (2.a) in the set.
2.2.b. The zone's apex KEY RR set MUST be signed by a private key and
one of the following two sentences MUST hold true. The private key's
public companion MUST be preconfigured in all the resolvers of
interest. The private key's public component MUST be a zone signing
KEY RR (2.a) authorized to provide validation of the zone's apex KEY
RR set, as recognized by resolvers of interest.
Expires August 1, 2000 [Page 3]
DNS Security Extension Clarification on Zone Status February 1, 2000
The previous sentence is trying to convey the notion of using a
trusted third party to provide validation of keys. If the domain name
owning the validating key is not the parent zone, the domain name must
represent someone the resolver trusts to provide validation.
2.2.c. NXT records MUST be deployed throughout the zone. (Updates RFC
2535, section 2.3.2.) Note: see the discussion following 2.1.c.
2.2.d. Each RR set that qualifies for zone membership MUST be signed
by a key that is in the apex's KEY RR set and is a zone signing KEY RR
(2.a). (Updates 2535, section 2.3.1.)
2.3 Unsecured
All other zones qualify as unsecured. This includes zones that are
designed to be experimentally secure, as defined in a later section on
that topic.
2.4 Wrap up
The designation of fully secured, privately secured, and unsecured are
merely labels to apply to zones, based on their contents. Resolvers,
when determining whether a signature is expected or not, will only see
a zone as secured or unsecured.
Resolvers that follow the most restrictive DNSSEC verification rules
will only see fully secured zones as secured, and all others as
unsecured, including zones which are privately secured. Resolvers
which are not as restrictive, such as those that implement algorithms
in addition to the mandatory to implement algorithms, will see some
privately secured zones as secured.
The intent of the labels "fully" and "privately" is to identify the
specific attributes of a zone. The words are chosen to assist in the
writing of a document recommending the actions a zone administrator
take in making use of the DNS security extensions. The words are
explicitly not intended to convey a state of compliance with DNS
security standards.
3 Parental Notification
For a resolver to come to a definitive answer concerning a zone's
security status, there is a requirement that the parent of a zone
signify whether the child zone is signed or not. The justification of
this requirement requires a discussion of the resolver's activity,
which is described in RFC 2535.
In RFC 2535, a parent is required to hold a NULL key for an unsigned
child (a bone of contention here is how this works in light of
multiple algorithms). The parent has the option to hold the keys of
the child if the child is signed. The parent may also hold nothing
cryptographic if the child is signed. This, of course, assumes the
parent is a signed zone.
Expires August 1, 2000 [Page 4]
DNS Security Extension Clarification on Zone Status February 1, 2000
There is a strong case for discouraging a parent from holding keys of
a signed child. These include concrete concerns about performance and
more abstract concerns about the liability of the parent.
DNS [RFC 1034 and 1035] requires a parent to hold NS records for a
child zone, this signifies the delegation. RFC 2535 requires a
secured parent to also have signed NXT records for the child, and
possibly a signed KEY RR set (required for NULL key situations).
By redefining the security status of a zone to be per zone and not per
algorithm, there is an opportunity to completely remove the need for a
KEY RR set in the parent. Because the question of whether the zone is
secure or not is a yes-or-no question, the notification needs just one
bit to be expressed.
Keep in mind that the following sections speak to the contents of a
zone, not a name server. In the case of a name server speaking
authoritatively for both the parent and child, or if a server caches
the information for the other half of the delegation, then a server
will have more types of data at a delegation point than a parent is
supposed to hold. (E.g., if a parent zone's name server caches the
SOA for the child, the SOA is not in the parent zone, but is in the
server's cache.)
3.1 Child Is Secured Bit
This section is written assuming the current definition of NXT holds.
There is some controversy surrounding the NXT record which may result
in a complete replacement of it for proof of non-existence. The
current NXT definition provides an extension bit in the types present
bit map, whose use is remains incompletely defined. The following
text largely ignores these uncertainties, and should be rewritten to
accommodate these uncertainties in revisions.
In the parent's half of the delegation point, there will be an NXT
record. According to the rules for a delegation point, only the NS,
NXT, and SIG bits will be turned on in the types present field,
assuming we drop the KEY set altogether.
The KEY bit in the parent's NXT types present bit map is hereby
redefined to have the following meaning.
If the bit corresponding to the KEY RR set in a parent NXT is set, the
parent has signed a KEY RR set for the child that includes a zone
signing KEY RR (2.a). Furthermore, the validity period on the SIG
(KEY) RR covers the current time and the public component of the key
used to generate the SIG (KEY) RR is validly available from the
parent.
E.g., Assume the zone "test." signs a key for "zone1.test.," with the
signature valid from May 1st to June 1st and a public key from "test."
available from April 1st until July 1st. The NXT record for
"zone1.test." will have the KEY RR bit set from May 1st to June 1st.
Expires August 1, 2000 [Page 5]
DNS Security Extension Clarification on Zone Status February 1, 2000
This constraint may be enforced in the SIG (NXT) RR validity period,
timely editing of the master file, or whatever other mechanism "test."
chooses to implement.
Conversely, if the bit is 0, then the child is not secured. Note that
for a fully secured zone (section 2.1), the bit is on (1). For all
unsecured zones (section 2.3) the bit is off (0). For privately
secured zones (section 2.2), the setting of the bit is determined by
whether the parent signs the child's keys or not. Hence, for
privately secured zones, the parent may have no responsibility. A
child wishing to have the parent set the bit must contact the parent.
3.2 Rules Governing the Bit
In this section, the words of the previous are turned into definitive
MUST and SHOULDs. Note that this section does not refer to the bit in
the NXT. This is in anticipation of a change in the way NXT indicates
types present (e.g., if bit 0 of the field is defined) or a successor
to the NXT is defined.
3.2.a. At a delegation point, a parent zone MUST have a mechanism in
place to indicate which RR sets are present. The mechanism MUST
indicate that the NS, SIG, and the type(s) corresponding to the
mechanism itself are present (of course, with these types actually
being present). With the exception of the KEY RR type, all other
types MUST be indicated as not present, and, in accordance with
delegation rules, actually be absent from the zone. If, in the
future, other data is permitted to be present at a delegation point,
this requirement MUST be amended.
Assuming the NXT record, the above requirement reads as follows. At a
delegation point, a parent zone must have a secured NXT record. This
NXT record must indicate that the NS, SIG, and NXT types are present.
With the exception of KEY, all other types must be indicated as not
present. The lower casing of the word "must" is intentional,
conveying that this is an explanation of the rule above.
3.2.b. The KEY set MUST be indicated as present during the time when
the parent has issued a signature for the child's KEY set. Conversely,
during periods of time in which the parent knows it has not generated
a signature for the KEY RR set, the KEY set MUST be indicated to be
absent.
If the parent has issued signatures with discontinuous validity spans,
then the presence of the KEY set will flip from present to not present
and back as time progresses.
If the parent is aware that the child's keys are becoming valid or
will be becoming invalid at a certain point in time, it is recommended
that this be reflected in the NXT's signature validity period.
3.2.c. When signing a child's KEY RR set, a parent SHOULD carefully
consider the algorithm of the key used to generate the signature. The
parent SHOULD make clear to child zones what steps are to be taken to
Expires August 1, 2000 [Page 6]
DNS Security Extension Clarification on Zone Status February 1, 2000
get the parent to indicate that the child is signed. This document
will go no further in specifying operational considerations.
(Let's say the parent signs the child's key set with an algorithm the
child can't process. The child could elect not to advertise this
signature as it cannot verify that the signature covers the real key
set. If this happens, is the parent justified in claiming that the
child is secured?)
3.2.d. The parent MUST allow the child, through some trusted, probably
non-DNS mechanism, to request that the indication of the KEY set in
the NXT be turned off. This allows a child to revert to an unsigned
state.
3.2.e. The parent SHOULD NOT allow the child to request that the KEY
set be indicated in the absence of a key signing request.
3.3 Operational Considerations
Retrieving the NXT for a delegated name from the parent zone (the
upper NXT) is not a trivial operation. The complication arises due to
having an NXT in the delegatee (the lower NXT) that matches the owner
name of the upper NXT. (The case in which both the parent and child
zones are secured is the only case mentioned here. If both are not
secured, then there will be at most one NXT, which is easily
retrieved.)
There are two complications to describe. One involves the multiple
NXT sets matching the same owner. The other is the pragmatic issue of
knowing where to get the answer.
With multiple NXT sets at the same owner, caches may become a problem.
If a (for example) recursive server has cached the lower NXT, any
query for the upper NXT may be confused for a lower NXT query. This
is akin to the issue of the ANY query, where a server with some cached
data will answer with just that and not seek the rest of the data.
A resolver may know the child's server's addresses and the parent zone
may not be sharing servers with the child. In this case the resolver
will need to be able to locate the parent zones (possibly having to go
to the root servers and descend) in order to obtain the upper NXT
record.
A potential solution to this is to define an NXT meta-query which will
force a recursive server to find all available NXT RR sets for a given
name. Details of this have not been examined.
3.4 Interaction with Dynamic Update
Dynamic update [RFC 2136, draft-ietf-dnsext-simple-secure-update-
xy.txt] defines a means by which a zone can change without undergoing
a full reload. This combination of dynamic update and the proposed
use of the NXT record to signify a child's status raises some
concerns.
Expires August 1, 2000 [Page 7]
DNS Security Extension Clarification on Zone Status February 1, 2000
First a few elements need to be labeled. There is an off-line signer,
which is the process that signs zone data files away from the name
server. There is an on-line signer, part of a name server, that the
dynamic update mechanism uses to sign the updated data. Finally,
there is an on-line key validator, perhaps a misnomer, which accepts
requests for parent signatures over each child zone's keys.
The proposal depicted in this draft relies upon the on-line key
validator informing the on-line and off-line signers of the status of
a child, recall that the status of a child has a temporal element.
E.g., a signature may be generated for just the month of July, so the
child is secured for the month of July, but not August.
The first issues pertain to the way in which a validation is encoded
in an NXT record by the off-line signer. There is a need for the
status information to flow from the on-line validator to the off-line
signer and then be used as input to the signing process. The way that
this information makes the transition is an issue. The second issue
is through what mechanism is this information ingested into the NXT
generating process. Recall that all other information can be derived
by the zone data, the status of the child isn't stored anywhere else
in the parent zone.
The next issue is the means in which a validation action is reported
to the active zone. On the surface, dynamically updating the NXT
would seem to make sense, but updating the NXT in this manner can lead
to a race condition in the server, this is unstable. The issue here
is deriving a mechanism by which a name server knows to signify that
the child status has changed. Note that this applies to newly
validated keys as well as the granting of a child's request to cancel
a validation.
The final issue is the operation of the off-line signer. When an NXT
is being regenerated, the old NXT is needed to see what the previous
setting of the child's status had been. The old NXT signature is also
needed to know that, had the child been known to be secured, for what
interval was is it thought to be secured so that the new NXT signature
is appropriately set. Of course, if the reason for updating the NXT
is a change as described in the previous paragraph, the old NXT is of
lesser value.
The issue raised in the last paragraph leads to a questioning of the
sanity of using signature validity periods to signify the temporal
status of data in a server. What does a server return if the NXT
needed is not currently covered by a valid signature?
4 NULL keys
Through the use of the types present to indicate the existence of a
signature validating the KEY set of a child, the need for NULL keys
effectively disappears. NULL keys are left as a defined entity, but
are rendered meaningless in DNSSEC.
Expires August 1, 2000 [Page 8]
DNS Security Extension Clarification on Zone Status February 1, 2000
5 Experimental Status
Without NULL keys, an experimentally secured zone cannot be defined as
it is in RFC 2535. The purpose of an experimentally secured zone was
to facilitate the migration from an unsecured zone to a secured zone.
The objective of facilitating the migration can be achieved without a
special designation of an experimentally secure status. Experimentally
secured is a special case of privately secured. A zone administrator
can achieve this by publishing a zone with signatures and configuring
a set of test resolvers with the corresponding public keys. Even if
the public key is published in a KEY RR, as long as there is no parent
signature, the resolvers will need some preconfiguration to know to
process the signatures. This allows a zone to be secured with in the
sphere of the experiment, yet still be registered as unsecured in the
general Internet.
6 IANA/ICANN Considerations
This document does not request any action from an assigned number
authority nor recommends any actions.
7 Security Considerations
Without a means to enforce compliance with specified protocols or
recommended actions, declaring a DNS zone to be "completely" secured
is impossible. Even if, assuming an omnipotent view of DNS, one can
declare a zone to be properly configured for security, and all of the
zones up to the root too, a misbehaving resolver could be duped into
believing bad data. If a zone and resolver comply, a non-compliant or
subverted parent could interrupt operations. The best that can be
hoped for is that all parties are prepared to be judged secure and
that security incidents can be traced to the cause in short order.
8 Acknowledgements
The need to refine the definition of a secured zone has become
apparent through the efforts of the participants at two DNSSEC
workshops, sponsored by the NIC-SE (.se registrar) and CAIRN (a
DARPA-funded research network). Further discussions leading to the
document include Olafur Gudmundsson, Russ Mundy, Robert Watson, and
Brian Wellington.
9 References
[RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities,"
RFC 1034, November 1987.
[RFC1035] P. Mockapetris, "Domain Names - Implementation and
Specification," RFC 1034, November 1987.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119, March 1997
Expires August 1, 2000 [Page 9]
DNS Security Extension Clarification on Zone Status February 1, 2000
[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound "Dynamic
Updates in the Domain Name System," RFC 2136, April 1997.
[RFC2535] D. Eastlake, "Domain Name System Security Extensions," RFC
2535, March 1999.
[draft-ietf-dnsext-simple-secure-update-xy.txt] B. Wellington, "Simple
Secure Domain Name System (DNS) Dynamic Update", version 00, February
2000.
10 Author Information
Edward Lewis NAI Labs 3060 Washington Road Glenwood, MD 21738 +1 443
259 2352 <lewis@tislabs.com>
11 Full Copyright Statement
Copyright (C) The Internet Society (1999, 2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Expires August 1, 2000 [Page 10]

334
doc/draft/draft-ietf-dnsind-dddd-01.txt
View File

@ -1,334 +0,0 @@
DNSIND Working Group Brian Wellington (TISLabs)
INTERNET-DRAFT Olafur Gudmundsson (TISLabs)
April 1999
<draft-ietf-dnsind-dddd-01.txt>
Updates: RFC 2136
Deferred Dynamic Domain Name System (DNS) Delete Operations
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document proposes a mechanism for notifying a dynamic DNS server
that a delete operation should be performed at a certain point in the
future. This works within the framework of the current DNS dynamic
update protocol, and provides needed functionality for clients with
leased dynamic addresses.
Expires October 1999 [Page 1]
INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999
1 - Introduction
Dynamic update operations for the Domain Name System [RFC1034, RFC1035]
are defined in [RFC2136], but there is no automated method of specifying
that records should have a fixed lifetime, or lease.
1.1 - Overview of DNS Dynamic Update
DNS dynamic update defines a new DNS opcode and a new interpretation of
the DNS message if that opcode is used. An update can specify
insertions or deletions of data, along with prerequisites necessary for
the updates to occur. All tests and changes for a DNS update request
are restricted to a single zone, and are performed at the primary server
for the zone. The primary server for a dynamic zone must increment the
zone SOA serial number when an update occurs or before the next
retrieval of the SOA.
1.2 - Overview of DHCP leases
DHCP [RFC2131] provides a means for a host to obtain a network address
from a DHCP server. The server may ``lease'' this address to the host,
meaning that it is valid only for the period of time specified in the
lease. The host may may extend its lease with subsequent requests, or
may issue a message to release the address back to the server when it is
no longer needed.
2 - Background
When a host receives dynamic addresses with associated dynamic DNS
records, the records can be updated by either the host or the DHCP
server. In many cases, update by the server is recommended, since the
server maintains lease information for each address. In some cases,
though, the server cannot update some or all of the DNS records. This
happens when the DNS and DHCP server are under different administration,
for example.
A host can easily update its own DNS records when receiving information
from the DHCP server. It can also delete its records when shutting
down. If the host unexpectedly goes down, though, it cannot delete the
records. When the DHCP lease on the address expires and is not renewed,
the DHCP server may reassign the address. The DNS records now point to
an assigned address, but not the correct address. Until the host
updates its records again, DNS will contain bad information.
Since the DHCP and DNS servers are often not co-located with the
clients, the possibility of a host unexpectedly going down and not
communicating with the servers is non-trivial.
Expires October 1999 [Page 2]
INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999
If the host could set a lease on the DNS records similar to that on its
address, the DNS records would lose validity at the same time as the
address. This would prevent bad information from remaining in DNS. DNS
has no such provision for leases, though, since this would require
storing a lease time along with each record (or each record in a dynamic
zone).
An alternative method is suggested. A ``delete'' update is sent along
with the ``add'' update, but the delete is marked in such a way that it
will not be exectuted immediately. Instead, it will be stored for the
specified amount of time before being applied. If the host wishes to
extend or shorten the lifetime of the DNS record(s), it can replace the
``deferred delete'' record, which will reset the lease time of the
record(s). The ``deferred delete'' record would, of course, also be
removed if a normal delete update was received.
3 - Protocol changes
When doing a delete update operation as defined in [RFC2136] (deleting
an RR, an RRset, or all RRset from a name), the TTL field MUST be
specified as 0. An [RFC2136] compliant server will silently ignore (*)
an update record with a non-zero TTL. This document overloads the TTL
field. If TTL is non-zero, the value represents the number of seconds
(a 32 bit unsigned integer) before which the delete will be applied to
the zone. Thus, the delete operation will be deferred for that number
of seconds, where the number of seconds indicates the lease time. A 32
bit integer provides for a lease time of over 136 years, which should be
long enough for most uses.
3.1 - Storage and execution
Deferred delete records are stored, persistently, by the name server.
The name server SHOULD attempt to evaluate the deletes in a timely
manner. If multiple deferred deletes are sent in the same DNS message
with the same TTL value, they MUST be processed atomically if processed
as planned (that is, none of the deferred deletes are updated or
cancelled).
3.2 - Processing of deferred deletes
When a deferred delete is received, the server must check to see if it
matches an existing deferred delete records, where matching indicates
the same name, type, class, and rdata. If a match is found, the new
deferred delete MUST replace the old one. If the deferred delete does
not refer to any record in the server, it should fail as a normal delete
would.
Expires October 1999 [Page 3]
INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999
3.3 - Processing of normal deletes
When a normal delete is received and accepted, the server SHOULD purge
any matching deferred delete records.
3.4 - Processing of cancellations
The value 0xFFFFFFFF (the largest unsigned 32 bit integer) in the TTL
field has a special meaning. If a delete containing this lease time is
received, the server will unconditionally remove any matching deferred
deletes. If no deferred delete matches, this request will be silently
ignored.
3.5 - Processing of adds
When data is added through a dynamic update which matches a deferred
delete, there is no additional processing done.
4 - TTL handling
Any record that may be deleted SHOULD have a short TTL compared to its
lease time, to prevent deleted data from being cached past its
expiration.
When the time until an RR is deleted becomes low enough, the server MAY
modify the TTL of the RRset. Whenever the TTL is automatically reduced
by this process, the zone will be considered ``changed'' for the purpose
of automatic SOA SERIAL increment (as in [RFC2136]) and real time zone
slave notification [RFC1996]. As these operations can potentially be
expensive (more so if DNSSEC [RFC2535] signatures must be regenerated),
the specific limits and effects are left to the implementation.
If the TTL is modified by the server, it is not reset if the lease is
renewed. Therefore, the original RR SHOULD be sent with the lease
renewal if the client expects that the server has modified the TTL.
Expires October 1999 [Page 4]
INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999
5 - Usage
Normally, a deferred delete update will initially be sent along with an
add, although this is not required. Further updates to the deferred
delete may be sent independently, although the add should be sent again.
If the deferred delete is associated with a leased address, the lease
time of the update SHOULD be approximately equal to the lease time of
the address.
6 - Protocol robustness
This protocol has no inherent protection against replayed messages,
which can either originate from an attack or faulty hardware. To
prevent this problem, prerequisites should be used in the update
message, such as a test for the existence of a TXT record describing the
lease, which would be added along with the other records (see [RFC2136],
section 5).
7 - Security considerations
This addition to the dynamic DNS protocol does not affect the security
of the protocol. If security is desired, TSIG [TSIG] and/or DNSSEC
[RFC2535] authentication should be used, as specified in [simple-update]
or [RFC2137, update2]. The authors strongly recommend using security
along with this protocol.
If a DNSSEC signed-zone is modified with deferred deletes, the server
must resign any affected records when the delete is executed. No
special processing is required when the delete is received.
8 - IANA Considerations
None.
9 - References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,''
RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1035, ISI, November 1987.
[RFC1996] P. Vixie ``A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY),'' RFC 1996, ISC, August 1996.
[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore
& Cisco & DEC, April 1997.
Expires October 1999 [Page 5]
INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999
[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC
2137, CyberCash, April 1997.
[RFC2535] D. Eastlake ``Domain Name System Security Extensions,'' RFC
2535, IBM, March 1999.
[TSIG] P. Vixie (ed), O. Gudmundsson, D. Eastlake, B. Wellington
``Secret Key Transaction Signatures for DNS (TSIG),'' draft-
ietf-dnsind-tsig-08.txt, ISC & TISLabs & IBM & TISLabs,
February 1999.
[simple-update]
B. Wellington ``Simple Secure Domain Name System (DNS)
Dynamic Update,'' draft-ietf-dnssec-simple-update-00.txt,
TISLabs, November 1998.
[update2] D. Eastlake ``Secure Domain Name System (DNS) Dynamic
Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite
Systems Company, August 1998.
8 - Author's Address
Brian Wellington Olafur Gudmundsson
TISLabs at Network Associates TISLabs at Network Associates
3060 Washington Road, Route 97 3060 Washington Road, Route 97
Glenwood, MD 21738 Glenwood, MD 21738
+1 443 259 2369 +1 443 259 2389
<bwelling@tislabs.com> <ogud@tislabs.com>
Expires October 1999 [Page 6]

5
doc/draft/draft-ietf-dnsind-dddd-02.txt Normal file
View File

@ -0,0 +1,5 @@
This Internet-Draft has expired and is no longer available.
Unrevised documents placed in the Internet-Drafts directories have a
maximum life of six months. After that time, they must be updated, or
they will be deleted. This document was deleted on March 20, 2000.

249
doc/draft/draft-ietf-dnsind-edns1-03.txt
View File

@ -1,249 +0,0 @@
DNSIND Working Group Paul Vixie
INTERNET-DRAFT ISC
<draft-ietf-dnsind-edns1-03.txt> June, 1999
Extensions to DNS (EDNS1)
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document specifies a number of extensions within the Extended
DNS framework defined by [EDNS0], including several new extended
label types and the ability to ask multiple questions in a single
request.
1 - Rationale and Scope
1.1. EDNS (see [EDNS0]) specifies an extension mechanism to DNS (see
[RFC1035]) which provides for larger message sizes, additional label
types, and new message flags.
1.2. This document makes use of the EDNS extension mechanisms to add
several new extended label types and message options, and the ability to
ask multiple questions in a single request.
Expires December 1999 [Page 1]
INTERNET-DRAFT EDNS1 June 1999
2 - Affected Protocol Elements
2.1. Compression pointers are 14 bits in size and are relative to the
start of the DNS Message, which can be 64KB in length. 14 bits restrict
pointers to the first 16KB of the message, which makes labels introduced
in the last 48KB of the message unreachable by compression pointers. A
longer pointer format is needed.
2.2. DNS Messages are limited to 65535 octets in size when sent over
TCP. This acts as an effective maximum on RRset size, since multiple
TCP messages are only possible in the case of zone transfers. Some
mechanism must be created to allow normal DNS responses (other than zone
transfers) to span multiple DNS Messages when TCP is used.
2.3. Multiple queries in a question section have not been supported in
DNS due the applicability of some DNS Message Header flags (such as AA)
and of the RCODE field only to a single QNAME, QTYPE, and QCLASS.
Multiple questions per request are desirable, and some way of asking
them must be made available.
3 - Extended Label Types
3.1. In [EDNS0], the ``0 1'' label type was specified to denote an
extended label type, whose value is encoded in the lower six bits of the
first octet of a label, and an extended label type of ``1 1 1 1 1 1''
was further reserved for use in future multibyte extended label types.
3.2. The ``0 0 0 0 0 0'' extended label type will indicate an extended
compression pointer, such that the following two octets comprise a
16-bit compression pointer in network byte order. Like the normal
compression pointer, this pointer is relative to the start of the DNS
Message.
3.3. The ``0 0 0 0 0 1'' extended label type will indicate a counted bit
string label as described in [CRAW98].
3.4. The ``0 0 0 0 1 0'' extended label type will indicate a ``long
local compression pointer'' as described in [KOCH98].
Expires December 1999 [Page 2]
INTERNET-DRAFT EDNS1 June 1999
4 - OPT pseudo-RR Flags and Options 4.1. The extended RCODE and flags
are structured as follows:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | EXTENDED-RCODE | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: |MD |FM |RRD|LM | Z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. (As
defined by [EDNS0].)
VERSION Indicates the implementation level of whoever sets it.
Full conformance with the draft standard version of this
specification is version ``1.'' Note that both
requestors and responders should set this to the highest
level they implement, that responders should send back
RCODE=BADVERS and that requestors should be prepared to
probe using lower version numbers if they receive an
RCODE=BADVERS.
MD ``More data'' flag. Valid only in TCP streams where
message ordering and reliability are guaranteed. This
flag indicates that the current message is not the
complete request or response, and should be aggregated
with the following message(s) before being considered
complete. Such messages are called ``segmented.'' It
is an error for the RCODE (including the EXTENDED-
RCODE), AA flag, or DNS Message ID to differ among
segments of a segmented message. It is an error for TC
to be set on any message of a segmented message. Any
given RR must fit completely within a message, and all
messages will both begin and end on RR boundaries. Each
section in a multipart message must appear in normal
message order, and each section must be complete before
later sections are added. All segments of a message
must be transmitted contiguously, without interleaving
of other messages.
FM ``First match'' flag. Notable only when multiple
questions are present. If set in a request, questions
will be processed in wire order and the first question
whose answer would have NOERROR AND ANCOUNT>0 is treated
Expires December 1999 [Page 3]
INTERNET-DRAFT EDNS1 June 1999
as if it were the only question in the query message.
Otherwise, questions can be processed in any order and
all possible answer records will be included in the
response. Response FM should be ignored by requestors.
RRD ``Recursion really desired'' flag. Notable only when a
request is processed by an intermediate name server
(``forwarder'') who is not authoritative for the zone
containing QNAME, and where QTYPE=ANY or QDCOUNT>1. If
set in a request, the intermediate name server can only
answer using unexpired cached answers (either positive
or negative) which were atomically acquired using (a)
the same QTYPE or set of QTYPEs present in the current
question and whose TTLs were each minimized to the
smallest among them when first cached, and (b) the same
FM and LM settings present in the current question.
LM ``Longest match'' flag. If this flag is present in a
query message, then for any question whose QNAME is not
fully matched by zone or cache data, the longest
trailing label-bounded suffix of the QNAME for which
zone or cache data is present will be eligible for use
as an answer. Note that an intervening wildcard name
shall supercede this behaviour and the rules described
in [RFC1034 4.3.2, 4.3.3] shall apply, except that the
owner name of the answer will be the wildcard name
rather than the QNAME. Any of: QTYPE=ANY, or
QCLASS=ANY, or QCOUNT>1, shall be considered an error if
the LM flag is set.
If LM is set in a request, then LM has meaning in the
response as follows: If the content of the response
would have been different without the LM flag being set
on the request, then the response LM will be set; If the
content of the response was not determined or affected
by the request LM, then the response LM will be cleared.
If the request LM was not set, then the response LM is
not meaningful and should be set to zero by responders
and ignored by requestors.
Z Set to zero by senders and ignored by receivers, unless
modified in a subsequent specification.
Expires December 1999 [Page 4]
INTERNET-DRAFT EDNS1 June 1999
5 - Multiple Questions for QUERY
5.1. If QDCOUNT>1, multiple questions are present. All questions must
be for the same QNAME and QCLASS; only the QTYPE is allowed to vary. It
is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY.
5.2. RCODE and AA apply to all RRs in the answer section having the
QNAME that is shared by all questions in the question section. AA
applies to all matching answers, and will not be set unless the exact
original request was processed by an authoritative server and the
response forwarded in its entirety.
5.3. If a multiple question request is processed by an intermediate
server and the authority server does not support multiple questions, the
intermediate server must generate an answer iteratively by making
multiple requests of the authority server. In this case, AA must never
be set in the final answer due to lack of atomicity of the contributing
authoritative responses.
5.4. If iteratively processing a multiple question request using an
authority server which can only process single question requests, if any
contributing request generates a SERVFAIL response, then the final
response's RCODE should be SERVFAIL.
6 - Acknowledgements
Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Michael Patton,
and Michael Graff were each instrumental in creating this specification.
7 - References
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1035, USC/Information Sciences
Institute, November 1987.
[EDNS0] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' Draft
draft-ietf-dnsind-edns0-XX, IETF DNSIND, September 1998
[CRAW98] M. Crawford, ``Binary Labels in the Domain Name System,''
Draft draft-ietf-dnsind-binary-labels-XX, IETF DNSIND, March
1998.
[KOCH98] P. Koch, ``A New Scheme for the Compression of Domain
Names,'' Draft draft-ietf-dnsind-local-compression-XX.txt.
Expires December 1999 [Page 5]
INTERNET-DRAFT EDNS1 June 1999
IETF DNSIND, March 1998.
8 - Author's Address
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063
+1 650 779 7001
<vixie@isc.org>
Expires December 1999 [Page 6]

5
doc/draft/draft-ietf-dnsind-edns1-04.txt Normal file
View File

@ -0,0 +1,5 @@
This Internet-Draft has expired and is no longer available.
Unrevised documents placed in the Internet-Drafts directories have a
maximum life of six months. After that time, they must be updated, or
they will be deleted. This document was deleted on March 20, 2000.

440
doc/draft/draft-ietf-dnsind-keyreferral-00.txt
View File

@ -1,440 +0,0 @@
DNSIND WG Edward Lewis
INTERNET DRAFT TIS Labs
May Update: RFC 2535 Jerry Scharf
Catagory: I-D ISC
April 1, 1999
The Zone Key Referral
<draft-ietf-dnsind-keyreferral-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Comments should be sent to the authors or the DNSIND WG mailing list
<namedroppers@internic.net>.
This draft expires on October 1, 1999
Copyright Notice
Copyright (C) The Internet Society (1999). All rights
reserved.
Notes on this document
This section will only appear in the -00.txt edition of this draft.
This document originated in the DNSSEC working group in June 1998. The
discussion of the issues in this draft were tabled until the publication
of the then current DNSSEC drafts as RFCs.
The first version of this document lists a third author, John Gilmore.
He is listed as an author because he was one of the initiators of what is
proposed. In this and following versions he is only listed in the
Acknowledgements (as opposed to being an author) as he has not been
involved in the writing/editing of the draft. This has been done to
avoid assigning his name to a document he may not have a chance to read,
this is not intended as a slight on his efforts.
When commenting on this draft, please be aware that some terms used here
are up for negotiation before progressing - such as "thief" and "road
block" appearing later in the draft. Comments which are left justified
were added during the re-issuing of the draft, they add context that
may have been lost over time.
Abstract
A new type of key is defined to address the problems of
performance in large delegeted zones and issues of liability of
registrars with regards to the storing of public keys belonging
to zone cuts. This new key type also brings DNSSEC more in line
with the DNS treatment of zone cuts and speeds recovery in
handling privatekey exposure.
The new type of key is a referral record that is stored, signed,
at the parent zone's place for the delegation point. A resolver
receiving this record is being informed that there are genuine
public keys at the child's authoritative name servers. The
parent no longer needs to store the child's public keys locally.
1 Introduction
There are a number of different reasons for the proposal of this
new key type. Reasons include:
o the performance impact that RFC 2535 has on name servers
o the problem of updating a widely delegated parent zone on demand
o statements in RFC 2181 on authoritative data at delegations
o perceived liability of the operator of a name server or registry
To address these issues, which are expanded upon below, a new
key type is proposed - a "zone key referral" - to join the user
key, host key, and zone key types defined in RFC 2535.
1.1 Performance Issues
A sample zone will be used to illustrate the problem. The
example will part from reality mostly in the length of zone
names, which changes the size of the owner and resource record
data fields.
# $ORIGIN test.
# @ IN SOA <SOA data>
# IN SIG SOA <by test.>
# IN KEY <1024 bit zone key>
# IN SIG KEY <by test.>
# IN SIG KEY <by .>
# IN NS ns.test.
# IN SIG NS <by test.>
# IN NXT my-org.test. NS SOA SIG KEY NXT
# IN SIG NXT <by test.>
#
# my-org IN KEY <1024 bit zone key>
# IN KEY <1024 bit zone key>
# IN SIG KEY <by test.>
# IN NS ns1.my-org.test.
# IN NS ns2.my-org.test.
# IN NXT them.test. NS SIG KEY NXT
# IN SIG NXT <by test.>
#
# them IN KEY 0xC100 3 1
# IN SIG KEY <by test.>
# IN NS ns1.them.test.
# IN NS ns2.them.test.
# IN NXT test. NS SIG KEY NXT
# IN SIG NXT <by test.>
In this zone file fragment, "my-org" is a delegation point of
interest with two registered public keys. Presumably, one key
is for signatures generated currently and the other is for still
living and valid but older signatures. "them" is another
delegation point, with a NULL key. This signifies that this zone
is unsecured.
To analyze the performance impact of the storing of keys, the
number of bytes used to represent the RRs in the procotol format
is used. The actual number of bytes stored will likely be
higher, accounting for data structure overhead and alignment.
The actual number of bytes transferred will be lower due to DNS
name compression.
The number of bytes for my-org's two 1024-bit keys, two NS
records, NXT and the associated signatures is 526. The bytes
needed for them (with the NULL key) is 346. Currently, there
are close to 2 million entries in com., so if we take my-org as
a typical domain, over 1GB on memory will be needed for com.
The zone keys used in the example are set to 1024 bits. This
number may range from as low as 512 bits upwards to over 3000
bits. To scale the above numbers to a different key size,
multiply the difference in key sizes by 4 for my-org and by 2
for them, and adjust the numbers accordingly.
The increased size of the data held for the zone cuts will have
two impacts at the transport and below layers. Bandwidth beyond
that currently needed will be used to carry the KEY records.
The inclusion of all of the child's keys will also push DNS over
the UDP size limit and start using TCP - which could cause
critical problems for current heavily used name servers, like
the roots.
Another impact, not illustrated by the example, is the frequency
of updates. If each time a public key for my-org is added or
deleted, the SOA serial number will have to increase, and the
SOA signed again. If an average zone changes its keys(s) once
per month, there will be on average 45 updates per minute in a
zone of 2 million delegations.
(The multiple algorithms issue is an extension of multiple keys. The
example should be updated to show at least a DSS key as well as an RSA
key.)
1.2 Security Incident Recovery (w/ respect to keys only)
Once a zone administrator is alerted that any key's private
counterpart has been discovered (exposed), the first action to
be taken is to stop advertising the public key in DNS. This
doesn't end the availability of the key - it will be residing in
caches - but is the closest action resembling revokation
available in DNS.
Stopping the advertisement in the zone's name servers is as
quick as altering the master file and restarting the name
server. Having to do this in two places will will only delay
the time until the recovery is complete.
For example, a registrar of a top level domain has decided to
update its zone only on Mondays and Fridays due to the size of
the zone. A customer/delegatee is the victim of a break in, in
which one of the items taken is the file of private keys used to
sign DNS data. If this occurs on a Tuesday, the thief has until
Friday to use the keys before they disappear from the DNS, even
if the child stops publishing them immediately.
If the public key set is in the parent zone, and the parent zone
is not able to make the change quickly, the public key cannot be
revoked quickly. If the parent only refers to there being a key
at the child zone, then the child has the agility to change the
keys - even issue a NULL key, which will force all signatures in
the zone to become suspect.
1.3 DNS Clarifications
RFC 2181, section 6, clarifies the status of data appearing at a
zone cut. Data at a zone cut is served authoritatively from the
servers listed in the NS set present at the zone cut. The data
is not (necessarily) served authoritatively from the parent.
(The exception is in servers handling both the parent and child
zone.)
Section 6 also mentions that there are two exceptions created by
DNSSEC, the NXT single record set and the KEY set. This
proposal addresses the exception relating to the KEY set,
limiting its severity (but falling short of removing it
altogether). By limiting the exception, we will be simplifying
DNS.
1.4 Liability
Liability is a legal concept, so it is not wise to attempt an
engineering solution to it. However, the perceived liability
incurred in using DNSSEC by registrars may prevent the adoption
of DNSSEC. Hence DNSSEC should be engineered in such a away to
address the concern.
One source of liability is the notion that by advertising a
public key for a child zone, a parent zone is providing a
service of security. With that comes responsibility. By having
the parent merely indicate that a child has a key (or has no
key), the parent is providing less in the way of security. If
the parent is wrong, the potential loss is less. Instead of
falsely authenticated data, configuration errors will be
apparent to the resolving client.
2 The Proposal
The proposal is to introduce a new key type which indicates
whether the delegated zone is running secured or not. Running
secured is either a zone signed with at least one key, an
experimental zone, or a zone with only NULL keys published.
The Zone Referral Key will resemble the NULL key in syntax.
There will be a flags field, an algorithm field, and a protocol
field, but no public key material. The Referral Key is signed
by the parent zone, as was the public key set in RFC 2065.
There is only one Referral Key RR present.
The Referral Key flags field will have the following values:
Field Bit(s) Value Meaning
A/C 0- 1 0b01 indicates a key will be found
0b11 indicates a key will not be found
0b?0 error (referral cannot encrypt)
XT 2 0 no extended flags are needed
Z 4- 5 0 must be zero for all keys
NAMTYP 6- 7 0b11 this is a referral to a zone key
Z 8-11 0 must be zero for all keys
SIG 12-15 0 must be zero for a referral key
The legal values of the flags field are (in summary):
Hex Value Indicates
0x4300 The delegation has a key record set
0xC300 The delegation has no key record
Other values are not valid for Referral Keys (but may be valid
for other keys).
The Protocol field must be set to 3, the DNSSEC protocol value.
The Algorithm field must be 0.
The algorithm is not important at this point. So long as the searcher
knows to expect a key set at the delegated zone's apex, a secure chain
is possible. One the key set is retrieved and verified, then the
algorithms used in the delegated zone are known. (The issue is that a
zone may be signed in algorithm 1 and not 3, 3 and not 1, both, etc.,
and a secure resolver must know this in order to set signature arrival
expectations.
2.1 Example
The Referral key for my-org.test. and them.test. would appear as
the following in the zone master file:
my-org.test. IN KEY 0x4300 3 0
them.test. IN KEY 0xC300 3 0
In the example introduced earlier, the master file would change
to the following.
# $ORIGIN test.
# @ IN SOA <SOA data>
# IN SIG SOA <by test.>
# IN KEY <1024 bit zone key>
# IN SIG KEY <by test.>
# IN SIG KEY <by .>
# IN NS ns.test.
# IN SIG NS <by test.>
# IN NXT my-org.test. NS SOA SIG KEY NXT
# IN SIG NXT <by test.>
#
# my-org IN KEY 0x4300 3 0
# IN SIG KEY <by test.>
# IN NS ns1.my-org.test.
# IN NS ns2.my-org.test.
# IN NXT them.test. NS SIG KEY NXT
# IN SIG NXT <by test.>
#
# them IN KEY 0xC300 3 1
# IN SIG KEY <by test.>
# IN NS ns1.them.test.
# IN NS ns2.them.test.
# IN NXT test. NS SIG KEY NXT
# IN SIG NXT <by test.>
3 Analysis
By removing the public keys from the parent's master file, the
parent is no longer a road block during an emergency removal of
keys. A parent zone is unchanged as a zone changes from NULL
keys to experimental keys to fully signed. The parent is also
not providing a security service, other than to authentically
claim the existence of a KEY record set - akin to the "hints" of
the name servers.
The change also improves the prospect for performance. The need
for multiple KEY RR's, each one on the order of 100 bytes, is
removed and replaced by a single KEY RR of the order of 25
bytes. Saving bytes reduces the need to use TCP to avoid
truncated responses. Also, the need for updating the zone drops
- no longer will there be updates for each key change.
As far as the statements by RFC 2181 conerning authority levels,
the Referral Key is not authortative and would be superseeded by
a verified set of the real zone keys. The only caveat is that
once the verified set of keys expire (assuming the parent has to
learn the keys from another server), the Referal Key must
reappear. This is an example of what has been labelled "mount-
like semantics."
[No reference for mount-like semantics has yet been found.]
The last point is important. This requires the "mount-like
semantics" that have been discussed for the BIND name servers.
Once hints are overridden by learned, authorititative and
verified data, the hints are not discarded. Hints in this state
are stored and become visible when the learned data expires.
4 IANA Considerations
Other than using a new value in the flags field of the KEY RR,
no new number assignments are needed. The flags field is not
under the control of IANA as of yet. There are no requirements
placed on IANA by this draft.
5 Security Considerations
There has been some debate about whether the Referral key should
be treated as a hint - just like the NS records. If so, then
there is no need to sign the Referral Key, and an unsigned
(hence non-authenticated) security record is of little value.
So, is the Referral Key even needed?
Authentication in DNSSEC is done from the data "back" towards a
trusted point - e.g., "up" to the root. Since the
authentication is done by going repeatedly from child to parent,
why bother having the parent indicate the status of the child?
The answer is in the scenario in which a resolver somewhere has
obtained data which fails the verification process. Perhaps the
signature is wrong, a key in the chain of trust is unavailable,
the set should have had a signature, but none is found (or vice
versa), or the trail of signed-by names is not acceptable. In
this case, the resolver needs to find the authoritative zone,
its status and its name server set.
If a zone is being attacked by a masquerader, and parents do not
make any statements about the security of child zones, then an
easy and successfull attack may occur. An attacker only needs
to supply either fake name server records or glue records to
redirect queries.
While this attack will not be stopped as far as denial of
service, the masquerader can be stopped from being accepted as
an authoritative source if the parent of the zone claims the
child is secure and signs the public keys of the true child and
not the masquerader.
The masquerader cannot successfully claim that the zone is
unsigned, because it must have a zone key signed by the parent.
NULL or not, the key would not be trusted by the resolver,
assuming the parent has not also been duped. The resolver,
sensing this, should report an error or security incident, and
not accept data.
6 Acknowledgements
John Gilmore originally raised the issues that have led to this
document.
7 Author's addresses
Edward Lewis Jerry Scharf
<lewis@tislabs.com> <scharf@vix.com>
3060 Washinton Rd (Rte 97)
Glenwood, MD 21738
+1(443)259-2352
8 References
RFC 2181 "Clarifications to the DNS Specification", Elz and Bush
RFC 2535 "Domain Name System Security Extensions", Eastlake
9 Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
This draft expires on October 1, 1999

5
doc/draft/draft-ietf-dnsind-keyreferral-01.txt Normal file
View File

@ -0,0 +1,5 @@
This Internet-Draft has expired and is no longer available.
Unrevised documents placed in the Internet-Drafts directories have a
maximum life of six months. After that time, they must be updated, or
they will be deleted. This document was deleted on March 20, 2000.

420
doc/draft/draft-ietf-dnsind-local-compression-05.txt
View File

@ -1,420 +0,0 @@
INTERNET-DRAFT Peter Koch
Expires: December 1999 Universitaet Bielefeld
Updates: 1035, 1183, 2163, 2168, 2535 June 1999
A New Scheme for the Compression of Domain Names
draft-ietf-dnsind-local-compression-05.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Comments should be sent to the author or the DNSIND WG mailing list
<namedroppers@internic.net>.
Abstract
The compression of domain names in DNS messages was introduced in
[RFC1035]. Although some remarks were made about applicability to
future defined resource record types, no method has been deployed yet
to support interoperable DNS compression for RR types specified since
then.
This document summarizes current problems and proposes a new
compression scheme to be applied to future RR types which supports
interoperability. Also, suggestions are made how to deal with RR
types defined so far.
1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Koch Expires December 1999 [Page 1]
INTERNET-DRAFT DNS Compression June 1999
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Domain names herein are for explanatory purposes only and should not
be expected to lead to useful information in real life [RFC2606].
2. Background
Domain name compression was introduced in [RFC1035], section 4.1.4,
as an optional protocol feature and later mandated by [RFC1123],
section 6.1.2.4. The intent was to reduce the message length,
especially that of UDP datagrams, by avoiding repetition of domain
names or even parts thereof.
A domain name is internally represented by the concatenation of label
strings, where the first octet denotes the string length, not
including itself. The null string, consisting of a single octet of
zeroes, is the representation of the root domain name and also
terminates every domain name.
As labels may be at most 63 characters long, the two most significant
bits in the length octet will always be zero. Compression works by
overloading the length octet with a second meaning. If the two MSB
have the value '1', the remainder of the length octet and the next
octet form a compression pointer, which denotes the position of the
next label of the current domain name in the message:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1 1| OFFSET |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
It is important that these pointers always point backwards.
Compression may occur in several places. First, the owner name of an
RR may be compressed. The compression target may be another owner
name or a domain name in the RDATA section of a previous RR. Second,
any domain name within the RDATA section may be compressed and the
target may be part of the same RR, being the owner name or another
domain name in the RDATA section, or it may live in a previous RR,
either as its owner or as a domain name in its RDATA section. In
fact, due to the chaining feature, combinations of the above may
occur.
3. Problems
While implementations shall use and must understand compressed domain
names in the RDATA section of "well known" RR types (those initially
defined in [RFC1035]), there is no interoperable way of applying
Koch Expires December 1999 [Page 2]
INTERNET-DRAFT DNS Compression June 1999
compression to the RDATA section of newer RRs:
Quote from [RFC1123], section 6.1.3.5:
Compression relies on knowledge of the format of data inside a
particular RR. Hence compression must only be used for the
contents of well-known, class-independent RRs, and must never be
used for class-specific RRs or RR types that are not well-known.
The owner name of an RR is always eligible for compression.
DNS records in messages may travel through caching resolvers not
aware of the particular RR's type and format. These caches cannot
rearrange compression pointers in the RDATA section simply because
they do not recognize them. Handing out these RRs in a different
context later will lead to confusion if the target resolver tries to
uncompress the domain names using wrong information. This is not
restricted to intermediate caching but affects any modification to
the order of RRs in the DNS message.
4. Local Compression
We often observe a certain locality in the domain names used as owner
and occuring in the RDATA section, e.g. in MX or NS RRs but also in
newer RR types [RFC1183]:
host.foo.bar.example RP adm.foo.bar.example adm.persons.bar.example
So, to still profit from compression without putting interoperability
at risk, a new scheme is defined which limits the effect of
compression to a single RR.
In contrast to the usual method of using offsets relative to the
start of a DNS packet we start counting at the RR owner or calculate
pointers relative to the start of the RDATA to avoid context
sensitivity. We use an additional compression indicator for a two
octet local pointer:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1 0| OFFSET |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The "10" bits will indicate the use of local compression and
distinguish it from conventional compression, plain labels and EDNS
label codes [EDNS0]. Two types of pointers need to be specified:
those pointing into the owner name and those pointing into RDATA.
A) Pointers into the owner name are interpreted as the ordinal label
number (starting at 0 for the topmost label, the TLD). This way we
avoid the need for extra decompression of the owner name during
Koch Expires December 1999 [Page 3]
INTERNET-DRAFT DNS Compression June 1999
message composition or decomposition.
The highest possible value of a compression pointer pointing into
the owner name is 254. The value 255 is reserved for future use.
B) Pointers into the RDATA section start at the fixed value 256 for
the first octet and have a maximum value of 16383 limiting
possible targets to the first 16128 octets. The actual offset
relative to the start of RDATA is determined by subtracting 256
from the value of the pointer.
Local pointers MUST point to a previous occurence of the same name in
the same RR. Even domain names in another RR of the same type cannot
serve as compression targets since the order of RRs in an RRSet is
not necessarily stable. The length of the compressed name(s) MUST be
used in the length calculation for the RDLENGTH field.
Example
Consider a DNS message containing two resource records, one CNAME RR
and one XMPL RR, undefined and meaningless so far, with an RDATA
section consisting of two domain names:
ab.foo.example IN CNAME bar.example
bar.example IN XMPL a.foo.example foo.example
In a message this appears as follows (randomly starting at octet 12):
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
12 | 2 | a |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
14 | b | 3 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
16 | f | o |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
18 | o | 7 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20 | e | x |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22 | a | m |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
24 | p | l |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
26 | e | 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 octets skipped (TYPE, CLASS, TTL, RDLENGTH)
Koch Expires December 1999 [Page 4]
INTERNET-DRAFT DNS Compression June 1999
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
38 | 3 | b |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
40 | a | r |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
42 | 1 1| 19 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The XMPL RR with local compression applied:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
44 | 1 1 | 38 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 octets skipped (TYPE, CLASS, TTL, RDLENGTH)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
56 | 1 | a |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
58 | 3 | f |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
60 | o | o |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
62 | 1 0| 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
64 | 1 0| 258 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The first local pointer at position 62 points to the topmost label
"example" of the XMPL RR's owner.
The second local pointer at position 64 represents the "foo.example"
and points backwards into the RDATA section, third octet, at absolute
position 58. Note that with conventional compression this example
message would have occupied less space.
5. Interaction with DNSSEC
The security extensions to DNS [RFC2535] mandate that domain names in
RDATA be signed only in expanded, lower case format. For RR types
using local compression the specification is changed as follows:
Resource Records subject to local compression MUST be stored,
signed, transmitted and verified in locally compressed form. Name
expansion or canonicalization MUST NOT be performed on the RDATA
section for signing or verification.
This way RR type transparency can be achieved, since domain names in
Koch Expires December 1999 [Page 5]
INTERNET-DRAFT DNS Compression June 1999
the RDATA section are treated as arbitrary data and can be cached and
verified by resolvers not aware of the particular RR type. Old RR
types subject to conventional or no compression are not affected by
this change.
Wildcard owners may serve as compression targets only in their fixed
part. Even if a particular query asks for a domain name which could
be used to compress the RDATA part more efficiently, this MUST NOT be
done. Otherwise signatures would be invalidated.
Currently slave servers store zones in text format and re-encode the
data into wire format, e.g. after a restart. This encoding must be
unique to ensure signature validity. To achieve this, local
compression MUST be applied optimally, i.e. every domain name must be
compressed as far as possible and each local compression pointer must
point to the earliest available target (including the owner).
6. Interaction with Binary Labels
When constructing local compression pointers into the owner name,
every one-bit label is counted as a label. This way the compression
and decompression is independent of the actual bit-string
representation.
For local compression pointers into the RDATA section, only bit-
string labels may serve as targets, not single one-bit labels. Bit-
string labels may be adjusted to increase compression efficiency
[BINLABELS, section 3.1]
The internal representation of a domain name has a maximum length of
255 [RFC 1035]. Any label consists of at least two octets, leading
to at most 127 labels per domain name plus the terminating zero
octet, which does not qualify as a compression target. With the
introduction of binary labels a domain name can consist of up to 1904
labels (all one-bit labels). This document restricts the possible
compression targets in an owner name to the topmost 255 labels. This
limit was chosen to be consistent with [RFC2535], section 4.1.3.
7. Old RR types and deployment
Although differences in RDATA sections by class have not yet been
reported and the concept of classes did not really spread, we are
just considering the IN class here.
The following RR types with domain names in the RDATA section have
been defined since [RFC1035] (Standards Track, Experimental and
Informational RFCs, ignoring withdrawn types): RP [RFC1183], AFSDB
[RFC1183], RT [RFC1183], SIG [RFC2535], PX [RFC2163], NXT [RFC2535],
Koch Expires December 1999 [Page 6]
INTERNET-DRAFT DNS Compression June 1999
SRV [RFC2052], NAPTR [RFC2168], KX [RFC2230]. Some specifications do
not mention DNS compression at all, others explicitly suggest it and
only in part identify interoperability issues. Only the KX and SRV
RR types are safe as their specifications prohibit compression.
The specification of RP, AFSDB, RT, PX, and NAPTR is hereby changed
in that domain names in the RDATA section MUST NOT be compressed and
MUST NOT be compression targets.
Local compression MUST NOT be used for owner names and it MUST NOT be
applied to domain names in RDATA sections of any RR type defined so
far.
The specification of future RR types should explicitly select the use
of local compression or forbid RDATA domain name compression at all.
8. Security Considerations
The usual caveats for using unauthenticated DNS apply. This scheme is
believed not to introduce any new security problems. However,
implementors should be aware of problems caused by blindly following
compression pointers of any kind. [RFC1035] and this document limit
compression targets to previous occurences and this MUST be followed
in constructing and decoding messages. Otherwise applications might
be vulnerable to denial of service attacks launched by sending DNS
messages with infinite compression pointer loops. In addition,
pointers should be verified to really point to the start of a label
(for conventional and local RDATA pointers) and not beyond the end of
the domain name (for local owner name pointers).
The maximum length of 255 applies to domain names in uncompressed
wire format, so care must be taken during decompression not to exceed
this limit to avoid buffer overruns.
9. Acknowledgements
The author would like to thank Andreas Gustafsson, Paul Vixie, Bob
Halley, Mark Andrews and Thomas Narten for their review and
constructive comments.
10. References
[RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities",
RFC 1034, STD 13, November 1987
Koch Expires December 1999 [Page 7]
INTERNET-DRAFT DNS Compression June 1999
[RFC1035] Mockapetris,P., "Domain Names - Implementation and
Specification", RFC 1035, STD 13, November 1987
[RFC1123] Braden,R., "Requirements for Internet Hosts -- Application
and Support", RFC 1123, STD 3, October 1989
[RFC1183] Everhart,C., Mamakos,L., Ullmann,R., Mockapetris,P., "New
DNS RR Definitions", RFC 1183, October 1990
[RFC2052] Gulbrandsen,A., Vixie,P. "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052, October 1996
[RFC2119] Bradner,S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997
[RFC2163] Allocchio,C., "Using the Internet DNS to Distribute MIXER
Conformant Global Address Mapping (MCGAM)", RFC 2163,
January 1998
[RFC2168] Daniel,R., Mealling,M., "Resolution of Uniform Resource
Identifiers using the Domain Name System", RFC 2168, June
1997
[RFC2230] Atkinson,R., "Key Exchange Delegation Record for the DNS",
RFC 2230, November 1997
[RFC2535] Eastlake,D., "Domain Name System Security Extensions", RFC
2535, March 1999
[RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names",
RFC 2606, BCP 32, June 1999
[EDNS0] Vixie,P., "Extension mechanisms for DNS (EDNS0)", draft-
ietf-dnsind-edns0-XX.txt, work in progress
[BINLABELS] Crawford,M., "Binary Labels in the Domain Name System",
draft-ietf-dnsind-binary-labels-XX.txt, work in progress
11. Author's Address
Peter Koch
Universitaet Bielefeld
Technische Fakultaet
Postfach 10 01 31
D-33501 Bielefeld
Germany
Koch Expires December 1999 [Page 8]
INTERNET-DRAFT DNS Compression June 1999
+49 521 106 2902
<pk@TechFak.Uni-Bielefeld.DE>
Koch Expires December 1999 [Page 9]

5
doc/draft/draft-ietf-dnsind-local-compression-06.txt Normal file
View File

@ -0,0 +1,5 @@
This Internet-Draft has expired and is no longer available.
Unrevised documents placed in the Internet-Drafts directories have a
maximum life of six months. After that time, they must be updated, or
they will be deleted. This document was deleted on March 20, 2000.

648
doc/draft/draft-ietf-dnsind-rollover-00.txt
View File

@ -1,648 +0,0 @@
INTERNET-DRAFT DNSIND Key Rollover
UPDATES RFC 1996 April 1999
Expires October 1999
draft-ietf-dnsind-rollover-00.txt
Domain Name System (DNS) Security Key Rollover
------ ---- ------ ----- -------- --- --------
Donald E. Eastlake 3rd, Mark Andrews
Status of This Document
This draft, file name draft-ietf-dnsind-rollover-00.txt, is intended
to be become a Proposed Standard RFC. Distribution of this document
is unlimited. Comments should be sent to the DNS working group
mailing list <namedroppers@internic.net> or to the authors.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``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
Deployment of Domain Name System (DNS) security with good cryptologic
practice will involve large volumes of key rollover traffic. A
standard format and protocol for such messages will be necessary for
this to be practical and is specified herein.
[Note: this draft has been moved to dnsind from dnssec as part of the
ongoing combination of these working groups. It would have been
draft-ietf-dnssec-rollover-01.txt otherwise.]
D. Eastlake 3rd, M. Andrews [Page 1]
INTERNET-DRAFT April 1999 DNSSEC Key Rollover
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................3
2. Key Rollover Scenario...................................3
3. Rollover Operation......................................5
3.1 Rollover to Parent.....................................5
3.2 Rollover to Children...................................6
4. Secure Zone Cuts and Joinders...........................7
5. Security Considerations.................................8
6. IANA Considerations.....................................9
References................................................10
Authors Address...........................................10
Expiration and File Name..................................11
D. Eastlake 3rd, M. Andrews [Page 2]
INTERNET-DRAFT April 1999 DNSSEC Key Rollover
1. Introduction
The Domain Name System (DNS) [RFC 1034, 1035] 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 2535].
The principle security service provided for DNS data is data origin
authentication. The owner of each zone signs the data in that zone
with a private key known only to the zone owner. Anyone that knows
the corresponding public key can then authenticate that zone data is
from the zone owner. To avoid having to preconfigure resolvers with
all zone's public keys, keys are stored in the DNS with each zone's
key signed by its parent (if the parent is secure).
To obtain high levels of security, keys must be periodically changed,
or "rolled over". The longer a private key is used, the more likely
it is to be compromised due to cryptanalysis, accident, or treachery
[RFC 2541].
In a widely deployed DNS security system, the volume of update
traffic will be large. Just consider the .com zone. If only 10% of
its children are secure and change their keys only once a year, you
are talking about hundreds of thousands of new child public keys that
must be securely sent to the .com manager to sign and return with
their new parent signature. And when .com rolls over its private
key, it will needs to send hundred of thousands of new signatures on
the existing child public keys to the child zones.
It will be impractical to handle such update volumes manually on a
case by case basis. The bulk of such key rollover updates must be
automated.
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document are to be interpreted as described in [RFC 2119].
2. Key Rollover Scenario
Although DNSSEC provides for the storage of other keys in the DNS for
other purposes, DNSSEC zone keys are included solely for the purpose
of being retrieved to authenticate DNSSEC signatures. Thus, when a
zone key is being rolled over, the old public key should be left in
the zone, along with the addition of the new public key, for as long
as it will reasonably be needed to authenticate old signatures that
have been cached or are held by applications. Similarly, old parent
SIGs should be retained for a short time after a parent KEY(s) roll
over and new parent SIGs have been installed.
D. Eastlake 3rd, M. Andrews [Page 3]
INTERNET-DRAFT April 1999 DNSSEC Key Rollover
If DNSSEC were universally deployed and all DNS server's clocks were
synchronized and zone transfers were instantaneous etc., it might be
possible to avoid ever having duplicate old/new KEY/SIG RRsets due to
simultaneous expiration of SIGs everywhere in the DNS. But these
assumptions do not hold. Security aware DNS servers decrease the TTL
of secure RRs served as the expiration of their authenticating SIG(s)
approaches but some dithered fudge must generally be left due to
clock skew, RR retention by applications, and the like. Retaining
old KEYs for a while after rolling over to new KEYs will be necessary
in practical cases.
Assume a middle zone with a secure parent and a secure child wishes
to role over its KEY RRset. This RRset would probably be one KEY RR
per crypto algorithm used to secure the zone, but for this scenario,
we will simply assume it is one KEY RR. The old KEY RR and two SIG
RRs will exist at the apex of the middle zone. (These RRs may also
exist at the leaf node for this zone in its parent if the parent
chooses to store them there.) The contents of the middle zone and the
zone KEY RRs of its secure child will have SIGs under the old key.
The middle zone owner needs to communicate with its parent to obtain
a new parental signature covering both the old and new KEY RRs and
covering just the new KEY RR. The signature on both is needed so the
old KEY can be retain for the period it might be needed to
authenticate old SIGs. The middle zone would probably want to obtain
these in advance so that it can install them at the right time along
with its new SIG RRs covering the content of its zone. Finally, it
needs to give new SIG RRs to its child that cover its KEY RRs so it
must signal its children to ask for such SIG RRs.
BEFORE ROLLOVER SHORTLY AFTER AFTER ROLLOVER
p.x KEY P1 p.x KEY P1 p.x KEY P1
p.x SIG(KEY) P1 p.x SIG(KEY) P1 p.x SIG(KEY) P1
p.x SIG(KEY) GP p.x SIG(KEY) GP p.x SIG(KEY) GP
m.p.x KEY M1 m.p.x KEY M2 m.p.x KEY M2
m.p.x SIG(KEY) P1 m.p.x KEY M1 m.p.x SIG(KEY) P1
m.p.x SIG(KEY) M1 m.p.x SIG(KEY) P1 m.p.x SIG(KEY) M2
m.p.x SIG(KEY) M2
c.m.p.x KEY C1 c.m.p.x KEY C1 c.m.p.x KEY C1
c.m.p.x SIG(KEY) M1 c.m.p.x SIG(KEY) M2 c.m.p.x SIG(KEY) M2
c.m.p.x SIG(KEY) C1 c.m.p.x SIG(KEY) M1 c.m.p.x SIG(KEY) C1
c.m.p.x SIG(KEY) C1
p = parent, m = middle, c = child, GP = grandparent key
P* = parent key, M* = middle zone key, C* = child key
D. Eastlake 3rd, M. Andrews [Page 4]
INTERNET-DRAFT April 1999 DNSSEC Key Rollover
3. Rollover Operation
Rollover operations use a DNS request syntactically identical to the
UPDATE request [RFC 2136] (except that the operation code is ROLLOVER
which is equal to (TBD)) and use a new form of NOTIFY [RFC 1996].
Considerations for such requests to the parent and children of a zone
are givens below.
All rollover operations involve significant amounts of cryptographic
calculations. Appropriate rate limiting SHOULD be applied to avoid
denial of service attacks.
[This draft does not consider cross-certification key rollover.]
3.1 Rollover to Parent
A zone rolling over its KEY RRset sends an upward ROLLOVER request to
its parent. Actually, it will normally do two upward ROLLOVERs, one
for a combined KEY RRset of its old and new KEYs and one for just its
new KEY RRset, as discussed above.
The server selection algorithm in [RFC 2136] section 4 should be
used. A child needs to be configured with or determine the name of
its parent but SHOULD NOT remember the location of its parent other
than via normal DNS caching of address RRs so that rollover will
continue to work if its parent servers are moved.
The ROLLOVER request Zone should be specified as the parent zone.
The request Update section has the new KEY RRset on which the parent
signature is requested along with the requesting zone's SIG(s) under
its old KEY(s) as RRs to be "added" to the parent zone. The
inception and expiration times in this child SIG or SIGs are the
requested inception and expiration times for the new parent SIG(s).
The "prerequisites" section has the old child KEY RRset with the
parent SIG (see next paragraph).
An upward ROLLOVER request MUST be signed and if not signed a BADAUTH
response generated. The signature MUST be under the previous zone
KEY, so the parent can validate it, or under a valid TSIG key
[draft-ietf-dnsind-tsig-*.txt] arranged with the parent. Including
the "prerequisite" section as specified above enables a parent that
keeps no record of its children's KEYs to still authenticate a
child's ROLLOVER request based on the old child KEY because the
parent is presented with its own SIG on the old KEY.
If the ROLLOVER command is erroneous or violates parental policy, an
Error response is returned. If a parent retains copies of its
children's KEYs, it may use that knowledge to validate ROLLOVER
D. Eastlake 3rd, M. Andrews [Page 5]
INTERNET-DRAFT April 1999 DNSSEC Key Rollover
request SIGs and ignore the "prerequisites" section.
If the ROLLOVER command is OK and the parent can sign online, its
response MAY include the new parent SIG(s) in the response Update
section. This response MUST be sent to the originator of the
request.
If the parent can not sign online, it should return a response with
an empty Update section and queue the SIG(s) calculation request.
This response MUST be sent to the originator of the request.
ROLLOVER response messages MUST always include the actual parent's
SOA signed with a key the child should recognize in the Additional
Information section (see section 4 below).
Regardless of whether the server has sent the new signatures above,
it MUST, once it has calculated the new SIG(s), send a ROLLOVER to
the child zone using the DNS port (53) and the server selection
algorithm defined in RFC 2136, Section 4. This ROLLOVER reqeust
contains the KEY RRset that triggered it and the new SIG(s). There
are several reasons for sending the ROLLOVER response regardless of
whether the new SIG RR(s) were sent in the original response. One is
to provide an indication to the operators of the zone in the event
someone is trying to hijack the zone. Another is that this maximizes
the probability of the response getting through.
Although the parent zone need not hold or serve the child's key, if
it does the ROLLOVER command REQUEST SHOULD NOT automatically update
the parent zone. A later UPDATE command can be used to actually put
the new KEY into the parent zone if desired and supported by parent
policy.
This document does not cover the question of parental policy on key
rollovers. Parents may have restrictions on how far into the future
they will sign KEY RRsets, what algorithms or key lengths they will
support, might require payment for the service, etc. The signing of
a future KEY by a parent is, to some extent, a granting of future
authoritative existence to the controller of the child private key
even if the child zone ownership should change. The only effective
way of invalidating such future signed child public keys would be for
the parent to roll over its key(s), which might be an expensive
operation.
3.2 Rollover to Children
When a secure zone is going to rollover its key(s), it needs to re-
sign the zone keys of any secure children under its new key(s). The
parent simply notifIES the child via a rollover NOTIFY [RFC 1996]
D. Eastlake 3rd, M. Andrews [Page 6]
INTERNET-DRAFT April 1999 DNSSEC Key Rollover
that the parent KEY(s) have changed. The child then proceeds to do
an upward ROLLOVER request, as described in 3.1 above to obtain the
new parental SIG(s).
A rollover NOTIFY is a NOTIFY request [RFC 1996] that has a QTYPE of
SIG and the owner name of the child zone. The answer section has the
current parent SOA signed by a key the child will know (see section
4).
A rollover NOTIFY MUST be signed and if not signed a BADAUTH response
generated. The signature MUST be under the previous parental zone
KEY, so the child can validate it, or under a valid TSIG key [draft-
ietf-dnsind-tsig-*.txt] negotiated between parent and child.
The rollover NOTIFY can be sent to any of the nameservers for the
child using the nameserver selection algorithm defined in RFC 2136,
Section 4. Nameservers for the child zone receiving a rollover
NOTIFY query will forward the rollover NOTIFY in the same manner as
an UPDATE is forwarded.
Unless the master server is configured to initiate an automatic
ROLLOVER it MUST seek to inform its operators that a rollover NOTIFY
request has been received. This could be done by a number of methods
including generating a log message, generating an email request to
the child zone's SOA RNAME or any other method defined in the
server's configuration for the zone. The default SHOULD be to send
mail to the zone's SOA RNAME. As with all rollover operations, care
should be taken to rate limit these messages so prevent them being
used to facilitate a denial of service attack.
Once the message has been sent (or suppressed if so configured) to
the child zone's administrator the master server for the child zone
is free to respond to the rollover NOTIFY request.
4. Secure Zone Cuts and Joinders
There are two other events that have some similarity to key rollover.
The first is when a secure zone the is more than one level deep has a
zone cut introduced inside it. For example, assume zone example.com
has a.b.c.example.com, d.b.c.example.com and e.example.com in it. A
zone cut could be introduced such that b.c.example.com became a
separate child zone of example.com. A real world exampe would be a
company that structures its DNS as host.branch.company.example. It
might start out will all of these names in one zone but later decide
to delegate all or some of the branches to branch zone file
maintainers.
D. Eastlake 3rd, M. Andrews [Page 7]
INTERNET-DRAFT April 1999 DNSSEC Key Rollover
The second is when a secure zone absorbs a child zone eliminating a
zone cut. This is simply the inverse of the previous paragraph.
From the point of view of the parent zone above the splitting zone or
above the upper of the two combining zones, there is no change.
When a zone is split by introducing a cut, the newly created child
must be properly configured.
However, from the point of view of a child of the splitting zone
which becomes a grandchild or a grandchild that becomes a child due
to joinder, there is a change in parent name. Therefore, in general,
there is a change in parent KEY(s). Unless the entity that handles
rollovers for the zone whose parent name has changed is appropriately
updated, future automated rollover will fail because it will be sent
to the old parent.
For this reason and so that other consistency checks can be made, the
parent SOA and SIG(SOA) are always included in the Answer section of
rollover NOTIFY requests and in ROLLOVER responsess. For automated
rollover to the new cut or joined state to work, these SOAs must be
signed with old KEY(s) of the former parent so the signatures can be
validated by the zone whose parent name is changing. In the case of
a joinder, if the private key of the pinched out middle zone is not
available, then manual update of the former grandchild, now child,
will be necessary. In the case of introducing a cut, operational
coordination with the former parent, now grandparent, signing the
initial updates to the former child, now grandchild, will be needed
to automate the reconfiguration of the zones.
5. Security Considerations
The security of ROLLOVER or UPDATE requests is essential, otherwise
false children could steal parental authorization or a false parent
could cause a child to install an invalid signature on its zone key,
etc.
A ROLLOVER request can be authenticated by request SIG(s)under the
old zone KEY(s) of the requestor [RFC 2535]. The response SHOULD
have transaction SIG(s) under the old zone KEY(s) of the responder.
(This public key security could be used to rollover a zone to the
unsecured state but at that point it would generally not be possible
to roll back without manual intervention.)
Alternatively, if there is a prior arrangement between a child and a
parent, ROLLOVER requests and responses can be secured and
authenticated using TSIG [draft-ietf-dnsind-tsig-*.txt]. (TSIG
security could be used to rollover a zone to unsecured and to
D. Eastlake 3rd, M. Andrews [Page 8]
INTERNET-DRAFT April 1999 DNSSEC Key Rollover
rollover an unsecured zone to the secured state.)
A server that implements online signing SHOULD have the ability to
black list a zone and force manual processing or demand that a
particular signature be used to generate the ROLLOVER request. This
it to allow ROLLOVER to be used even after a private key has been
compromised.
6. IANA Considerations
The DNS operation code (TBD) is assigned to ROLLOVER. There are no
other IANA considerations in this document.
D. Eastlake 3rd, M. Andrews [Page 9]
INTERNET-DRAFT April 1999 DNSSEC Key Rollover
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 1996] - "A Mechanism for Prompt Notification of Zone Changes
(DNS NOTIFY)", P. Vixie, August 1996.
[RFC 2119] - "Key words for use in RFCs to Indicate Requirement
Levels", S. Bradner. March 1997.
[RFC 2136] - "Dynamic Updates in the Domain Name System (DNS
UPDATE)", P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April
1997.
[draft-ietf-dnsind-tsig-*.txt]
[RFC 2535] - "Domain Name System Security Extensions", D. Eastlake.
March 1999.
[RFC 2541] - "DNS Security Operational Considerations", D. Eastlake.
March 1999.
Authors Address
Donald E. Eastlake 3rd
IBM
65 Sindegan Hill Road, RR #1
Carmel, NY 10512
Telephone: +1 914-276-2668 (h)
+1 914-784-7913 (w)
FAX: +1 914-784-3833 (w)
EMail: dee3@us.ibm.com
Mark Andrews
Internet Software Consortium
1 Seymour Street
Dundas Valley, NSW 2117
AUSTRALIA
Telephone: +61-2-9871-4742
Email: marka@isc.org
D. Eastlake 3rd, M. Andrews [Page 10]
INTERNET-DRAFT April 1999 DNSSEC Key Rollover
Expiration and File Name
This draft expires in October 1999.
Its file name is draft-ietf-dnsind-rollover-00.txt.
D. Eastlake 3rd, M. Andrews [Page 11]

5
doc/draft/draft-ietf-dnsind-rollover-01.txt Normal file
View File

@ -0,0 +1,5 @@
This Internet-Draft has expired and is no longer available.
Unrevised documents placed in the Internet-Drafts directories have a
maximum life of six months. After that time, they must be updated, or
they will be deleted. This document was deleted on March 20, 2000.

663
doc/draft/draft-ietf-dnsind-sec-rr-00.txt
View File

@ -1,663 +0,0 @@
DNSIND WG Edward Lewis
INTERNET DRAFT NAI Labs
Category: I-D Jerry Scharf
ISC
Olafur Gudmundsson
NAI Labs
June 25, 1999
The SEC Resource Record
<draft-ietf-dnsind-sec-rr-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet- Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Comments should be sent to the authors or the DNSIND WG mailing list
namedroppers@internic.net.
This draft expires on December 25, 1999.
Copyright Notice
Copyright (C) The Internet Society (1999). All rights reserved.
Abstract
A new DNS reseource record, the SECurity RR, is defined to address
concerns about the parent zone's holding of the child zone's KEY RR
set. These concerns are addressed in a manner that retains the
information needed by a secure resolver when asking a parent zone
about the child zone. This proposal updates RFC 2535 and RFC 2181.
1. Introduction
DNS security extensions require a signed zone to hold KEY RR sets for
each of its delegations. This requirement has four negative
implications for the top level domains, which, for the most part,
consist of delegation points. (These issues also impact other
delegating zones, these problems are not unique to the TLDs.)
Addressing these concerns by removing the requirement for the KEY RR
in the parent has an adverse effect on secure resolution of DNS
Expires December 25, 1999 [Page 1]
Internet Draft June 25, 1999
signatures. A new DNS reseource record, the SECurity RR, is defined
to address these concerns.
The Zone Key Referral, described in another draft by the same authors,
is one proposed response to the concerns about parent's holding child
keys. However, that proposal has two drawbacks. One, it results in
two KEY RR sets at a delegation, one in the parent and one in the
child, which differ. It also does not address the expression of
security parameters, such as whether or not the child zone uses the
NXT record (which is currently mandatory).
This document will begin by repeating the arguments against the
holding of keys at the parent as presented in the Zone Key Referral.
The document will then present the need for information about the
child to be held in parent. Following this, the SEC RR will be
defined, its master file representation discussed, and implications on
name servers.
(Editorial note. Sections 1.1 through 1.5 are copied nearly verbatim
from the Zone Key Referral so that retirement of that draft will not
cause a problem.)
1.1 Reasons for removing the KEY data from the parent
There are a number of different reasons for the removal of the KEY RR
from the parent. Reasons include:
o the performance impact that holding keys has on name servers
o the problem of updating a widely delegated parent zone on demand
o statements in RFC 2181 on authoritative data at delegations
o perceived liability of the operator of a name server or registry
1.2 Performance Issues
A sample zone will be used to illustrate the problem. The example
will part from reality mostly in the length of zone names, which
changes the size of the owner and resource record data fields.
Expires December 25, 1999 [Page 2]
Internet Draft June 25, 1999
# $ORIGIN test.
# @ IN SOA <SOA data>
# IN SIG SOA <by test.>
# IN KEY <1024 bit zone key>
# IN SIG KEY <by test.>
# IN SIG KEY <by .>
# IN NS ns.test.
# IN SIG NS <by test.>
# IN NXT my-org.test. NS SOA SIG KEY NXT
# IN SIG NXT <by test.>
#
# my-org IN KEY <1024 bit zone key>
# IN KEY <1024 bit zone key>
# IN SIG KEY <by test.>
# IN NS ns1.my-org.test.
# IN NS ns2.my-org.test.
# IN NXT that-org.test. NS SIG KEY NXT
# IN SIG NXT <by test.>
#
# that-org IN KEY 0xC100 3 255
# IN SIG KEY <by test.>
# IN NS ns1.that-org.test.
# IN NS ns2.that-org.test.
# IN NXT test. NS SIG KEY NXT
# IN SIG NXT <by test.>
In this zone file, "my-org" is a delegation point of interest with two
registered public keys. Presumably, one key is for signatures
generated currently and the other is for still living and valid but
older signatures. "that-org" is another delegation point, with a NULL
key. This signifies that this zone is unsecured.
To analyze the performance impact of the storing of keys, the number
of bytes used to represent the RRs in the procotol format is used.
The actual number of bytes stored will likely be higher, accounting
for data structure overhead and alignment. The actual number of bytes
transferred will be lower due to DNS name compression.
The number of bytes for my-org's two 1024-bit keys, two NS records,
NXT and the associated signatures is 526. (1024 bit RSA/MD5 keys were
used for the calculation.) The bytes needed for that-org (with the
NULL key) is 346. Currently, there are close to 2 million entries in
com., so if we take my-org as a typical domain, over 1GB on memory
will be needed for com. The zone keys used in the example are set to
1024 bits. This number may range from as low as 512 bits upwards to
over 3000 bits.
The increased size of the data held for the zone cuts will have two
impacts at the transport and below layers. Bandwidth beyond that
currently needed will be used to carry the KEY records. The inclusion
of all of the child's keys will also push DNS over the UDP size limit
and start using TCP - which could cause critical problems for current
Expires December 25, 1999 [Page 3]
Internet Draft June 25, 1999
heavily used name servers, like the root and TLD name servers. EDNS0
[RFC-to-be] addresses expansion of UDP message size, which alleviates
this problem.
Another impact, not illustrated by the example, is the frequency of
updates. If each time a public key for my-org is added or deleted,
the SOA serial number will have to increase, and the SOA signed again.
If an average zone changes the contents of its key RR set once per
month, there will be on average 45 updates per minute in a zone of 2
million delegations. (This estimate does not address the fact that
signatures also expire, requiring a new signing of the zone
periodically.)
1.3 Security Incident Recovery (w/ respect to keys only)
Once a zone administrator is alerted that any key's private
counterpart has been discovered (exposed), the first action to be
taken is to stop advertising the public key in DNS. This doesn't end
the availability of the key - it will be residing in caches and given
in answers from those caches - but is the closest action resembling
revokation available in DNS.
Stopping the advertisement in the zone's name servers is as quick as
altering the master file and restarting the name server. Having to do
this in two places will will only delay the time until the recovery is
complete.
For example, a registrar of a top level domain has decided to update
its zone only on Mondays and Fridays due to the size of the zone. A
customer/delegatee is the victim of a break in, in which one of the
items taken is the file of private keys used to sign DNS data. If this
occurs on a Tuesday, the thief has until Friday to use the keys before
they disappear from the DNS, even if the child stops publishing them
immediately.
If the public key set is in the parent zone, and the parent zone is
not able to make the change quickly, the public key cannot be revoked
quickly. If the parent only refers to there being a key at the child
zone, then the child has the agility to change the keys - even issue a
NULL key, which will force all signatures in the zone to become
suspect.
1.4 DNS Clarifications
RFC 2181, section 6, clarifies the status of data appearing at a zone
cut. Data at a zone cut is served authoritatively from the servers
listed in the NS set present at the zone cut. The data is not
(necessarily) served authoritatively from the parent. (The exception
is in servers handling both the parent and child zone.)
Section 6 also mentions that there are two exceptions created by
DNSSEC, the NXT single record set and the KEY set. This proposal
addresses the exception relating to the KEY set, by removing the set
Expires December 25, 1999 [Page 4]
Internet Draft June 25, 1999
from the parent. The SEC RR is introduced and belongs in the parent
zone, there is no counterpart in the child (at the apex).
1.5 Liability
Liability is a legal concept, so it is not wise to attempt an
engineering solution to it. However, the perceived liability incurred
in using DNSSEC by registrars may prevent the adoption of DNSSEC.
Hence DNSSEC should be engineered in such a way to address the
concern.
One source of liability is the notion that by advertising a public key
for a child zone, a parent zone is providing a service of security.
With that comes responsibility. By having the parent merely indicate
that a child has a key (or has no key), the parent is providing less
in the way of security. If the parent is wrong, the potential loss is
less. Instead of falsely authenticated data, configuration errors
will be apparent to the resolving client.
Whether or not the KEY RR remains advertised in the parent zone or the
SEC RR is in place, the parent zone administrators still have to
adhere to proper key handling practices, which are being documented in
DNSOP draft. In particular, the parent has to be sure that the keys
it is signing for a child have been submitted by the true
administrator of the the child zone, and not submitted by an imposter.
1.6 The needs of the resolver
Now that the reasons for removing the child's keys from the parent
zone have been presented, reasons why something must take their place
are presented. A "secure" resolver is a DNS resolver that receives an
answer and, if a signature arrives, verifies the signature. Most
often, this operation will happen in resolvers that are part of name
servers, as opposed to general purpose hosts.
The first step in authenticating a DNS response is to see if the data
is accompanied by a signature. There are five possible outcomes.
Three results are not desirable, a signature may arrive but shouldn't,
no signature arrives but should, or a signature arrives but uses the
wrong cryptographic algorthm Two outcomes can be considered
successful, a signature arriving with the correct algorithm or no
signature arrives and shouldn't. (There is one other case - a
signature generated with an inappropriate key - which is a matter
beyond the scope of this draft.)
Since the resolver can not instantly know whether a signature is
expected, the resolver must start a discovery process. This process
can be done by the resolver querying zones between the root and the
desired domain for information about the next successive zones.
(Optimizing this search is not presented here.) For this search to be
successful, the parent must hold something that indicates the status
of the child's security, so the resolver may search with certainty.
While refraining from using the word "policy" to describe the data,
the phrase "security parameters" is used.
Expires December 25, 1999 [Page 5]
Internet Draft June 25, 1999
The security parameters of a zone are not entirely defined yet, and
will remain open until a critical mass of operations experience is
gained. Initially, the following information is known to be needed.
The set of algorithms in use by the zone.
KEY RRs and SIG RRs have protocol fields indicating how the key is
made. For now, two are in distribution, a value of 1 for RSA/MD5 and
3 for DSA. Unfortunately, the value are numeric in 8 bits, so a
bitmap representation cannot be used.
The mechanism for negative answers.
Currently, the NXT is mandatory, liked by some administrators and
disliked by other administrators. NXTs cannot be made optional, doing
so makes them obsolete. (An attacker can make the responses look like
a zone doesn't use NXTs, even if the zone does.) If the choice of NXT
or no NXT can be securely indicated, then this is solved. There have
been discussions on alternatives to the NXT record. By allowing a
zone to indicate the style of negative answer in use, alternatives can
be installed in experimental zones.
Signature policy.
This is an untested issue. Expressing a policy, such as whether
multiple algorithms are used, whether verification of one signature
needed or all signatures, etc., has not been fully studied.
2. The SEC RR
The SEC RR is a record that describes the DNS security parameters of
the owner. The owner MUST also have an NS RR set, i.e., the owner
MUST be a cut point. A signed zone MUST have a SEC RR set for each
delegation point.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Negative Answer Bitmap | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Security Parameters ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RDATA of the SEC RR
The SEC RR RDATA contains two data fields. One is a 16-bit field
acting as a bitmap to indicate the means used to signify a negative
answer. The other field is an unbounded field of option-value pairs
indicating other salient settings for the zone. The latter field is
not padded to any particular byte boundary.
The SEC RR is answered authoritatively from the parent zone, and is
signed by the parent. A properly configured delegation point in the
parent would have just an SEC RR, records used for negative answering,
and a glue NS set. The corresponding point in the child (the zone's
apex) would have the SOA, KEY set, NS records, negative answer
Expires December 25, 1999 [Page 6]
Internet Draft June 25, 1999
records, and other desired and legal RR sets. SIG RR's appear in both
the parent and child side of the delegation.
There is no other special processing of the SEC RR set. It is used in
a reply as an answer when it is the subject of a direct query (QTYPE
IS SEC) or when a QTYPE=ANY reaches the delegating zone. If a name
server is authoritative for both the parent and child, the SEC is
included in the ANY reply for the delegation point.
(Editorial note: this region is in particular need of careful review.)
The SEC RR for a name SHOULD be supplied optionally in the additional
data section if the CD bit is not set whenever a zone's NS or KEY set
is requested. If a request for a KEY set is sent to a parent-only
server and the server is not recursive, the server should add the SEC
record to the additional section of the referral message.
If a name server authoritative for a child zone is asked for its SEC
RR and the server has never learned the SEC RR (whether through
caching the record or by also loading the parent zone), the server MAY
answer with a negative answer. The resolver seeking a SEC RR SHOULD
know to ask for this from a parent-serving name server.
2.1 Negative Answer Bitmap
The Negative Answer Bitmap indicates the mechanism for use in denying
the existance of data. The bitmap is 16 bits, the most significant
bit called 0, least significant is 15.
Bit 0 = The parent doesn't know what the child uses (1=Yes)
Bit 1 = The child signs its negative answers (1=Yes)
Bit 2 = The child follows traditional DNS rules (1=yes)
Bit 3 = The child uses the NXT record (1=yes)
Bit 14 = The child uses a locally defined mechanism (1=yes)
Bit 15 = The length of the bit field has been extended (1=yes)
Bits 4 through 14 are currently unassigned, and are under the purview
of IANA. Bit 15 MUST BE zero. (This specification must be
superceeded to define an extension mechanism.)
A zone may use multiple mechanisms to indicate a negative answer. A
zone SHOULD expect that a resolver finding any one of the mechanisms
used in a reply indicates a negative answer, i.e. the mechanisms are
OR'd together.
The only illegal values for this bit field are:
Bit 0 = 1 and any other bit turned on
Bit 0 = 0, Bit 1 = 1, and no other bit turned on
Bit 15 = 1
2.1.1 Bit 0 (Better titles will be attached later)
The situation in which this bit is on should not arise, but it is
defined to be safe. The philosophy behind this is that security
Expires December 25, 1999 [Page 7]
Internet Draft June 25, 1999
parameters should always be made explicit, including when a sitation
is unclear.
2.1.2 Bit 1
This bit indicates that the child attachs SIG records to the resource
records used in the negative answer. For example, this may indicate
that the reslover should expect to see a SIG (NXT) when an NXT is
returned.
2.1.3 Bit 2
The child will answer with an SOA or any of the other means used in
the past to indicate a negative answer. (I think a reference to the
negative answer/cache document should go here.)
2.1.4. Bit 3
The child uses the NXT as defined in RFC 2535. This document declares
that the use of the NXT is optional, a deviation from RFC 2535.
2.1.5 Bit 14
The child is using a mechanism that is not globally defined. A zone
should be in such a state for only experimental reasons and realize
that in this state, the negative answers it gives may not be useful to
the general population of resolvers.
2.1.6 Bit 15
As of this specification, this bit must be 0 (zero).
2.1.7 Unallocated bits
The remainder of the bits must also be zero. A procedure will be
defined for allocating them.
2.2 Security Parameters
The Security parameters is a sequence of options and values. An
option is a numeric indicatior of the parameter. The value is usually
either a yes or no, or a enumerated value. In rare instances, an
option may require variable length data, in this case a triplet of
option-length-value is used. The presence of the length field is
indicated by the most significant bit in the option field being 1.
Due to the nature of the SEC RR, the length field is not commonly
used.
The option field is 8 bits. The most significant bit of the options
field is turned on if there is a length field. The value field is
also 8 bits. If the option-length-value is needed, the length is 8
bits and contains the number of octets comprising the value. No
padding is used.
Expires December 25, 1999 [Page 8]
Internet Draft June 25, 1999
An option may appear multiple times in the Security Parameters. The
sequencing of the options is not significant. If two options
contradict each other, this is an error, and is noted by the resolver.
A self-contradictory SEC RR is a security error and data from the zone
covered by it SHOULD be considered at risk.
Option Values are
0 Reserved
1 Zone is unsigned
2 Key Algorithm in use
3 Signing policy
0x70-0x7F Locally defined (no length field)
0xF0-0xFF Locally defined (uses length field)
All unassigned option values are under the control of IANA. Values 0
to 127 do not use the length field, values 128 to 255 do use the
length field. The option value is to be treated as unsigned.
2.2.1 Option 0
This option is reserved for future definition.
2.2.2 Option 1
The parent has not signed a KEY RR for the child, therefore the child
zone has no DNSSEC approved signing keys. If this option is not
present, then the resolver SHOULD assume that there are zone keys in
the child zone.
If the value of this is non-zero, this assertion is true. If the
value is zero, this assertion is false. If the parent has signed keys
for the child, the value is zero, however, in this case, the parent
SHOULD NOT include this option in the security parameters.
It is tempting to exclude an unsigned zone option from this list,
relying on the absence of any in use key algorithms (option 2) to
imply that the zone is unsigned. The unsigned option is included to
make this information explicit, so that when analyzing a running zone,
it is obvious to an administrator that a zone is unsigned.
2.2.3 Option 2
The parent has signed a key for the child which claims a particular
algorithm. This value field is equal to that of the algorithm field
of the triggering KEY RR.
Option 2 can be repeated for different algorithms. It is not
necessary to have multiple Option 2 entries with the same key
algorithm value.
If Option 1 and Option 2 appear in the same SEC RR, this is a
self-contradictory record. If neither Option 1 nor Option 2 appear,
this also constitues a self-contradictory record.
Expires December 25, 1999 [Page 9]
Internet Draft June 25, 1999
2.2.4 Option 3
The child has the option to require that all material signatures
(those generated by DNSSEC-approved signing keys) must be validated
(within any temporal constraints) for the data to be considered valid.
The child may instead require that just one of the signatures be
validated. This may be a reflection of the manner in which a zone's
administration is shared amongst organizations.
If Option 3 is not present (and Option 2 is), the resolver SHOULD
assume that ALL (temporally valid) signatures are required. If the
parent includes at least one Option 2, it SHOULD specify an Option 3,
with a value indicated by the child.
Values for Option 3 are
0 Reserved
1 All signatures are required
2 One signature is required
256 Locally defined
All remaining values are under the control of IANA.
(Editorial note: whether the assumption that all signatures are
necessary or just one is sufficient in the absence of this option is
open to WG debate.)
2.2.5 Options 0x70-0x7F
This option is reserved for an organization to use locally, in an
experimental fashion. This option does not use the length field.
Global interpretation of this option is undefined.
2.2.6 Options 0xF0-0xFF
This option is reserved for an organization to use locally, in an
experimental fashion. This option uses the length field. Global
interpretation of this option is undefined.
3. Master File Representation
The SEC RR fields are to be represented as hexidecimal fields, with a
preceeding '0x', or in decimal format. Hexidecimal SHOULD be used.
For example, the SEC RR representing a zone that use signed NXT
records, and has one or more DSA keys, one or more RSA keys, and
requires that just one signature be verified would be:
myzone.test. 3500 IN SEC 0x5000 0x0201 0203 0302
(0x020102030302 is one field, hence one 0x prefix.)
Hex values for the security parameters MAY BE separated by
whitespace, as shown. DNS data display routines SHOULD substitute
Expires December 25, 1999 [Page 10]
Internet Draft June 25, 1999
mnemonics for these values, but MUST write the numeric form in master
files.
4. Signature Policy
The SEC RR must be signed by one or more zone keys of the parent
(delgating) zone, and the signatures must adhere to the parent's
policy.
The SEC RR for the root zone is the lone exception, it appears at the
apex of the root zone, and must be signed sufficiently by the root's
zone key or keys.
5. Cache Considerations
When a SEC RR set for a name is held in a cache, it will have a
credibility rating indicating that the data came from the parent
(unless the parent and child share servers). When data about the same
name arrives from the child, with a higher credibility, the newly
arrived data MUST NOT cause the cache to remove the SEC RR.
6. IANA Considerations
IANA is requested to assign this RR an type parameter for DNS, and to
assign the indicated option numbers and values when requests are
approved. The procedure for requesting new options and values will be
defined in future versions of this specfication.
7. Security Considerations
This record is designed to address the concerns of securing delegation
points and resolving the security of DNS answers. This record is
important to the security because it supplies needed information and
eases the burden of security on the DNS.
The SEC RR does require one piece of additional information not
addressed to date to be communicated from the parent to the child.
This is the signature policy. This will be needed in the operations
documents.
Editorial Note: This document would benefit by a companion document
describing the process of evaluating the signatures in DNS. Such a
document would provide clearer input to the security parameters field.
8. Editorial Considerations
Although somewhat detailed in this current description, this record is
still in the formative state. The -00 document has been quickly
written to test the waters for interest.
9. References
RFC 2535 is the prime DNSSEC definition. RFC 2181 is the Clarify
document. EDNS0 reference needed...
Expires December 25, 1999 [Page 11]
Internet Draft June 25, 1999
10. Acknowledgements
This record is a successor to the Zone Key Referral, originally
promoted by John Gilmore and Jerry Scharf. A DNSSEC workshop
sponsored by the NIC-SE in May 1999 provided the enlightenment that
expanded the Zone Key Referral into the SEC RR proposal.
11. Author's Addresses
Edward Lewis Jerry Scharf Olafur Gudmundsson
NAI Labs Internet Software Consortium NAI Labs
3060 Washington Road 950 Charter St 3060 Washington Rd
Glenwood, MD 21738 Redwood City, CA 94063 Glenwood, MD 21738
+1 443 259 2352 +1 650 779 7060 +1 443 259 2389
<lewis@tislabs.com> <scharf@vix.com> <ogud@tislabs.com>
12. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Expires December 25, 1999 [Page 12]

5
doc/draft/draft-ietf-dnsind-sec-rr-01.txt Normal file
View File

@ -0,0 +1,5 @@
This Internet-Draft has expired and is no longer available.
Unrevised documents placed in the Internet-Drafts directories have a
maximum life of six months. After that time, they must be updated, or
they will be deleted. This document was deleted on March 20, 2000.