ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

draft updates

Browse Source
This commit is contained in:
Bob Halley
1999-05-12 23:51:54 +00:00
parent dd324bd791
commit 6112b0e8fa
7 changed files with 3355 additions and 456 deletions
Download Patch File Download Diff File Expand all files Collapse all files

899
doc/draft/draft-duerst-dns-i18n-01.txt Normal file
View File

@@ -0,0 +1,899 @@
Internet Draft M. Duerst
<draft-duerst-dns-i18n-01.txt> University of Zurich
Expires in six months July 1997
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 ds.internic.net (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@ifi.unizh.ch>.
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.
Table of contents
0. Change History ................................................. 2
0.8 Changes (to be) Made from Version 01 to Version 02 (or later) 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 (to be) Made from Version 01 to Version 02 (or later)
- 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,
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
Multimedia-Laboratory
Department of Computer Science
University of Zurich
Winterthurerstrasse 190
CH-8057 Zurich
Switzerland
Tel: +41 1 257 43 16
Fax: +41 1 363 00 35
E-mail: mduerst@ifi.unizh.ch
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]

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

@@ -0,0 +1,334 @@
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]

470
doc/draft/draft-ietf-dnsind-indirect-key-00.txt Normal file
View File

@@ -0,0 +1,470 @@
DNSIND Working Group D. Eastlake
INTERNET-DRAFT IBM
Expires October 1999
April 1999
draft-ietf-dnsind-indirect-key-00.txt
Indirect KEY RRs in the Domain Name System (DNS)
-------- --- --- -- --- ------ ---- ------ -----
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-ietf-dnsind-indirect-key-00.txt, is
intended to be become a Proposed Standard RFC. Distribution of this
document is unlimited. Comments should be sent to the DNSSEC mailing
list <dns-security@tis.com> 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
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.
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
[RFC 2535] defines a means for storing cryptographic public keys in
the Domain Name System. An additional code point is defined for the
algorithm field of the KEY resource record (RR) to indicate that the
key is not stored in the KEY RR but is pointed to by the KEY RR.
Encodings to indicate different types of key and pointer formats are
specified.
[This draft is moved from the DNSSEC WG as part of that WG's merger
into me DNSIND WG. It would have been draft-ietf-dnssec-indirect-
key-02.txt in the DNSSEC WG.]
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT Indirect KEY RRs
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................3
2. The Indirect KEY RR Algorithm...........................3
2.1 The Target Type Field..................................4
2.2 The Target Algorithm Field.............................5
2.3 The Hash Fields........................................5
3. Performance Considerations..............................6
4. IANA Considerations.....................................6
5. Security Considerations.................................6
References.................................................7
Author's Address...........................................7
Expiration and File Name...................................8
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT Indirect KEY RRs
1. Introduction
The Domain Name System (DNS) security extensions [RFC 2535] provide
for the general storage of public keys in the domain name system via
the KEY resource record (RR). These KEY RRs are used in support of
DNS security and may be used to support other security protocols.
KEY RRs can be associated with users, zones, and hosts or other end
entities named in the DNS.
For reasons given below, it will sometimes be desireable to store a
key or keys elsewhere and merely point to it from the KEY RR.
Indirect key storage makes it possible to point to a key service via
a URL, to have a compact pointer to a larger key or set of keys, to
point to a certificate either inside DNS [RFC 2538] or outside the
DNS, and where appropriate, to store a key or key set applicable to
many DNS entries in some place and point to it from those entries.
However, to simplify DNSSEC implementation, this technique MUST NOT
be used for KEY RRs used in for verification in DNSSEC, i.e., the
value of the "protocol" field of an indirect KEY RR MUST NOT be 3.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD",
"RECOMMENDED", and "MAY" in this document are to be interpreted as
described in [RFC 2119].
2. The Indirect KEY RR Algorithm
Domain Name System (DNS) KEY Resource Record (RR) [RFC 2535]
algorithm number 252 is defined as the indirect key algorithm. This
algorithm MAY NOT be used for zone keys in support of DNS security.
All KEYs used in DNSSEC validation MUST be stored directly in the
DNS.
When the algorithm byte of a KEY RR has the value 252, the "public
key" portion of the RR is formated as follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| target type | target alg. | hash type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash size | hash (variable size) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
| /
/ pointer (variable size) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT Indirect KEY RRs
2.1 The Target Type Field
Target type specifies the type of the key containing data being
pointed at.
Target type
-----------
0 - reserved, see section 4
1 - indicates that the pointer is a domain name from which KEY RRs
[RFC 2535] should be retrieved. Name compression in the pointer
field is prohibited.
2 - indicates that the pointer is a null terminated character string
which is a URL [RFC 1738]. For exisiting data transfer URL
schemes, such as ftp, http, shttp, etc., the data is the same as
the public key portion of a KEY RR. (New URL schemes may be
defined which return multiple keys.)
3 - indicates that the pointer is a domain name from which CERT RRs
[RFC 2538] should be retrieved. Name compression in the pointer
field is prohibited.
4 - indicates that the pointer is a null terminated character string
which is a URL [RFC 1738]. For exisiting data transfer URL
schemes, such as ftp, http, shttp, etc., the data is the same as
the entire RDATA portion of a CERT RR [RFC 2538]. (New URL
schemes may be defined which return multiple such data blocks.)
5 - indicates that the pointer is a null terminated character string
which is a URL [RFC 1738]. For exisiting data transfer URL
schemes, such as ftp, http, shttp, etc., the data is a PKCS#1 [RFC
2437] format key. (New URL schemes may be defined which return
multiple keys.)
6 through 255 - available for assignment, see section 4.
256 through 511 (i.e., 256 + n) - indicate that the pointer is a null
terminated character string which is a URL [RFC 1738]. For
exisiting data transfer URL schemes, such as ftp, http, shttp,
etc., the data is a certificate of the type indicated by a CERT RR
[RFC 2538] certificate type of n. That is, target types 257, 258,
and 259 are PKIX, SPKI, and PGP certificates and target types 509
and 510 are URL and OID private certificate types. (New URL
schemes may be defined which return multiple such certificates.)
512 through 65534 - available for assignment, see section 4.
65535 reserved, see section 4.
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT Indirect KEY RRs
2.2 The Target Algorithm Field
The algorithm field is as defined in [RFC 2535]. If non-zero, it
specifies the algorithm type of the target key or keys pointed. If
zero, it does not specify what algorithm the target key or keys apply
to.
2.3 The Hash Fields
If the indirecting KEY RRset [RFC 2181, 2535] is retrieved from an
appropriately secure DNS zone with a resolver implementing DNS
security, then there would be a high level of confidence in the
entire value of the KEY RRset including any direct keys. This may or
may not be true of any indirect key pointed to. If an indirect key
is embodied in a certificate or retrieved via a secure protocol such
as SHTTP, it may also be secure. But an indirecting KEY RR could,
for example, simply have an FTP URL pointing to a binary key stored
elsewhere, the retrieval of which would not be secure.
The hash option in algorithm 252 KEY RRs provides a means of
extending the security of the indirecting KEY RR to the actual key
material pointed at. By including a hash in a secure indirecting RR,
this secure hash can be checked against the hash of the actual keying
material
Type Hash Algorithm
---- --------------
0 indicates no hash present
1 MD5 [RFC 1321]
2 SHA-1
3 RIPEMD
4-252 available, see section 4
253 private, domain name (see below)
254 private, OID (see below)
255 reserved
Codes 253 and 254 indicate that a private, proprietary, local, or
experimental hash algorithm is used. For code 253, the hash field
begins with a wire encoded domain name (with compression prohibited)
that indicates the algorithm to use. For code 254, the hash field
begins with a one byte unsigned OID length followed by a BER encoded
OID which indicates the algorithm to use.
The hash size field is an unsigned octet count of the hash field size
less the length of any code 253 or 254 prefix. For some hash
algorithms it may be fixed by the algorithm choice but this will not
always be the case. For example, hash size is used to distinguish
between RIPEMD-128 (16 octets) and RIPEMD-160 (20 octets). If the
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT Indirect KEY RRs
hash algorithm field is 0, the hash size MUST be zero and no hash
octets are present.
The hash field itself is variable size with its length specified by
the hash size field and any code 253 or 254 prefix.
3. Performance Considerations
With current public key technology, an indirect key will sometimes be
shorter than the keying material it points at. In addition, there
can be cases where a single indirect KEY RR points to multiple keys
elsewhere. This may improve DNS performance in the retrieval of the
initial KEY RR. However, an additional retrieval step then needs to
be done to get the actually keying material which must be added to
the overall time to get the public key.
4. IANA Considerations
IETF consensus, standards action, and similar terms in this section
are as define in [RFC 2434].
KEY RR algorithm number 252 was already reserved for indirect keys in
RFC 2535.
An IETF standards action is required to allocate target type codes
hex x0000, x0006 through x00FF, x0200 through x0FFF, and xFFFF.
Codes in the range x1000 through x7FFF can be allocated by an IETF
consensus. Codes x8000 through xFEFF are available on a first come
first serve basis. Codes xFF00 through xFFFE are available for
experimentation or private local use without allocation. Use of
codes in this block may result in conflicts outside such experiment
or locality.
An IETF consensus is required to allocate an indirect KEY RR hash
algorithm code in the range 4-252 and a standards action is required
to allocate hash algorithm code 255. Codes 253 and 254 should cover
requirements for local, private, or proprietary algorithms.
5. Security Considerations
The indirecting step of using an indirect KEY RR adds complexity and
additional steps where security could go wrong. If the indirect key
RR was retrieved from a zone that was insecure for the resolver, you
have no security. If the indirect key RR, although secure itself,
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT Indirect KEY RRs
point to a key which can not be securely retrieved and is not
validateted by a secure hash in the indirect key RR, you have no
security.
References
RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities",
STD 13, November 1987.
RFC 1035 - P. Mockapetris, "Domain Names - Implementation and
Specifications", STD 13, November 1987.
RFC 1321 - R. Rivest, "The MD5 Message-Digest Algorithm", April 1992.
RFC 1738 - T. Berners-Lee, L. Masinter & M. McCahill, "Uniform
Resource Locators (URL)", December 1994.
RFC 2119 - "Key words for use in RFCs to Indicate Requirement
Levels", S. Bradner. March 1997.
RFC 2181 - R. Elz, R. Bush, "Clarifications to the DNS
Specification", July 1997.
RFC 2434 - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", October 1998.
RFC 2437 - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography
Specifications Version 2.0", October 1998.
RFC 2535 - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
RFC 2538 - D. Eastlake, O. Gudmundsson, "Storing Certificates in the
Domain Name System (DNS)", March 1999.
Author's Address
Donald E. Eastlake 3rd
IBM
65 shindegan Hill Road, RR #1
Carmel, NY 10512 USA
Telephone: +1-914-784-7913 (w)
+1-914-276-2668 (h)
FAX: +1-914-784-3833 (w)
EMail: dee3@us.ibm.com
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT Indirect KEY RRs
Expiration and File Name
This draft expires October 1999.
Its file name is draft-ietf-dnsind-indirect-key-00.txt.
D. Eastlake 3rd [Page 8]

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

@@ -0,0 +1,440 @@
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

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

@@ -0,0 +1,648 @@
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]

278
doc/draft/draft-ietf-dnsind-simple-secure-update-00.txt Normal file
View File

@@ -0,0 +1,278 @@
DNSIND Working Group Brian Wellington (TISLabs)
INTERNET-DRAFT April 1999
<draft-ietf-dnsind-simple-secure-update-00.txt>
MAY Updates: RFC 2535, RFC 2136, [TSIG]
MAY Replaces: RFC 2137, [update2]
Simple Secure Domain Name System (DNS) Dynamic Update
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 draft proposes an alternative method for performing secure
Domain Name System (DNS) dynamic updates. The method described here
is both simple and flexible enough to represent any policy decisions.
Secure communication based on request/transaction signatures [TSIG]
is used to provide authentication and authorization.
Expires October 1999 [Page 1]
INTERNET-DRAFT Simple Secure Dynamic Update April 1999
1 - Introduction
Dynamic update operations for the Domain Name System are defined in
[RFC2136], but no mechanisms for security have been defined. Request
and transaction signatures are defined in [TSIG].
Familiarity with the DNS system [RFC1034, RFC1035] as well as the
proposals mentioned above is assumed. Familiarity with DNS Security
[RFC2535] is assumed in section (4).
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 DNS Transaction Security
[TSIG] provides a means for two processes that share a secret key to
authenticate DNS requests and responses sent between them. This is done
by appending TSIG digital signature (keyed hash) RRs to those messages.
Keyed hashes are simple to calculate and verify, and do not require
caching of data.
2 - Authentication
TSIG records are attached to all secure dynamic update messages. This
allows the server to verifiably determine the originator of the message.
It can then use this information in the decision of whether to accept
the update. DNSSEC SIG records may be included in an update message,
but MAY NOT be used for authentication purposes in the update protocol.
If a message fails the authentication test due to an unauthorized key,
the failure is indicated with the REFUSED rcode. Other TSIG or dynamic
update errors are returned unchanged.
Expires October 1999 [Page 2]
INTERNET-DRAFT Simple Secure Dynamic Update April 1999
3 - Policy
All policy is dictated by the server and is configurable by the zone
administrator. The server's policy defines criteria which determine if
the key used to sign the update is permitted to update the records
requested. By default, a key cannot make any changes to the zone; the
key's scope must be explicitly enabled. There are several reasons that
this process is implemented in the server and not the protocol (as in
[RFC2137, update2], where the signatory bits of KEY records may define
the policy).
3.1 - Flexibility
Storing policy in the signatory fields of DNS keys is overly
restrictive. Only a fixed number of bits are present, which means that
only a fixed number of policy decisions are representable. There are
many decisions that do not fit into the framework imposed by the
signatory field; a zone administrator cannot effectively impose a policy
not implemented in the draft defining the field.
There may be any number of policies applied in the process of
authorization, and there are no restrictions on the scope of these
policies. Implementation of the policies is beyond the scope of this
document.
3.2 - Simplicity
Policy decisions in the server could be used as an adjunct to policy
fields in the KEY records. This could lead to confusion if the policies
are inconsistent. Furthermore, since there is no need to expose
policies, a central configuration point is more logical.
3.3 - Extendibility
If a policy is changed, there are no changes made to the DNS protocol or
the data on the wire. This means that new policies can be defined at
any point without adverse effects or interoperability concerns.
Expires October 1999 [Page 3]
INTERNET-DRAFT Simple Secure Dynamic Update April 1999
4 - Interaction with DNSSEC
A successful update request may or may not include SIG records for each
RRset. Since SIG records are not used for authentication in this
protocol, they are not required. If the updated zone is signed, the
server will generate SIG records for each incoming RRset with the Zone
key (which MUST be online). If there are any non-DNSSEC SIG records
present, they are retained. If there are SIG records that have been
generated by the appropriate zone KEY, these SIGs are verified and
retained if the verification is successful. DNSSEC SIG records
generated by other KEYs are dropped. The server will generate SIG
records for each set with the Zone key, unless one has already been
verified. The server will also generate a new SOA record and possibly
new NXT records, and sign these with the Zone key.
The server MUST update the SOA record and MAY generate new NXT records
when an update is received. Unlike traditional dynamic update, the
client is forbidden from updating SOA 1 NXT records.
5 - Security considerations
For a secure zone to support dynamic update, the Zone key MUST be online
(unlike [RFC2137]). No additional protection is offered by having the
Zone key offline and an Update key online, since compromising any key
that can sign the zone's data compromises the zone itself.
6 - 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.
[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.
[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC
2137, CyberCash, April 1997.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC
2065, 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.
Expires October 1999 [Page 4]
INTERNET-DRAFT Simple Secure Dynamic Update April 1999
[update2] D. Eastlake ``Secure Domain Name System (DNS) Dynamic
Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite
Systems Company, August 1998.
7 - Author's Address
Brian Wellington
TISLabs at Network Associates
3060 Washington Road, Route 97
Glenwood, MD 21738
+1 443 259 2369
<bwelling@tislabs.com>
Expires October 1999 [Page 5]

742
doc/draft/draft-ietf-dnssec-tkey-01.txt → doc/draft/draft-ietf-dnsind-tkey-00.txt
View File

File diff suppressed because it is too large Load Diff