upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-06-04 22:12:05 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

resurrect dead files for Andreas

Browse source
This commit is contained in:
Michael Graff 2000-05-24 17:41:12 +00:00
parent 19d1b1667d
commit 599c6d44f4
32 changed files with 20793 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

905
doc/expired/draft-duerst-dns-i18n-02.txt Normal file
View file

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

336
doc/expired/draft-dunlap-dns-duxfr-00.txt Normal file
View file

@ -0,0 +1,336 @@
DNSIND Working Group K. Dunlap
INTERNET-DRAFT Check Point Software
<draft-dunlap-dns-duxfr-00.txt> P. Vixie
ISC
September 1999
Dynamic Update Zone Transfer
Copyright (C) The Internet Society (1999). All Rights Reserved.
Status of This Memo
This draft, file name draft-dunlap-dns-duxfr-00.txt, is intended to
become a Proposed Standard RFC. Distribution of this document is unlim-
ited. Comments should be sent to <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 docu-
ments 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 not appropriate 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
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This document proposes an alternative extension to the DNS protocol for
Incremental zone transfer (IXFR) [RFC1995]. This extension uses the
mechanisms for adding and deleting Resource Records specified in
[RFC2136] to transmit the changes between authoritative servers of a
zone.
Expires March 2000 [Page 1]
INTERNET-DRAFT DNS DUXFR September 1999
1 - Introduction
For rapid propagation of changes to a DNS database [STD13], it is neces-
sary to reduce latency by actively notifying servers of the change.
This is accomplished by the DNS NOTIFY Mechanism [RFC1996].
The simple method described for Incremental transfer (IXFR), in
[RFC1995], does not adequately address the complexity of the problem.
Dynamic Update Zone Transfer (DUXFR), as proposed, is a mechanism to
transmit the complexity of changes in the zone and still have the effi-
ciency of IXFR means to propagate changed portions of a zone.
In this document, a slave name server which requests DUXFR is called a
DUXFR client and a master or slave name server which responds to the
request is called a DUXFR server.
2 - Brief Description of the Protocol
If a DUXFR client, which likely has an older version of a zone, thinks
it needs a newer version of the zone (typically through SOA refresh
timeout or the NOTIFY mechanism), it sends a DUXFR message containing
the SOA serial number of its (presumably outdated) copy of the zone.
A DUXFR server should keep record of the newest version of the zone and
the differences between that copy and several older versions. When a
DUXFR request with an older version number is received, the DUXFR server
needs to send only the differences required to make that version
current. These differences are sent using the DNS UPDATE format packets
for deletes and add specified in [RFC2136 2.5].
When a zone has been updated, it should be saved in stable storage
before the new version is used to respond to DUXFR (or AXFR) queries.
Otherwise, if the server crashes, data which is no longer available may
have been distributed to slave servers, which can cause persistent data-
base inconsistencies.
If a DUXFR query with the same or newer version number than that of the
server is received, it is replied to with a single SOA record of the
server's current version, just as in IXFR.
The Transport protocol for DUXFR queries is TCP/IP.
Expires March 2000 [Page 2]
INTERNET-DRAFT DNS DUXFR September 1999
3 - Query Format
The DUXFR Query format is based on the standard DNS UPDATE Message For-
mat. In the DNS Packet Header the Opcode is set to UPDATE and the Zone
Type (ZTYPE) being set to AXFR. The Additional section containing the
SOA record of the client's version of the zone.
4 - Response Format
The response packets to the DUXFR query are in the standard DNS UPDATE
Message Format. The records in the Update Section are formatted using
the four sets of semantics for adding and deleting Resource Records
specified in the ``Update Section'' in [RFC2136 2.5]. The client will
process these changes using the prerequisite for the transaction as the
existence of the SOA serial number specified in the Additional section
of the DUXFR query.
The response to a DUXFR query, when the server no longer has all the
previous history from the version the client requests, will be a
Response code (RCODE) of "Refused". It is recommended that the client
retry with an AXFR query described in [RFC1034 4.3.5].
It is recommended that the Prerequisite sections of the DNS message be
empty on transmission and ignored on reception. The Additional section
may contain necessary data such as signatures as specified by other
extensions to [RFC 2136].
5 - Version Overhead
A DUXFR server can not be required to hold all previous versions forever
and may delete them anytime. In general, there is a trade-off between
the size of storage space and the possibility of using DUXFR.
Information about older versions should be purged if the total length of
a DUXFR response would be longer than that of an AXFR response. Given
that the purpose of DUXFR is to reduce AXFR overhead, this strategy is
quite reasonable. The strategy assures that the amount of storage
required is at most twice that of the current zone information.
Information older than the SOA expire period may also be purged.
6 - IANA Considerations
No IANA services are required by this document.
Expires March 2000 [Page 3]
INTERNET-DRAFT DNS DUXFR September 1999
7 - Security Considerations
DNS is related to several security problems, no attempt is made to fix
them in this document.
The authors believe that this document does not introduce any additional
security problems to the current DNS protocol.
8 - Examples
Given the following three generations of data with the current serial
number of 3.
Example.Com. IN SOA NS.Example.Com. admin.Example.Com.
(
1 600 600 3600000 604800 )
IN NS NS.Example.Com.
NS.Example.Com. IN A 192.168.1.5
Vangogh.Example.Com. IN A 192.168.1.21
Vangogh.Example.Com. is removed and Monet.Example.Com. is added.
Example.Com. IN SOA NS.Example.Com. admin.Example.Com. (
2 600 600 3600000 604800 )
IN NS NS.Example.Com.
NS.Example.Com. IN A 192.168.1.5
Monet.Example.Com. IN A 192.168.6.27
IN A 192.168.3.128
One of the IP address of Monet.Example.Com. is changed.
Example.Com. IN SOA NS.Example.Com. admin.Example.Com. (
3 600 600 3600000 604800 )
IN NS NS.Example.Com.
NS.Example.Com. IN A 192.168.1.5
Monet.Example.Com. IN A 192.168.6.42
IN A 192.168.3.128
Expires March 2000 [Page 4]
INTERNET-DRAFT DNS DUXFR September 1999
The following DUXFR query:
+--------------------------------------------------+
Header | OPCODE=QUERY, QR=Request |
+--------------------------------------------------+
Zone | QNAME=Example.Com., QCLASS=IN, QTYPE=AXFR |
+--------------------------------------------------+
Prerequisite | <empty> |
+--------------------------------------------------+
Update | <empty> |
+--------------------------------------------------+
Additional | Example.Com. IN SOA serial=1 |
+--------------------------------------------------+
The reply could be with the following DUXFR response with Update packets
in the Answer Section:
+--------------------------------------------------+
Header | OPCODE=QUERY, QR=Response |
+--------------------------------------------------+
Zone | QNAME=Example.Com., QCLASS=IN, QTYPE=AXFR |
+--------------------------------------------------+
Prerequisite | Example.Com. IN SOA serial=1 |
+--------------------------------------------------+
Update | Vangogh.Example.Com. 0 ANY A 192.168.1.21 |
| Monet.Example.Com. IN A 192.168.6.42 |
| Monet.Example.Com. IN A 192.168.3.128 |
| Example.Com. 0 IN SOA serial=1 |
| Example.Com. IN SOA serial=2 |
| Monet.Example.Com. 0 ANY A 192.168.6.42 |
| Example.Com. 0 ANY SOA serial=2 |
| Example.Com. IN SOA serial=3 |
+--------------------------------------------------+
Additional | <empty> |
+--------------------------------------------------+
or with the following Compressed DUXFR response with Update packets in
the Answer Section:
Expires March 2000 [Page 5]
INTERNET-DRAFT DNS DUXFR September 1999
+--------------------------------------------------+
Header | OPCODE=QUERY, QR=Response |
+--------------------------------------------------+
Zone | QNAME=Example.Com., QCLASS=IN, QTYPE=AXFR |
+--------------------------------------------------+
Prerequisite | Example.Com. IN SOA serial=1 |
+--------------------------------------------------+
Update | Vangogh.Example.Com. 0 ANY A 192.168.1.21 |
| Monet.Example.Com. IN A 192.168.6.42 |
| Monet.Example.Com. IN A 192.168.3.128 |
| Example.Com. 0 ANY SOA serial=1 |
| Example.Com. IN SOA serial=3 |
+--------------------------------------------------+
Additional | <empty> |
+--------------------------------------------------+
References
[RFC1034]]
P. Mockapetris, ``Domain Names - Concepts and Facilities'' STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[RFC1035]
P. Mockapetris, ``Domain Names - Implementation and Specifica-
tion'' RFC 1035, USC/Information Sciences Institute, November
1987.
[RFC1996]
P. Vixie, ``A Mechanism for Prompt Notification of Zone Changes
(DNS Notify)'' RFC 1996, August 1996
[RFC1995]
M. Ohta, ``Incremental Zone Transfer in DNS'' RFC 1995, August
1996.
[RFC2026]
S. Bradner, ``the Internet Standards Process -- Revision 3'' RFC
2026, Harvard University, October 1996.
[RFC2136]
P. Vixie, S. Thomson, Y. Rekhter and J. Bound, ``Dynamic
Updates in the Domain Name System (DNS UPDATE)'' RFC 2136,
April 1997
Expires March 2000 [Page 6]
INTERNET-DRAFT DNS DUXFR September 1999
Author's Address
Kevin J. Dunlap
Check Point Software Technologies, Inc.
The Meta IP Group
119 South Main Street, Suite 200
Seattle, WA 98033
+1 206 674 3700
<kevind@MetaIP.CheckPoint.Com>
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063
+1 650 779 7001
<vixie@isc.org>
Expires March 2000 [Page 7]
INTERNET-DRAFT DNS DUXFR September 1999
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 implementation may be prepared, copied,
published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by
removing
the copyright notice or references to the Internet Society or
other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other
than
English.
The limited permissions granted above are perpetual and will not
be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Expires March 2000 [Page 8]

337
doc/expired/draft-ietf-dnsind-binary-labels-05.txt Normal file
View file

@ -0,0 +1,337 @@
DNSIND Working Group Matt Crawford
Internet Draft Fermilab
May 5, 1999
Binary Labels in the Domain Name System
<draft-ietf-dnsind-binary-labels-05.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Introduction and Terminology
This document defines a ``Bit-String Label'' which may appear within
domain names. This new label type compactly represents a sequence
of ``One-Bit Labels'' and enables resource records to be stored at
any bit-boundary in a binary-named section of the domain name tree.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KWORD].
2. Motivation
Binary labels are intended to efficiently solve the problem of
storing data and delegating authority on arbitrary boundaries when
the structure of underlying name space is most naturally represented
in binary.
Expires November 10, 1999 Crawford [Page 1]
Internet Draft Binary DNS Labels May 5, 1999
3. Label Format
Up to 256 One-Bit Labels can be grouped into a single Bit-String
Label. Within a Bit-String Label the most significant or "highest
level" bit appears first. This is unlike the ordering of DNS labels
themselves, which has the least significant or "lowest level" label
first. Nonetheless, this ordering seems to be the most natural and
efficient for representing binary labels.
Among consecutive Bit-String Labels, the bits in the first-appearing
label are less significant or "at a lower level" than the bits in
subsequent Bit-String Labels, just as ASCII labels are ordered.
3.1. Encoding
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+
|0 1| ELT | Count | Label ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+
(Each tic mark represents one bit.)
ELT 000001 binary, the six-bit extended label type [EDNS0]
assigned to the Bit-String Label.
Count The number of significant bits in the Label field. A
Count value of zero indicates that 256 bits are
significant. (Thus the null label representing the DNS
root cannot be represented as a Bit String Label.)
Label The bit string representing a sequence of One-Bit Labels,
with the most significant bit first. That is, the One-Bit
Label in position 17 in the diagram above represents a
subdomain of the domain represented by the One-Bit Label
in position 16, and so on.
The Label field is padded on the right with zero to seven
pad bits to make the entire field occupy an integral
number of octets. These pad bits MUST be zero on
transmission and ignored on reception.
A sequence of bits may be split into two or more Bit-String Labels,
but the division points have no significance and need not be
preserved. An excessively clever server implementation might split
Expires November 10, 1999 Crawford [Page 2]
Internet Draft Binary DNS Labels May 5, 1999
Bit-String Labels so as to maximize the effectiveness of message
compression [DNSIS]. A simpler server might divide Bit-String
Labels at zone boundaries, if any zone boundaries happen to fall
between One-Bit Labels.
3.2. Textual Representation
A Bit-String Label is represented in text -- in a zone file, for
example -- as a <bit-spec> surrounded by the delimiters "\[" and
"]". The <bit-spec> is either a dotted quad or a base indicator and
a sequence of digits appropriate to that base, optionally followed
by a slash and a length. The base indicators are "b", "o" and "x",
denoting base 2, 8 and 16 respectively. The length counts the
significant bits and MUST be between 1 and 32, inclusive, after a
dotted quad, or between 1 and 256, inclusive, after one of the other
forms. If the length is omitted, the implicit length is 32 for a
dotted quad or 1, 3 or 4 times the number of binary, octal or
hexadecimal digits supplied, respectively, for the other forms.
In augmented Backus-Naur form [ABNF],
bit-string-label = "\[" bit-spec "]"
bit-spec = bit-data [ "/" length ]
/ dotted-quad [ "/" slength ]
bit-data = "x" 1*64HEXDIG
/ "o" 1*86OCTDIG
/ "b" 1*256BIT
dotted-quad = decbyte "." decbyte "." decbyte "." decbyte
decbyte = 1*3DIGIT
length = NZDIGIT *2DIGIT
slength = NZDIGIT [ DIGIT ]
OCTDIG = %x30-37
NZDIGIT = %x31-39
If a <length> is present, the number of digits in the <bit-data>
MUST be just sufficient to contain the number of bits specified by
the <length>. If there are insignificant bits in a final
hexadecimal or octal digit, they MUST be zero. A <dotted-quad>
always has all four parts even if the associated <slength> is less
Expires November 10, 1999 Crawford [Page 3]
Internet Draft Binary DNS Labels May 5, 1999
than 24, but, like the other forms, insignificant bits MUST be zero.
Each number represented by a <decbyte> must be between 0 and 255,
inclusive.
The number represented by <length> must be between 1 and 256
inclusive.
The number represented by <slength> must be between 1 and 32
inclusive.
When the textual form of a Bit-String Label is generated by machine,
the length SHOULD be explicit, not implicit.
3.2.1. Examples
The following four textual forms represent the same Bit-String
Label.
\[b11010000011101]
\[o64072/14]
\[xd074/14]
\[208.116.0.0/14]
The following represents two consecutive Bit-String Labels which
denote the same relative point in the DNS tree as any of the above
single Bit-String Labels.
\[b11101].\[o640]
3.3. Canonical Representation and Sort Order
Both the wire form and the text form of binary labels have a degree
of flexibility in their grouping into multiple consecutive Bit-
String Labels. For generating and checking DNS signature records
[DNSSEC] binary labels must be in a predictable form. This
canonical form is defined as the form which has the fewest possible
Bit-String Labels and in which all except possibly the first (least
significant) label in any sequence of consecutive Bit-String Labels
is of maximum length.
For example, the canonical form of any sequence of up to 256 One-Bit
Labels has a single Bit-String Label, and the canonical form of a
sequence of 513 to 768 One-Bit Labels has three Bit-String Labels of
which the second and third contain 256 label bits.
Expires November 10, 1999 Crawford [Page 4]
Internet Draft Binary DNS Labels May 5, 1999
The canonical sort order of domain names [DNSSEC] is extended to
encompass binary labels as follows. Sorting is still label-by-
label, from most to least significant, where a label may now be a
One-Bit Label or a standard (code 00) label. Any One-Bit Label
sorts before any standard label, and a 0 bit sorts before a 1 bit.
The absence of a label sorts before any label, as specified in
[DNSSEC].
For example, the following domain names are correctly sorted.
foo.example
\[b1].foo.example
\[b100].foo.example
\[b101].foo.example
bravo.\[b10].foo.example
alpha.foo.example
4. Processing Rules
A One-Bit Label never matches any other kind of label. In
particular, the DNS labels represented by the single ASCII
characters "0" and "1" do not match One-Bit Labels represented by
the bit values 0 and 1.
5. Discussion
A Count of zero in the wire-form represents a 256-bit sequence, not
to optimize that particular case, but to make it completely
impossible to have a zero-bit label.
6. IANA Considerations
This document defines one Extended Label Type, termed the Bit-String
Label, and requests registration of the code point 000001 binary in
the space defined by [EDNS0].
7. Security Considerations
All security considerations which apply to traditional ASCII DNS
labels apply equally to binary labels. he canonicalization and
sorting rules of section 3.3 allow these to be addressed by DNS
Security [DNSSEC].
Expires November 10, 1999 Crawford [Page 5]
Internet Draft Binary DNS Labels May 5, 1999
8. References
[ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234.
[DNSIS] P.V. Mockapetris, "Domain names - implementation and
specification", RFC 1035.
[DNSSEC]D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security
Extensions", RFC 2065.
[EDNS0] P. Vixie, "Extension mechanisms for DNS (EDNS0)", Currently
draft-dnsind-edns0-01.txt.
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
9. Author's Address
Matt Crawford
Fermilab MS 368
PO Box 500
Batavia, IL 60510
USA
Phone: +1 630 840-3461
EMail: crawdad@fnal.gov
Expires November 10, 1999 Crawford [Page 6]

334
doc/expired/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]

167
doc/expired/draft-ietf-dnsind-dhcp-rr-00.txt Normal file
View file

@ -0,0 +1,167 @@
INTERNET-DRAFT Andreas Gustafsson
draft-ietf-dnsind-dhcp-rr-00.txt Internet Engines, Inc.
October 1999
A DNS RR for encoding DHCP information
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 describes a DNS RR for use by DHCP servers that need to
store state information in the DNS.
Introduction
A set of procedures to allow DHCP servers [RFC2131] to automatically
update the DNS [RFC1034, RFC1035] is proposed in [DHCPDNS].
A situation can arise where multiple DHCP clients request the same
DNS name from their (possibly distinct) DHCP servers. To resolve
such conflicts, [DHCPDNS] proposes storing client identifiers in the
DNS to unambiguously associate domain names with the DHCP clients
"owning" them. Early versions of [DHCPDNS] proposed using TXT
records for encoding this information; the current version specifies
the use of KEY records.
In the interest of clarity, it would be preferable for this DHCP
Expires April 2000 [Page 1]
draft-ietf-dnsind-dhcp-rr-00.txt October 1999
information to use a distinct RR type rather than the existing KEY
type. A separate RR type can also improve efficiency by avoiding the
unnecessary transmission of unrelated KEY records.
This memo defines a distinct RR type for use by DHCP servers, the
"DHCP" RR.
The DHCP RR
The DHCP RR is defined with mnemonic DHCP and type code <TBD>.
DHCP RDATA format
The RDATA section of a DHCP RR in transmission contains RDLENGTH
bytes of binary data. The format of this data and its interpretation
by DHCP servers and clients, including the interpretation of multiple
DHCP RRs at the same domain name, are TBD. [This part of the
specification should be driven by the needs of, and written in
cooperation with, the DHCP Working Group and the authors of
[DHCPDNS]].
DNS software should consider the RDATA section to be opaque. In DNS
master files, the RDATA is represented as a hexadecimal string with
an optional "0x" or "0X" prefix. Periods (".") may be inserted
anywhere after the "0x" for readability. This format is identical to
that of the NSAP RR [RFC1706]. The number of hexadecimal digits MUST
be even.
Example
A DHCP server allocating the IPv4 address 10.0.0.1 to a client
"client.org.nil" might associate eight bytes of housekeeping
information with the client as follows:
client.org.nil. A 10.0.0.1
client.org.nil. DHCP 01.23.45.67.89.ab.cd.ef
Security Considerations
The DHCP record as such does not introduce any new security problems
into the DNS. However, care should be taken not to store sensitive
information in DHCP records, since they are published along with
other DNS data. Note that even the hardware addresses of DHCP
clients may be considered sensitive information.
IANA Considerations
The IANA is requested to allocate an RR type number for the DHCP
Expires April 2000 [Page 2]
draft-ietf-dnsind-dhcp-rr-00.txt October 1999
record type from the regular RR type number range.
References
[RFC1035] - Domain Names - Implementation and Specifications, P.
Mockapetris, November 1987.
[RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
November 1987.
[RFC1706] - DNS NSAP Resource Records, B. Manning, R. Colella,
October 1994.
[RFC2131] - Dynamic Host Configuration Protocol, R. Droms, March
1997.
[DHCPDNS] - draft-ietf-dhc-dhcp-dns-*.txt
Author's Address
Andreas Gustafsson
Internet Engines, Inc.
950 Charter Street
Redwood City, CA 94063
USA
Phone: +1 650 779 6004
Email: gson@iengines.net
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.
Expires April 2000 [Page 3]
draft-ietf-dnsind-dhcp-rr-00.txt October 1999
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Expires April 2000 [Page 4]

502
doc/expired/draft-ietf-dnsind-dname-03.txt Normal file
View file

@ -0,0 +1,502 @@
DNSIND Working Group Matt Crawford
Internet Draft Fermilab
March 21, 1999
Non-Terminal DNS Name Redirection
<draft-ietf-dnsind-dname-03.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."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
1. Introduction
This document defines a new DNS Resource Record called ``DNAME'',
which provides the capability to map an entire subtree of the DNS
name space to another domain. It differs from the CNAME record
which maps a single node of the name space.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KWORD].
2. Motivation
This Resource Record and its processing rules were conceived as a
solution to the problem of maintaining address-to-name mappings in a
context of network renumbering. Without the DNAME mechanism, an
authoritative DNS server for the address-to-name mappings of some
network must be reconfigured when that network is renumbered. With
DNAME, the zone can be constructed so that it needs no modification
when renumbered. DNAME can also be useful in other situations, such
as when an organizational unit is renamed.
Expires September 26, 1999 Crawford [Page 1]
Internet Draft Non-Terminal Nicknames March 21, 1999
3. The DNAME Resource Record
The DNAME RR has mnemonic DNAME and type code 39 (decimal).
DNAME has the following format:
<owner> <ttl> <class> DNAME <target>
The format is not class-sensitive. All fields are required. The
RDATA field <target> is a <domain-name> [DNSIS].
The DNAME RR causes type NS additional section processing.
The effect of the DNAME record is the substitution of the record's
<target> for its <owner> as a suffix of a domain name. A "no-
descendants" limitation governs the use of DNAMEs in a zone file:
If a DNAME RR is present at a node N, there may be other data at
N (except a CNAME or another DNAME), but there MUST be no data
at any descendant of N. This restriction applies only to
records of the same class as the DNAME record.
This rule assures predictable results when a DNAME record is cached
by a server which is not authoritative for the record's zone. It
MUST be enforced when authoritative zone data is loaded. Together
with the rules for DNS zone authority [DNSCLR] it implies that DNAME
and NS records can only coexist at the top of a zone which has only
one node.
The compression scheme of [DNSIS] MUST NOT be applied to the RDATA
portion of a DNAME record unless the sending server has some way of
knowing that the receiver understands the DNAME record format.
Signalling such understanding is expected to be the subject of
future DNS Extensions.
Naming loops can be created with DNAME records or a combination of
DNAME and CNAME records, just as they can with CNAME records alone.
Resolvers, including resolvers embedded in DNS servers, MUST limit
the resources they devote to any query. Implementors should note,
however, that fairly lengthy chains of DNAME records may be valid.
4. Query Processing
To exploit the DNAME mechanism the name resolution algorithms
[DNSCF] must be modified slightly for both servers and resolvers.
Both modified algorithms incorporate the operation of making a
Expires September 26, 1999 Crawford [Page 2]
Internet Draft Non-Terminal Nicknames March 21, 1999
substitution on a name (either QNAME or SNAME) under control of a
DNAME record. This operation will be referred to as "the DNAME
substitution".
4.1. Processing by Servers
For a server performing non-recursive service steps 3.c and 4 of
section 4.3.2 [DNSCF] are changed to check for a DNAME record before
checking for a wildcard ("*") label, and to return certain DNAME
records from zone data and the cache.
DNS clients sending Extended DNS [EDNS0] queries with Version 0 or
non-extended queries are presumed not to understand the semantics of
the DNAME record, so a server which implements this specification,
when answering a non-extended query, SHOULD synthesize a CNAME
record for each DNAME record encountered during query processing to
help the client reach the correct DNS data. The behavior of clients
and servers under Extended DNS versions greater than 0 will be
specified when those versions are defined.
The synthesized CNAME RR, if provided, MUST have
The same CLASS as the QCLASS of the query,
TTL equal to zero,
An <owner> equal to the QNAME in effect at the moment the DNAME
RR was encountered, and
An RDATA field containing the new QNAME formed by the action of
the DNAME substitution.
If the server has the appropriate key on-line [DNSSEC, SECDYN], it
MAY generate and return a SIG RR for the synthesized CNAME RR.
The revised server algorithm is:
1. Set or clear the value of recursion available in the response
depending on whether the name server is willing to provide
recursive service. If recursive service is available and
requested via the RD bit in the query, go to step 5, otherwise
step 2.
2. Search the available zones for the zone which is the nearest
ancestor to QNAME. If such a zone is found, go to step 3,
otherwise step 4.
Expires September 26, 1999 Crawford [Page 3]
Internet Draft Non-Terminal Nicknames March 21, 1999
3. Start matching down, label by label, in the zone. The matching
process can terminate several ways:
a. If the whole of QNAME is matched, we have found the node.
If the data at the node is a CNAME, and QTYPE doesn't match
CNAME, copy the CNAME RR into the answer section of the
response, change QNAME to the canonical name in the CNAME
RR, and go back to step 1.
Otherwise, copy all RRs which match QTYPE into the answer
section and go to step 6.
b. If a match would take us out of the authoritative data, we
have a referral. This happens when we encounter a node with
NS RRs marking cuts along the bottom of a zone.
Copy the NS RRs for the subzone into the authority section
of the reply. Put whatever addresses are available into the
additional section, using glue RRs if the addresses are not
available from authoritative data or the cache. Go to step
4.
c. If at some label, a match is impossible (i.e., the
corresponding label does not exist), look to see whether the
last label matched has a DNAME record.
If a DNAME record exists at that point, copy that record
into the answer section. If substitution of its <target>
for its <owner> in QNAME would overflow the legal size for a
<domain-name>, set RCODE to YXDOMAIN [DNSUPD] and exit;
otherwise perform the substitution and continue. If the
query was not extended [EDNS0] with a Version indicating
understanding of the DNAME record, the server SHOULD
synthesize a CNAME record as described above and include it
in the answer section. Go back to step 1.
If there was no DNAME record, look to see if the "*" label
exists.
If the "*" label does not exist, check whether the name we
are looking for is the original QNAME in the query or a name
we have followed due to a CNAME. If the name is original,
set an authoritative name error in the response and exit.
Otherwise just exit.
If the "*" label does exist, match RRs at that node against
QTYPE. If any match, copy them into the answer section, but
Expires September 26, 1999 Crawford [Page 4]
Internet Draft Non-Terminal Nicknames March 21, 1999
set the owner of the RR to be QNAME, and not the node with
the "*" label. Go to step 6.
4. Start matching down in the cache. If QNAME is found in the
cache, copy all RRs attached to it that match QTYPE into the
answer section. If QNAME is not found in the cache but a DNAME
record is present at an ancestor of QNAME, copy that DNAME
record into the answer section. If there was no delegation from
authoritative data, look for the best one from the cache, and
put it in the authority section. Go to step 6.
5. Use the local resolver or a copy of its algorithm (see resolver
section of this memo) to answer the query. Store the results,
including any intermediate CNAMEs and DNAMEs, in the answer
section of the response.
6. Using local data only, attempt to add other RRs which may be
useful to the additional section of the query. Exit.
Note that there will be at most one ancestor with a DNAME as
described in step 4 unless some zone's data is in violation of the
no-descendants limitation in section 3. An implementation might
take advantage of this limitation by stopping the search of step 3c
or step 4 when a DNAME record is encountered.
4.2. Processing by Resolvers
A resolver or a server providing recursive service must be modified
to treat a DNAME as somewhat analogous to a CNAME. The resolver
algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d
as 4.e and insert a new 4.d. The complete algorithm becomes:
1. See if the answer is in local information, and if so return it
to the client.
2. Find the best servers to ask.
3. Send them queries until one returns a response.
4. Analyze the response, either:
a. if the response answers the question or contains a name
error, cache the data as well as returning it back to the
client.
b. if the response contains a better delegation to other
servers, cache the delegation information, and go to step 2.
Expires September 26, 1999 Crawford [Page 5]
Internet Draft Non-Terminal Nicknames March 21, 1999
c. if the response shows a CNAME and that is not the answer
itself, cache the CNAME, change the SNAME to the canonical
name in the CNAME RR and go to step 1.
d. if the response shows a DNAME and that is not the answer
itself, cache the DNAME. If substitution of the DNAME's
<target> for its <owner> in the SNAME would overflow the
legal size for a <domain-name>, return an implementation-
dependent error to the application; otherwise perform the
substitution and go to step 1.
e. if the response shows a server failure or other bizarre
contents, delete the server from the SLIST and go back to
step 3.
A resolver or recursive server which understands DNAME records but
sends non-extended queries MUST augment step 4.c by deleting from
the reply any CNAME records which have an <owner> which is a
subdomain of the <owner> of any DNAME record in the response.
5. Examples of Use
5.1. Organizational Renaming
If an organization with domain name FROBOZZ.EXAMPLE became part of
an organization with domain name ACME.EXAMPLE, it might ease
transition by placing information such as this in its old zone.
frobozz.example. DNAME frobozz-division.acme.example.
MX 10 mailhub.acme.example.
The response to an extended recursive query for www.frobozz.example
would contain, in the answer section, the DNAME record shown above
and the relevant RRs for www.frobozz-division.acme.example.
5.2. Classless Delegation of Shorter Prefixes
The classless scheme for in-addr.arpa delegation [INADDR] can be
extended to prefixes shorter than 24 bits by use of the DNAME
record. For example, the prefix 192.0.8.0/22 can be delegated by
the following records.
Expires September 26, 1999 Crawford [Page 6]
Internet Draft Non-Terminal Nicknames March 21, 1999
$ORIGIN 0.192.in-addr.arpa.
8/22 NS ns.slash-22-holder.example.
8 DNAME 8.8/22
9 DNAME 9.8/22
10 DNAME 10.8/22
11 DNAME 11.8/22
A typical entry in the resulting reverse zone for some host with
address 192.0.9.33 might be
$ORIGIN 8/22.0.192.in-addr.arpa.
33.9 PTR somehost.slash-22-holder.example.
The same advisory remarks concerning the choice of the "/" character
apply here as in [INADDR].
5.3. Network Renumbering Support
If IPv4 network renumbering were common, maintenance of address
space delegation could be simplified by using DNAME records instead
of NS records to delegate.
$ORIGIN new-style.in-addr.arpa.
189.190 DNAME in-addr.example.net.
$ORIGIN in-addr.example.net.
188 DNAME in-addr.customer.example.
$ORIGIN in-addr.customer.example.
1 PTR www.customer.example.
2 PTR mailhub.customer.example.
; etc ...
This would allow the address space 190.189.0.0/16 assigned to the
ISP "example.net" to be changed without the necessity of altering
the zone files describing the use of that space by the ISP and its
customers.
Renumbering IPv4 networks is currently so arduous a task that
updating the DNS is only a small part of the labor, so this scheme
may have a low value. But it is hoped that in IPv6 the renumbering
task will be quite different and the DNAME mechanism may play a
useful part.
Expires September 26, 1999 Crawford [Page 7]
Internet Draft Non-Terminal Nicknames March 21, 1999
6. IANA Considerations
This document defines a new DNS Resource Record type with the
mnemonic DNAME and type code 39 (decimal). The naming/numbering
space is defined in [DNSIS]. This name and number have already been
registered with the IANA.
7. Security Considerations
The DNAME record is similar to the CNAME record with regard to the
consequences of insertion of a spoofed record into a DNS server or
resolver, differing in that the DNAME's effect covers a whole
subtree of the name space. The facilities of [DNSSEC] are available
to authenticate this record type.
8. References
[DNSCF] P.V. Mockapetris, "Domain names - concepts and facilities",
RFC 1034.
[DNSCLR] R. Elz, R. Bush, "Clarifications to the DNS Specification",
RFC 2181.
[DNSIS] P.V. Mockapetris, "Domain names - implementation and
specification", RFC 1035.
[DNSSEC] D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security
Extensions", RFC 2065.
[DNSUPD] P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System", RFC 2136.
[EDNS0] P. Vixie, "Extensions mechanisms for DNS (EDNS0)", Currently
draft-dnsind-edns0-01.txt.
[INADDR] H. Eidnes, G. de Groot, P. Vixie, "Classless IN-ADDR.ARPA
delegation", RFC 2317.
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
[SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic
Update", RFC 2137.
Expires September 26, 1999 Crawford [Page 8]
Internet Draft Non-Terminal Nicknames March 21, 1999
9. Author's Address
Matt Crawford
Fermilab MS 368
PO Box 500
Batavia, IL 60510
USA
Phone: +1 630 840-3461
EMail: crawdad@fnal.gov
Expires September 26, 1999 Crawford [Page 9]

319
doc/expired/draft-ietf-dnsind-edns0-01.txt Normal file
View file

@ -0,0 +1,319 @@
DNSIND Working Group Paul Vixie
INTERNET-DRAFT ISC
<draft-dnsind-edns0-01.txt> January, 1999
Extension mechanisms for DNS (EDNS0)
Status of this Memo
This document is an Internet-Draft. 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.''
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
The Domain Name System's wire protocol includes a number of fixed
fields whose range has been or soon will be exhausted and does not
allow clients to advertise their capabilities to servers. This
document describes backward compatible mechanisms for allowing the
protocol to grow.
1 - Rationale and Scope
1.1. DNS (see [RFC1035]) specifies a Message Format and within such
messages there are standard formats for encoding options, errors, and
name compression. The maximum allowable size of a DNS Message is fixed.
Many of DNS's protocol limits are too small for uses which are or which
are desired to become common. There is no way for implementations to
advertise their capabilities.
Expires July 1999 [Page 1]
INTERNET-DRAFT EDNS0 January 1999
1.2. Existing clients will not know how to interpret the protocol
extensions detailed here. In practice, these clients will be upgraded
when they have need of a new feature, and only new features will make
use of the extensions. We must however take account of client behaviour
in the face of extra fields, and design a fallback scheme for
interoperability with these clients.
2 - Affected Protocol Elements
2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit
word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of
1-bit flags. The original reserved Z bits have been allocated to
various purposes, and most of the RCODE values are now in use. More
flags and more possible RCODEs are needed.
2.2. The first two bits of a wire format domain label are used to denote
the type of the label. [RFC1035 4.1.4] allocates two of the four
possible types and reserves the other two. Proposals for use of the
remaining types far outnumber those available. More label types are
needed.
2.3. DNS Messages are limited to 512 octets in size when sent over UDP.
While the minimum maximum reassembly buffer size still allows a limit of
512 octets of UDP payload, most of the hosts now connected to the
Internet are able to reassemble larger datagrams. Some mechanism must
be created to allow requestors to advertise larger buffer sizes to
responders.
3 - Extended Label Types
3.1. The ``0 1'' label type will now indicate an extended label type,
whose value is encoded in the lower six bits of the first octet of a
label. All subsequently developed label types should be encoded using
an extended label type.
3.2. The ``1 1 1 1 1 1'' extended label type will be reserved for future
expansion of the extended label type code space.
4 - OPT pseudo-RR
4.1. The OPT pseudo-RR can be added to the additional data section of
either a request or a response. An OPT is called a pseudo-RR because it
pertains to a particular transport level message and not to any actual
DNS data. OPT RRs shall never be cached, forwarded, or stored in or
loaded from master files.
Expires July 1999 [Page 2]
INTERNET-DRAFT EDNS0 January 1999
4.2. An OPT RR has a fixed part and a variable set of options expressed
as {attribute, value} pairs. The fixed part holds some DNS meta data
and also a small collection of new protocol elements which we expect to
be so popular that it would be a waste of wire space to encode them as
{attribute, value} pairs.
4.3. The fixed part of an OPT RR is structured as follows:
Field Name Field Type Description
------------------------------------------------------
NAME domain name empty (root domain)
TYPE u_int16_t OPT
CLASS u_int16_t sender's UDP payload size
TTL u_int32_t extended RCODE and flags
RDLEN u_int16_t describes RDATA
RDATA octet stream {attribute,value} pairs
4.4. The variable part of an OPT RR is encoded in its RDATA and is
structured as zero or more of the following:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | |
/ OPTION-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
OPTION-CODE (Assigned by IANA.)
OPTION-LENGTH Size (in octets) of OPTION-DATA.
OPTION-DATA Varies per OPTION-CODE.
4.5. The sender's UDP buffer size (which OPT stores in the RR CLASS
field) is the number of octets of the largest UDP payload that can be
reassembled and delivered in the sender's network stack. Note that path
MTU, with or without fragmentation, may be smaller than this.
Expires July 1999 [Page 3]
INTERNET-DRAFT EDNS0 January 1999
4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
reassembly buffer. Choosing 1280 on an Ethernet connected requestor
would be reasonable. The consequence of choosing too large a value may
be an ICMP message from an intermediate gateway, or even a silent drop
of the response message. Requestors are advised to retry in such cases.
4.5.2. Both requestors and responders are advised to take account of the
path's already discovered MTU (if known) when considering message sizes.
4.6. The extended RCODE and flags (which OPT stores in the RR TTL field)
are structured as follows:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | EXTENDED-RCODE | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | Z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note that
EXTENDED-RCODE value "0" indicates that an unextended
RCODE is in use (values "0" through "15").
VERSION Indicates the implementation level of whoever sets it.
Full conformance with this specification is indicated by
version ``0.'' Note that both requestors and responders
should set this to the highest level they implement,
that responders should send back RCODE=BADVERS and that
requestors should be prepared to probe using lower
version numbers if they receive an RCODE=BADVERS.
Z Set to zero by senders and ignored by receivers, unless
modified in a subsequent specification.
5 - Transport Considerations
5.1. The presence of an OPT pseudo-RR in a request should be taken as an
indication that the requestor fully implements the given version of
EDNS, and can correctly understand any response that conforms to that
feature's specification.
5.2. Lack of use of these features in a request must be taken as an
indication that the requestor does not implement any part of this
specification and that the responder may make no use of any protocol
Expires July 1999 [Page 4]
INTERNET-DRAFT EDNS0 January 1999
extension described here in its response.
5.3. Responders who do not understand these protocol extensions are
expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL.
Therefore use of extensions should be ``probed'' such that a responder
who isn't known to support them be allowed a retry with no extensions if
it responds with such an RCODE. If a responder's capability level is
cached by a requestor, a new probe should be sent periodically to test
for changes to responder capability.
6 - Security Considerations
Requestor-side specification of the maximum buffer size may open a new
DNS denial of service attack if responders can be made to send messages
which are too large for intermediate gateways to forward, thus leading
to potential ICMP storms between gateways and responders.
7 - IANA Considerations
IANA is hereby requested to assign an RR type code for OPT.
It is the recommendation of this document and its working group that
IANA create a registry for EDNS Extended Label Types, for EDNS Option
Codes, and for EDNS Version Numbers.
This document assigns label type 0b01xxxxxx as "EDNS Extended Label
Type." We request that IANA record this assignment.
This document assigns extended label type 0bxx111111 as "Reserved for
future extended label types." We request that IANA record this
assignment.
This document assigns option code 65535 to "Reserved for future
expansion."
This document expands the RCODE space from 4 bits to 12 bits. This will
allow IANA to assign more than the 16 distinct RCODE values allowed in
[RFC1035].
This document assigns EDNS Extended RCODE "16" to "BADVERS".
IESG approval should be required to create new entries in the EDNS
Extended Label Type or EDNS Version Number registries, while any
published RFC (including Informational, Experimental, or BCP) should be
grounds for allocation of an EDNS Option Code.
Expires July 1999 [Page 5]
INTERNET-DRAFT EDNS0 January 1999
8 - Acknowledgements
Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas
Narten were each instrumental in creating and refining this
specification.
9 - References
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1035, USC/Information Sciences
Institute, November 1987.
10 - Author's Address
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063
+1 650 779 7001
<paul@vix.com>
Expires July 1999 [Page 6]

249
doc/expired/draft-ietf-dnsind-edns1-03.txt Normal file
View file

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

470
doc/expired/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/expired/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

697
doc/expired/draft-ietf-dnsind-kitchen-sink-02.txt Normal file
View file

@ -0,0 +1,697 @@
INTERNET-DRAFT Donald E. Eastlake, 3rd
IBM
Expires March 2000 September 1999
draft-ietf-dnsind-kitchen-sink-02.txt
The Kitchen Sink DNS Resource Record
--- ------- ---- --- -------- ------
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-ietf-dnsind-kitchen-sink-02.txt, is
intended to be become an Experimental RFC. Distribution of this
document is unlimited. Comments should be sent to
<namedroppers@internic.net> or to the author.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
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.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved
Abstract
Periodically people desire to put proprietary, complex, and/or
obscure data into the Domain Name System (DNS). This draft defines a
kitchen sink Resource Record that will satisfy this desire for the
storage of miscellaneous structured information.
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT The Kitchen Sink Resource Record
Acknowledgements
The suggestions or information provided by the following persons have
improved this document and they are gratefully acknowledged:
Rob Austein
Matt Crawford
Johnny Eriksson
Phillip H. Griffin
Michael A. Patton
David Singer
Table of Contents
Status of This Document....................................1
Copyright Notice...........................................1
Abstract...................................................1
Acknowledgements...........................................2
Table of Contents..........................................2
1. Introduction............................................3
2. Kitchen Sink Resource Record............................3
2.1 The Meaning Octet......................................4
2.2 The Coding and Subcoding Octets........................5
2.2.1 ASN.1 Subcodings.....................................7
2.2.2 MIME Subcodings......................................7
2.2.3 Text Subcodings......................................8
3. Master File Representation..............................8
4. Performance Considerations..............................9
5. Security Considerations.................................9
6. IANA Considerations.....................................9
7. Full Copyright Statement................................9
References................................................11
Author's Address..........................................12
Expiration and File Name..................................12
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT The Kitchen Sink Resource Record
1. Introduction
The Domain Name System (DNS) provides a replicated distributed secure
hierarchical database which stores "resource records" (RRs) under
hierarchical domain names. This data is structured into zones which
are independently maintained. [RFC 1034, 1035, 2535]
Numerous types of RRs have been defined. These support such critical
functions as host name to address translation (A, AAAA, etc. RRs),
automatic mail routing (MX etc. RRs), and other functions. In
addition, there are RRs defined related to the zone structure and
administration of the DNS (SOA, NS, and RP RRs), security (SIG, KEY,
and NXT RRs), etc. There is a TXT RR for the inclusion of general
human readable text.
New RRs that are reasonably simple and designed via the open IETF
standards process are periodically added as new needs become
apparent. But there are people who want to put some proprietary,
complex and/or non-standard structured data in the DNS. In the past
they have frequently come up with some way of reinterpreting the TXT
RR, since that is one of the least constrained RRs. This is likely a
bad idea since all previous ways to reinterpreting the TXT RR have
sunk without a trace. (Well, if they actually got an RFC out, it's
still there, but, practically speaking, almost nobody actually uses
it.)
If a new type of data is needed for a global interoperable use in the
DNS, the best course is to design a new RR that meets the need
through the IETF standards process. This draft defines an extremely
general and flexible RR which can be used for other data, such as
proprietary data, where global interoperability is not a
consideration. It includes representations of OSI ASN.1, MIME, XML,
and, recursively, DNS RRs.
2. Kitchen Sink Resource Record
The symbol for the kitchen sink resource record is SINK. Its type
number is 40. This type is defined across all DNS classes.
The RDATA portion of the SINK RR is structured as follows:
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT The Kitchen Sink Resource Record
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| meaning | coding |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| subcoding | /
+--+--+--+--+--+--+--+--+ /
/ data /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The "meaning", "coding", and "subcoding" octets are always present.
The "data" portion is variable length and could be null in some
cases. The size of the "data" portion can always be determined by
subtracting 3 from the SINK resource record RDLENGTH. The coding
octet gives the general structure of the data. The subcoding octet
provides additional information depending on the value of the coding
nibble.
All references to "domain name" in this document mean a domain name
in the DNS CLASS of the SINK RR.
2.1 The Meaning Octet
The meaning octet indicates whether any semantic tagging appears at
the beginning of the data field and the format of such semantic
tagging. This contrasts with the coding and subcoding octets which
merely indicate format. The inclusion of such semantic tagging is
encouraged and it is expected to be the primary means by which
applications determine if a SINK RR is of the variety in which they
have interest.
It is noted that multiple popular uses of SINK could develop that are
not distinguished by using different parts of the DNS name space or
different DNS classes. If this occurs, retrievals may fetch large
sets of SINK RR to be sorted through at the application level.
Should this occur, such popular uses of SINK should obtain and
migrate to their own RR number using normal RR number allocation
procedures. In addition, it would be possible to define an extended
query operation that selects from among SINK RRs based on the
semantic tag.
The types of tags available are chosen to be globally unique and
under the control of some "owner". The owner designates the meaning
associated with the tags they control. Where the tag is a URI, it is
recommended that a retrieval from the URI fetch material that would
be helpful in determining this meaning. No a priori method is
defined for determining the meaning of other tags beside an out of
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT The Kitchen Sink Resource Record
band question to the owner.
INITIAL ASSIGNED MEANING VALUES
0 - reserved.
1 - none.
2 - OID.
3 - domain name.
4 - URI.
5-254 - available for assignment, see section 6.
255 - reserved.
A meaning octet value of 1 indicates that there is no semantic
tagging at the beginning of the data area. The information, whatever
it is, starts at the beginning of the data field and is coded
according to the coding and subcoding octets.
Meaning octet values of 2, 3, or 4, indicate, on the other hand, that
a semantic tag is present. A value of two indicates that a BER
[X.690] encoded OID appears prefixed by a single unsigned octet of
OID length count. A value of three indicates that a DNS domain name
appears in wire format with name compression prohibited. And a value
of four indicates that a null (zero) octet terminated URI appears.
2.2 The Coding and Subcoding Octets
The coding octet gives the major method by which the data in the data
field is encoded. It should always have a meaningful value. The
subcoding octet is intended to give additional coding details.
Although the subcoding octet is always present, it must be
interpreted in the context of the coding octet. For any coding octet
value which does not specify subcoding octet value meanings, the
subcoding octet MUST be ignored and SHOULD be zero.
While not explicitly mentioned below, the data field will actually
start with a semantic tag if indicated by the meaning octet. If such
a semantic tag is present, any data prefix required by the coding or
subcoding octet is placed after the semantic tag and before the data.
CODING OCTET VALUES
0 - reserved.
1 - DNS RRs. The data portion consists of DNS resource records
as they would be transmitted in a DNS response section. The
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT The Kitchen Sink Resource Record
subcoding octet is the number of RRs in the data area as an
unsigned integer. Domain names may be compressed via pointers
as in DNS replies. The origin for the pointers is the beginning
of the RDATA section of the SINK RR. Thus the SINK RR is safe
to cache since only code that knows how to parse the data
portion of a SINK RR need know of and can expand these
compressions.
2 - MIME structured data [RFC 2045, 2046]. The data portion is
a MIME structured message. The "MIME-Version:" header line may
be omitted unless the version is other than "1.0". The top
level Content-Transfer-Encoding may be encoded into the
subcoding octet (see section 2.2.2). Note that, to some extent,
the size limitations of DNS RRs may be overcome in the MIME case
by using the "Content-Type: message/external-body" mechanism.
3 - Text tagged data. The data potion consists of text formated
as specified in the TXT RR except that the first and every
subsequent odd numbered text item is considered to be a tag
labeling the immediately following text item. If there are an
odd number of text items overall, then the last is considered to
label a null text item. Syntax of the tags is as specified in
RFC 2396 for the "Authority Component" without the two leading
slashes ("//") or trailing slash using the DNS for authority.
Thus any organization with a domain name can assign tags without
fear of conflict. The subcodings octet specifies the encoding
of the labeled text items as specified in section 2.2.3.
4 - HTML. The subcoding octet indicates the version of HTML
with the major version number in the upper nibble and the minor
version number in the lower nibble. Thus, for example, HTML 3.2
would be indicated by a 0x32 octet.
5 - XML. The subcoding octet is the version of XML, currently
1.
6 - ASN.1 [X.680, etc.]. See section 2.2.1.
7-251 - Available for assignment, see section 6.
252 - Private coding format indicated by an OID. The format of
the data portion is indicated by an initial BER encoded OID
which is prefixed by a one octet unsigned length count for the
OID. The subcoding octet is available for whatever use the
private formating wishes to make of it.
253 - Private coding format indicated by a domain name. The
format of the data portion is indicated by an initial wire
format domain name with compression prohibited. (Such names are
self delimiting.) The subcoding octet is available for whatever
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT The Kitchen Sink Resource Record
use the private formating wishes to make of it.
254 - Private coding format indicated by a URI. The format of
the data portion is indicated by an initial URI [RFC 2396] which
is terminated by a zero (null) valued octet followed by the data
with that format. The subcoding octet is available for whatever
use the private formating wishes to make of it. The manner in
which the URI specifies the format is not defined but presumably
the retriever will recognize the URI by some pattern match.
255 - reserved.
NOTE: the existence of a DNS RR coding and the infinite possibilities
of ASN.1, XML, and MIME permit one to SINK to even greater depths by
nesting.
2.2.1 ASN.1 Subcodings
For ASN.1 [X.680, etc.] data, a specific concrete encoding must be
chosen as indicated by the subcoding octet.
ASN.* SUBCODINGS
0 - reserved.
1 - BER ( Basic Encoding Rules [X.690] ).
2 - DER ( Distinguished Encoding Rules [X.690] ).
3 - PER ( Packed Encoding Rules ) Aligned [X.691].
4 - PER Unaligned [X.691].
5 - CER ( Canonical Encoding Rules [X.690] ).
6-253 - available for assignment, see section 6.
254 - private. This subcoding will never be assigned to a standard
set of encoding rules. An OID preceded by a one octet unsigned
length of OID appears at the beginning of the data area after
the ASN coding OID.
255 - reserved.
2.2.2 MIME Subcodings
If the coding octet indicates the data is MIME structured, the
precise encoding is given by the subcoding octets as listed below.
MIME SUBCODINGS
0 - reserved, see section 6.
1 - 7bit.
2 - 8bit.
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT The Kitchen Sink Resource Record
3 - binary.
4 - quoted-printable.
5 - base64.
6 - 253 - available for assignment, see section 6.
254 - private. The data portion must start with an "x-" or "X-"
token denoting the private content-transfer-encoding immediately
followed by one null (zero) octet followed by the remainder of
the MIME object.
255 - reserved, see section 6.
2.2.3 Text Subcodings
If the coding octet indicates the data is text, the exact encoding of
the text items is indicated by the subcoding octet as follows:
TEXT SUBCODINGS
0 - reserved, see section 6.
1 - ASCII.
2 - UTF-7 [RFC 1642].
3 - UTF-8 [RFC 2044].
4 - ASCII with MIME header escapes [RFC 2047].
5 - 253 - available for assignment, see section 6.
254 - private. Each text item must start with a domain name [RFC
1034] in wire format without compression denoting the private
text encoding immediately followed by the remainder of the text
item.
255 - reserved, see section 6.
3. Master File Representation
SINK resource records may appear as lines in zone master files. The
meaning, coding, and subcoding appear as unsigned decimal integers.
The data portion can be quite long. It is represented in base 64
[RFC 2045] and may be divided up into any number of white space
separated substrings, down to single base 64 digits, which are
concatenated to obtain the full data. These substrings can span
lines using the standard parenthesis notation. (This type of base64
master file data is also required to support the DNS KEY and SIG
security RRs [RFC 2535].)
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT The Kitchen Sink Resource Record
4. Performance Considerations
Currently DNS is optimized for small data transfers, generally not
exceeding 512 octets including overhead. Larger transfers are less
efficient but do work correctly and efforts are underway to make them
more efficient.
It is easy to create very large RRs or RR sets using SINK. DNS
administrators should think about this and may wish to discourage
large RRs or RR sets. Consideration should also be given to putting
zones from which large RRs or RR sets will be commonly retrieved on
separate hosts which can be tuned for the load this will represent.
5. Security Considerations
Since the SINK resource record can be used to store arbitrary data in
the DNS, this data could have security consequences, particularly if
it is control, executable, macro, or interpretable information or
very large and might cause buffer overflow. Due care should be
taken.
[RFC 2535] covers data original authentication of the data in the
domain name system including SINK RRs.
6. IANA Considerations
Assignment of specific meaning to the values listed herein as
"reserved" requires an IETF standards action.
All other assignments of available meaning, coding, or subcoding
octet values are by IETF consensus.
The many provisions for private indicita specified by separately
allocated OIDs, domain names, or URIs should cover most requirements
for private or proprietary values.
7. 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 implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
D. Eastlake 3rd [Page 9]
INTERNET-DRAFT The Kitchen Sink Resource Record
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.
D. Eastlake 3rd [Page 10]
INTERNET-DRAFT The Kitchen Sink Resource Record
References
[RFC 1034] - P. Mockapetris, "Domain names - concepts and
facilities", 11/01/1987.
[RFC 1035] - P. Mockapetris, "Domain names - implementation and
specification", 11/01/1987.
[RFC 1642] - D. Goldsmith, M. Davis, "UTF-7 - A Mail-Safe
Transformation Format of Unicode", 07/13/1994.
[RFC 2044] - F. Yergeau, "UTF-8, a transformation format of Unicode
and ISO 10646", 10/30/1996.
[RFC 2045] - N. Freed, N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
12/02/1996.
[RFC 2046] - N. Freed, N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", 12/02/1996.
[RFC 2047] - K. Moore, "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
12/02/1996.
[RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", August 1998.
[RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
[X.680] - ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998,
Information Technology - Abstract Syntax Notation One (ASN.1):
Specification of Basic Notation
[X.681] - ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998,
Information Technology - Abstract Syntax Notation One (ASN.1):
Information Object Specification
[X.682] - ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998,
Information Technology - Abstract Syntax Notation One (ASN.1):
Constraint Specification
[X.683] - ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998,
Information Technology - Abstract Syntax Notation One (ASN.1):
Parameterization of ASN.1 Specifications
[X.690] - ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998,
Information Technology - ASN.1 Encoding Rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and
D. Eastlake 3rd [Page 11]
INTERNET-DRAFT The Kitchen Sink Resource Record
Distinguished Encoding Rules (DER)
[X.691] - ITU-T Recommendation X.691 (1997) | ISO/IEC 8825-2:1998,
Information Technology - ASN.1 Encoding Rules: Specification of
Packed Encoding Rules (PER)
Author's Address
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road
Carmel, 10512 USA
Telephone: +1 914-276-2668 (h)
+1 914-784-7913 (w)
FAX: +1 914-784-3833 (w)
EMail: dee3@us.ibm.com
Expiration and File Name
This draft expires March 2000.
Its file name is draft-ietf-dnsind-kitchen-sink-02.txt.
D. Eastlake 3rd [Page 12]

420
doc/expired/draft-ietf-dnsind-local-compression-05.txt Normal file
View file

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

662
doc/expired/draft-ietf-dnsind-local-names-07.txt Normal file
View file

@ -0,0 +1,662 @@
DNS Working Group Donald E. Eastlake, 3rd
INTERNET-DRAFT IBM
Expires December 1999 June 1999
draft-ietf-dnsind-local-names-07.txt
Local Domain Name System (DNS) Names
----- ------ ---- ------ ----- -----
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-ietf-dnsind-local-names-07.txt.
Distribution of this document is unlimited. Comments should be sent
to the DNS mailing list <namedroppers@internic.net> or to the author.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
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
It is increasingly common for their to be "local" domain names which
are not intended to be seen from the global Internet. In some cases
this if for policy reasons, in other cases because they map to IP
addresses or other data which is only locally meaningful [RFC 1918,
2373].
A new top level domain (TLD) name (.local) is reserved and a name
structure suggested below this TLD such that local private DNS zones
can safely be created without fear of conflict if these names should
leak out of a private enclave. It addition, a method of providing
DNS service for these names is suggested such that they are
maintained privately, similar to the reserved private IP addresses,
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT Local DNS Names
yet locally appear to be part of the global DNS name tree and are
reachable by a local resolver with no special knowledge. Additional
second level domain names are assigned under this TLD for IPv6 link
and site local addresses and loopback functions.
Acknowledgments
The valuable contributions of the following persons are gratefully
acknowledged:
Dan Harrington
Michael A. Patton
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT Local DNS Names
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Acknowledgments............................................2
Table of Contents..........................................3
1. Introduction............................................4
2. Local Names Via The .local Top Level Domain.............5
2.1 Local DNS Server Specifics.............................7
2.2 Local in-addr.arpa Zones...............................8
2.3 Name Conflicts.........................................8
2.4 Nested Enclaves........................................9
3. Other Names in .local...................................9
4. Security Considerations.................................9
4.1 Strength of Privacy Offered............................9
4.2 Interaction with DNSSEC...............................10
References................................................11
Author's Address..........................................11
Expiration and File Name..................................11
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT Local DNS Names
1. Introduction
The global Internet Domain Name System (DNS) is documented in [RFC
1034, 1035, 1591, 2606] and numerous additional Requests for Comment.
It defines a tree of names starting with root, ".", immediately below
which are top level domain names such as .com and .us. Below top
level domain names there are normally additional levels of names.
Generally the information in the DNS is public and intended to be
globally accessible. Certainly, in the past, the model of the
Internet was one of end-to-end openness [RFC 1958]. However, with
increasing security threats and concerns, firewalls and enclaves have
appeared. In many cases, organizations have hosts or resources that
they specifically want to reference with DNS names but which they
also want to be walled off from global access and even from global
knowledge of the DNS name for the resource.
In the realm of IP addresses, this has been accomplished by reserving
three blocks of IPv4 addresses as documented in [RFC 1918] and by
allocating parts of the IPv6 address space for link and site local
addresses [RFC 2373]. Familiarity with the contents of these RFCs is
assumed. Addresses in these blocks are not to be globally routed.
In the DNS area, local private names have generally been achieved in
the past by "splitting" DNS at the enclave boundary, giving different
answers to resolvers depending or whether they are inside or outside
of the enclave, using different servers for inside and outside, etc.
as mentioned in [RFC 1918]. Such relatively complex configuration
diddling is at variance with the simple global tree structure of the
initial DNS concept.
This document specifies an alternative approach to achieving the
effect of local names that is more in tune with the concept of a
single global DNS tree or at least the appearance of a single tree.
Use of this approach is not required and older techniques will
continue to work.
[RFC 1918] requires that private IP addresses not be indirectly
exposed to the general Internet via DNS records or otherwise. By
implication, the same would be true of IPv6 local addresses. This
RFC provides the recommended way to accomplish such private IP
address hiding and carves out a limited exception thereto for the
addresses of the servers for some zones which are children of the
.local top level domain name.
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT Local DNS Names
2. Local Names Via The .local Top Level Domain
The fundamental idea, as described in more detail below, is to define
second level domains under .local which are served by DNS name
servers that have private IP addresses. These server's addresses
would only be routed within the domain to which the names are local.
Thus the servers, and the names and resource records inside them,
would not be directly accessible outside the enclave, if the
guidelines in this document are followed.
The following figure shows a highly simplified overview of an example
configuration:
+----------------------------+
| domain/enclave A |
| |
| #====================# |
| H private IP addrs A H |
| H H |
+-----------------------O privhost1 H |
| | H H |
+-----+-----------------O privhost2 H |
| | | H H |
| | | #====================# |
| | a | |
| +--------------------O pubhost3 |
.local | | | | |
+----+ | | +----------------------------+
| | | |
| | | | +----------------------------+
| | | | | domain/enclave B |
(root) | | | | | |
. ----+ | | | | #====================# |
| | | | | H private IP addrs B H |
| | | | | H H |
| +--|--------------------O privhost2 H |
| | | | H H |
+-------+ +-----------------O privhost3 H |
.com | | H : H |
| | #====:===============# |
| | : |
| b +-------------O pubhost4 |
+------+ | |
| +-------------O pubhost5 |
| | |
| +----------------------------+
|
| example
+---------------------O pubhost6
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT Local DNS Names
Starting at the bottom, pubhost6 is intended to illustrate an
ordinary host connected to the Internet with domain name
pubhost6.example.com. Though not indicated in the above diagram,
every DNS zone is in fact served by at least two hosts (and some but
substantially more). The addresses of the servers for the root (.),
.com, and example.com zones would all be in the public portion of the
IP address space, i.e., in the space of all unicast IP addresses not
reserved for private use.
Moving to the top of the figure, enclave A represents some
organization that wishes to have some hosts with publicly visible
names and some with hidden names that are visible only locally.
pubhost3.a.com is an example of a publicly visible host which would
probably have a public IP address although access to pubhost3 from
outside the enclave might be filtered or even blocked by a firewall
or the like. privhost1 and privhost2 are examples of hidden names.
If a zone with privhost1 and privhost2 in it is served by DNS servers
with private IP addresses ("private IP addresses A") such that the
servers are accessible within enclave A but not from outside enclave
A, then the information is that zone will only be locally visible.
As show in the above figure, privhost1 and privhost2 have addresses
that are also private IP addresses, making those hosts inaccessible
outside enclave A, but it is the private addresses of the DNS
servers, not of the hosts pointed to from within the private DNS
zone, that provides the protection for the DNS names and other
private DNS information. (From the above simplified diagram, it
might appear that fully qualified domain names of these hosts would
be privhost1.local and privhost2.local but the names are actually
more complex as explained in Section 2.1.)
Finally, in the middle, another enclave is shown with two hosts with
visible names and public IP addresses, pubhost4.b.com and
pubhost5.b.com. In addition, there are two private host names
privhost2 and privhost3. The duplication of privhost2 between
enclaves A and B would not be a problem as only DNS resolvers in
enclave A can access the DNS servers with the zone having the enclave
A version of privhost2 and only DNS resolvers in enclave B can access
the DNS servers with the zone having the enclave B version of
privhost2.
Publicly visible host names are required by [RFC 1918] to have public
(i.e., globally unique) IP addresses. Private DNS names would
normally have private IP addresses, and all do in the figure above,
but this is not required. A public IP address could be stored under
a private name. And, of course, it is possible for the same physical
host to have multiple IP addresses, including a mix of public and
private. The dotted line in the figure above is intended to indicate
that privhost3 and pubhost4 are actually the same physical machine.
The could be accomplished equally well by storing a single public
address for that host under both the public and private names or by
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT Local DNS Names
having the host answer to both a public IP address stored under the
public name and a private IP address stored under the private name.
In the later case you could even also store the public address along
with the private address under the private name.
2.1 Local DNS Server Specifics
A variety of second level names are provided in the .local zone each
of which is a delegation point to a zone with some number of name
servers in one of the private IP address space blocks. The multiple
second level names permit choice between the different private IP
blocks and different numbers of servers. Thus the actual fully
qualified name for the private host examples in the figure above
would be more like privhost1.a2.local, privhost2.a2.local, etc. (but
see Section 2.3 below).
Glue records are provided to give private IP addresses for initial
name servers; however, it should be noted that the NS and A records
in the local zones will dominate the information stored in the .local
zone. This means that once a resolver has contacted a local server,
the list of NS RRs in the local zone on that server will control and
could contain more or different servers than were given at the chosen
.local delegation point. Nevertheless, the glue A records in the
global .local zone do place some constraints of the private IP
address of the local DNS servers implementing zones which are
children of .local.
It is also possible for an enclave to locally configure its own
version of the .local zone. Depending on its enclave boundary
implementation, it might be able to constrain all of its internal
references to .local to use its own variant version. This version
could have whatever private addresses were desired for the name
servers involved. Such a configuration MAY be used, but it is
recommended that the globally accessible .local specified herein be
used for uniformity. That way, even a unconstrained resolver
starting from the normal root servers (i.e., an "out of the box"
resolver) will correctly resolve or fail to resolve names under
.local depending on the resolvers location in the network as
specified herein.
It is only necessary for the local DNS servers to have private IP
addresses to achieve the effect of local names. However, care MUST
be taken that none of the local DNS servers or any server that might
cache their output is accessible by any network interface that has a
non-private IP address. Otherwise considerable confusion could
result if local names are resolved by a resolver outside a local
enclave to private IP addresses which have a different meaning for
that resolver.
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT Local DNS Names
2.2 Local in-addr.arpa Zones
Inverse lookup of local names corresponding to private IP addresses
needs to be provided via the in-addr.arpa and ip6.int zones. Because
of the fixed naming within this zone, different names with different
numbers of servers or different addresses can not be provided. As
with the forward .local entries, the actual NS RRs in the servers
serving the private portions of the inverse in-addr.arpa will
dominate. When one of these is queried by a resolver, it can provide
information on additional servers for that particular subzone in the
private IP address portion of the in-addr.arpa tree.
2.3 Name Conflicts
The intention is that local names would only be used in the enclave
where the entities they refer to exist, and these names would not be
exported. However, experience indicates that. despite best efforts
to avoid it, some such names will leak out via email cc's, URL's in
HTML, etc. (Such leakage occurs regardless of how the local names
are formed or whether they are accessible via the default root zone.)
These leaked private names can cause confusion if they can conflict
with global names or names local to other enclaves. Use of the
.local top level domain assures no conflict with global names. To
assure no conflict with different local fully qualified names, the
domain name of the enclave SHOULD always be prefixed to .local.
For example, a company might have
host1.company.example
as a globally accessible host and
host2.company.example.b3.local
as a host for internal use only. The global name could normally be
resolvable anywhere on the Internet while the local name could not be
resolved anywhere except within the company enclave.
Note that different names were chosen for the initial label in the
two names above, i.e., host1 and host2. The reason for this is that,
in some environments, local hosts are referred to by an unqualified
names, such as host3. For DNS look up purposes, such a name must be
expanded into a fully qualified domain name and a "search list" of
possible suffix qualifications is tried. If, for example, both
host4.school.ac.example and host4.school.ac.example.b3.local existed,
then a local reference to "host4" would be ambiguous and could lead
to either machine depending on the order of qualifications tried.
This order could even be different in different pieces of local
software or on different local hosts, resulting in substantial
confusion. For this reason, it is strongly recommended that disjoint
name sets be used for global and local entity unqualified domain
names and that fully qualified domain names be used wherever
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT Local DNS Names
practical.
2.4 Nested Enclaves
It is possible to have enclaves within enclaves. In general the best
way to accomplish this is to use a different portion of the private
IP address space at each nesting level of enclave. (Private IP
address space can be reused in enclaves that are siblings or the
like.) Then similar entries to those proposed here for .local can be
made in the private zone referring to name servers with addresses in
the nested enclave's private IP address space.
3. Other Names in .local
Three additional second level domain names are assigned in the .local
top level domain for other types of local names.
In particular,
link.local and
site.local
are reserved for use in qualifying IPv6 link local names and site
local names.
In addition, loopback.local is assigned and given the loopback
address.
4. Security Considerations
This section discusses the strength of the privacy offered by using
subzones of .local and interactions with DNS security.
4.1 Strength of Privacy Offered
Local names, as proposed herein, are not intended to be a strong
security mechanism.
The privacy of the DNS information protected by storing it in servers
with private IP addresses is weak. It is completely dependent on the
integrity of enclave perimeter routing to make these servers
inaccessible. And it may occasionally leak out in any case due to
inclusion in email address fields, web pages, and the like, although
such leakage should be no worse than current split DNS
D. Eastlake 3rd [Page 9]
INTERNET-DRAFT Local DNS Names
implementations of DNS data hiding.
Software should not depend on local names being accessible only
within a particular enclave as someone could deliberately create the
same names within a different enclave. This is true even if, as
recommended herein, the names incorporate the domain name of the
original enclave in an attempt to avoid such conflicts.
4.2 Interaction with DNSSEC
Although an enclave may derive some amount of security by virtue of
its isolation, it will normally be desirable to implement DNS
security [RFC 2535] within the enclave. The enclave owner should
generate their own keys and sign their subzone of .local. However, a
signed copy of their public key can not be included in the .local
zone as it is different for every enclave. Thus, to authenticate the
.local subzone contents, it will be necessary to sign the KEY RR at
the apex of the local subzone of .local with the .local zone key or
another key that is trusted by local resolvers or staticly configure
the public key for the .local subzone in local resolvers.
D. Eastlake 3rd [Page 10]
INTERNET-DRAFT Local DNS Names
References
RFC 1033 - M. Lottor, "Domain Administrators Operations Guide",
November 1987.
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 1591 - J. Postel, "Domain Name System Structure and Delegation",
03/03/1994.
RFC 1918 - Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E.
Lear, "Address Allocation for Private Internets", 02/29/1996.
RFC 1958 - B. Carpenter, "Architectural Principles of the Internet",
06/06/1996.
RFC 2373 - R. Hinden, S. Deering, "IP Version 6 Addressing
Architecture", July 1998
RFC 2535 - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
RFC 2606 - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
June 1999.
Author's Address
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road, RR #1
Carmel, NY 10512 USA
Telephone: +1 914-276-2668 (h)
+1 914-784-7913 (w)
FAX: +1 914-784-3833 (w)
EMail: dee3@us.ibm.com
Expiration and File Name
This draft expires December 1999.
Its file name is draft-ietf-dnsind-local-names-07.txt.
D. Eastlake 3rd [Page 11]
D. Eastlake 3rd [Page 12]

560
doc/expired/draft-ietf-dnsind-rfc2052bis-02.txt Normal file
View file

@ -0,0 +1,560 @@
Applications Area Arnt Gulbrandsen
INTERNET-DRAFT Troll Technologies
<draft-ietf-dnsind-rfc2052bis-02.txt> Paul Vixie
Obsoletes: RFC 2052 Internet Software Consortium
January 1999
A DNS RR for specifying the location of services (DNS SRV)
Status of this Memo
This document is an Internet-Draft. 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."
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
This document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain (like a more general
form of MX).
Overview and rationale
Currently, one must either know the exact address of a server to
contact it, or broadcast a question. This has led to, for example,
ftp.whatever.com aliases [RFC 2219], the SMTP-specific MX RR, and
using MAC-level broadcasts to locate servers.
The SRV RR allows administrators to use several servers for a single
domain, to move services from host to host with little fuss, and to
designate some hosts as primary servers for a service and others as
backups.
Clients ask for a specific service/protocol for a specific domain
(the word domain is used here in the strict RFC 1034 sense), and get
back the names of any available servers.
Gulbrandsen and Vixie Proposed [Page 1]
RFC 2052bis DNS SRV RR January 1999
Note that where this document refers to "address records", it means A
RR's, AAAA RR's, or their most modern equivalent.
Introductory example
If a SRV-cognizant web-browser wants to retrieve
http://www.example.com/
it does a lookup of
_http._tcp.www.example.com
and retrieves the document from one of the servers in the reply. The
example zone file near the end of this memo contains answering RRs
for this query.
Definitions
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY"
used in this document are to be interpreted as specified in BCP 14.
Other terms used in this document are defined in the DNS
specification, RFC 1034.
The format of the SRV RR
Here is the format of the SRV RR, whose DNS type code is 33:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
(There is an example near the end of this document.)
Service
The symbolic name of the desired service, as defined in Assigned
Numbers [STD 2] or locally. An underscore (_) is prepended to
the service identifier to avoid collisions with DNS labels that
occur in nature.
Some widely used services, notably POP, don't have a single
universal name. If Assigned Numbers names the service
indicated, that name is the only name which is legal for SRV
lookups. Only locally defined services may be named locally.
The Service is case insensitive.
Proto
The symbolic name of the desired protocol, with an underscore
(_) prepended to prevent collisions with DNS labels that occur
Gulbrandsen and Vixie Proposed [Page 2]
RFC 2052bis DNS SRV RR January 1999
in nature. _TCP and _UDP are at present the most useful values
for this field, though any name defined by Assigned Numbers or
locally may be used (as for Service). The Proto is case
insensitive.
Name
The domain this RR refers to. The SRV RR is unique in that the
name one searches for is not this name; the example near the end
shows this clearly.
TTL
Standard DNS meaning [RFC 1035].
Class
Standard DNS meaning [RFC 1035]. SRV records occur in the IN
Class.
Priority
As for MX, the priority of this target host. A client MUST
attempt to contact the target host with the lowest-numbered
priority it can reach; target hosts with the same priority
SHOULD be tried in an order defined by the weight field. The
range is 0-65535. This is a 16 bit binary integer in network
byte order.
Weight
A load balancing mechanism. When selecting a target host among
the those that have the same priority, the chance of trying this
one first SHOULD be proportional to its weight, as specified
below. Larger weights lead to a higher probability of being
selected. The range of this number is 0-65535. This is a 16
bit binary integer in network byte order. Domain administrators
are urged to use Weight 0 when there isn't any load balancing to
do, to make the RR easier to read for humans (less noisy). In
the presence records containing weights greater than 0, records
with weight 0 have a very small chance of being selected.
To choose the target, the client SHOULD implement the effect of
this algorithm. This permits administrators to plan weights to
achieve the load distribution desired. Each time a target is
needed, the client should order the remaining (not previously
used) SRV RRs at the current priority in any random fashion,
except placing all those with weight 0 at the beginning of the
list. Compute the sum of the weights of those RRs, and with
each RR associate the running sum in the selected order. Then
choose a random number (not necessarily of integral value)
between 0 and the sum computed (inclusive), and select the RR
whose running sum value is the first in the selected order which
Gulbrandsen and Vixie Proposed [Page 3]
RFC 2052bis DNS SRV RR January 1999
is greater than or equal to the random number selected.
Port
The port on this target host of this service. The range is
0-65535. This is a 16 bit binary integer in network byte order.
This is often as specified in Assigned Numbers but need not be.
Target
As for MX, the domain name of the target host. There MUST be
one or more address records for this name, the name MUST NOT be
an alias (in the sense of RFC 1034 or RFC 2181). Implementors
are urged, but not required, to return the address record(s) in
the Additional Data section. Unless and until permitted by
future standards action, name compression is not to be used for
this field.
A Target of "." means that the service is decidedly not
available at this domain.
Applicability Statement
In general, it is expected that SRV records will be used by clients
for applications where the relevant protocol specification indicates
that clients should use the SRV record. The examples in this
document use familiar protocols as an aid in understanding. It is
not intended that those protocols will necessarily use SRV records.
Domain administrator advice
Expecting everyone to update their client applications when the first
internet site adds a SRV RR for some server is futile (even if
desirable). Therefore SRV would have to coexist with address record
lookups for existing protocols, and DNS administrators should try to
provide address records to support old clients:
- Where the services for a single domain are spread over several
hosts, it seems advisable to have a list of address records at
the same DNS node as the SRV RR, listing reasonable (if perhaps
suboptimal) fallback hosts for Telnet, NNTP and other protocols
likely to be used with this name. Note that some programs only
try the first address they get back from e.g. gethostbyname(),
and we don't know how widespread this behavior is.
- Where one service is provided by several hosts, one can either
provide address records for all the hosts (in which case the
round-robin mechanism, where available, will share the load
equally) or just for one (presumably the fastest).
Gulbrandsen and Vixie Proposed [Page 4]
RFC 2052bis DNS SRV RR January 1999
- If a host is intended to provide a service only when the main
server(s) is/are down, it probably shouldn't be listed in
address records.
- Hosts that are referenced by backup address records must use the
port number specified in Assigned Numbers for the service.
- Designers of future protocols for which "secondary servers" is
not useful (or meaningful) may choose to not use SRV's support
for secondary servers. Clients for such protocols may use or
ignore SRV RRs with Priority higher than the RR with the lowest
Priority for a domain.
Currently there's a practical limit of 512 bytes for DNS replies.
Until all resolvers can handle larger responses, domain
administrators are strongly advised to keep their SRV replies below
512 bytes.
All round numbers, wrote Dr. Johnson, are false, and these numbers
are very round: A reply packet has a 30-byte overhead plus the name
of the service ("_telnet._tcp.example.com" for instance); each SRV RR
adds 20 bytes plus the name of the target host; each NS RR in the NS
section is 15 bytes plus the name of the name server host; and
finally each A RR in the additional data section is 20 bytes or so,
and there are A's for each SRV and NS RR mentioned in the answer.
This size estimate is extremely crude, but shouldn't underestimate
the actual answer size by much. If an answer may be close to the
limit, using a DNS query tool (e.g. "dig") to look at the actual
answer is a good idea.
The "Weight" field
Weight, the load balancing field, is not quite satisfactory, but the
actual load on typical servers changes much too quickly to be kept
around in DNS caches. It seems to the authors that offering
administrators a way to say "this machine is three times as fast as
that one" is the best that can practically be done.
The only way the authors can see of getting a "better" load figure is
asking a separate server when the client selects a server and
contacts it. For short-lived services like SMTP an extra step in the
connection establishment seems too expensive, and for long-lived
services like telnet, the load figure may well be thrown off a minute
after the connection is established when someone else starts or
finishes a heavy job.
Gulbrandsen and Vixie Proposed [Page 5]
RFC 2052bis DNS SRV RR January 1999
The Port number
Currently, the translation from service name to port number happens
at the client, often using a file such as /etc/services.
Moving this information to the DNS makes it less necessary to update
these files on every single computer of the net every time a new
service is added, and makes it possible to move standard services out
of the "root-only" port range on unix.
Usage rules
A SRV-cognizant client SHOULD use this procedure to locate a list of
servers and connect to the preferred one:
Do a lookup for QNAME=_service._protocol.target, QCLASS=IN,
QTYPE=SRV.
If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV
RR which specifies the requested Service and Protocol in the
reply:
If there is precisely one SRV RR, and its Target is "."
(the root domain), abort.
Else, for all such RR's, build a list of (Priority, Weight,
Target) tuples
Sort the list by priority (lowest number first)
Create a new empty list
For each distinct priority level
While there are still elements left at this priority
level
Select an element randomly, with probability
Weight, as specified above, and move it to the
tail of the new list
For each element in the new list
query the DNS for address records for the Target or
use any such records found in the Additional Data
section of the earlier SRV response.
for each address record found, try to connect to the
(protocol, address, service).
Gulbrandsen and Vixie Proposed [Page 6]
RFC 2052bis DNS SRV RR January 1999
else if the service desired is SMTP (and SMTP has been defined
elsewhere to expect SRV lookups)
skip to RFC 974 (MX).
else
Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
for each address record found, try to connect to the
(protocol, address, service)
Notes:
- Port numbers SHOULD NOT be used in place of the symbolic service
or protocol names (for the same reason why variant names cannot
be allowed: Applications would have to do two or more lookups).
- If a truncated response comes back from an SRV query, the rules
described in [RFC2181] shall apply.
- A client MAY use means other than Weight to choose among target
hosts with equal Priority.
- A client MUST parse all of the RR's in the reply.
- If the Additional Data section doesn't contain address records
for all the SRV RR's and the client may want to connect to the
target host(s) involved, the client MUST look up the address
record(s). (This happens quite often when the address record
has shorter TTL than the SRV or NS RR's.)
- Future protocols could be designed to use SRV RR lookups as the
means by which clients locate their servers.
Fictional example
This is (part of) the zone file for example.com, a still-unused
domain:
$ORIGIN example.com.
@ SOA server.example.com. root.example.com. (
1995032001 3600 3600 604800 86400 )
NS server.example.com.
NS ns1.ip-provider.net.
NS ns2.ip-provider.net.
Gulbrandsen and Vixie Proposed [Page 7]
RFC 2052bis DNS SRV RR January 1999
_ftp._tcp SRV 0 0 21 server.example.com.
_finger._tcp SRV 0 0 79 server.example.com.
; telnet - use old-slow-box or new-fast-box if either is
; available, make three quarters of the logins go to
; new-fast-box.
_telnet._tcp SRV 0 1 23 old-slow-box.example.com.
SRV 0 3 23 new-fast-box.example.com.
; if neither old-slow-box or new-fast-box is up, switch to
; using the sysdmin's box and the server
SRV 1 0 23 sysadmins-box.example.com.
SRV 1 0 23 server.example.com.
; HTTP - server is the main server, new-fast-box is the backup
; (On new-fast-box, the HTTP daemon runs on port 8000)
_http._tcp SRV 0 0 80 server.example.com.
SRV 10 0 8000 new-fast-box.example.com.
; since we want to support both http://example.com/ and
; http://www.example.com/ we need the next two RRs as well
_http._tcp.www SRV 0 0 80 server.example.com.
SRV 10 0 8000 new-fast-box.example.com.
; SMTP - mail goes to the server, and to the IP provider if
; the net is down
_smtp._tcp SRV 0 0 25 server.example.com.
SRV 1 0 25 mailhost.ip-provider.net.
@ MX 0 server.example.com.
MX 1 mailhost.ip-provider.net.
; NNTP - use the IP provider's NNTP server
_nntp._tcp SRV 0 0 119 nntphost.ip-provider.net.
; IDB is an locally defined protocol
_idb._tcp SRV 0 0 2025 new-fast-box.example.com.
; addresses
server A 172.30.79.10
old-slow-box A 172.30.79.11
sysadmins-box A 172.30.79.12
new-fast-box A 172.30.79.13
; backup address records - new-fast-box and old-slow-box are
; included, naturally, and server is too, but might go
; if the load got too bad
@ A 172.30.79.10
A 172.30.79.11
A 172.30.79.13
; backup address record for www.example.com
www A 172.30.79.10
; NO other services are supported
*._tcp SRV 0 0 0 .
*._udp SRV 0 0 0 .
In this example, a telnet connection to "example.com." needs an SRV
lookup of "_telnet._tcp.example.com." and possibly A lookups of "new-
Gulbrandsen and Vixie Proposed [Page 8]
RFC 2052bis DNS SRV RR January 1999
fast-box.example.com." and/or the other hosts named. The size of the
SRV reply is approximately 365 bytes:
30 bytes general overhead
20 bytes for the query string, "_telnet._tcp.example.com."
130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
fast-box", "old-slow-box", "server" and "sysadmins-box" -
"example.com" in the query section is quoted here and doesn't
need to be counted again.
75 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server",
"ns1.ip-provider.net." and "ns2" - again, "ip-provider.net." is
quoted and only needs to be counted once.
120 bytes for the 6 address records (assuming IPv4 only) mentioned
by the SRV and NS RR's.
IANA Considerations
The IANA has assigned RR type value 33 to the SRV RR. No other IANA
services are required by this document.
Changes from RFC 2052
This document obsoletes RFC 2052. The major change from that
previous, experimental, version of this specification is that now the
protocol and service labels are prepended with an underscore, to
lower the probability of an accidental clash with a similar name used
for unrelated purposes. Aside from that, changes are only intended
to increase the clarity and completeness of the document.
Security Considerations
The authors believes this RR to not cause any new security problems.
Some problems become more visible, though.
- The ability to specify ports on a fine-grained basis obviously
changes how a router can filter packets. It becomes impossible
to block internal clients from accessing specific external
services, slightly harder to block internal users from running
unauthorized services, and more important for the router
operations and DNS operations personnel to cooperate.
- There is no way a site can keep its hosts from being referenced
as servers (as, indeed, some sites become unwilling secondary
MXes today). This could lead to denial of service.
- With SRV, DNS spoofers can supply false port numbers, as well as
Gulbrandsen and Vixie Proposed [Page 9]
RFC 2052bis DNS SRV RR January 1999
host names and addresses. Because this vunerability exists
already, with names and addresses, this is not a new
vunerability, merely a slightly extended one, with little
practical effect.
References
STD 2: Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700,
October 1994 (as currently updated by the IANA).
RFC 1034: Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
RFC 1035: Mockapetris, P., "Domain names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
RFC 974: Partridge, C., "Mail routing and the domain system", RFC
974, January 1986.
BCP 14: Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC 2181: Elz, R., Bush, R., "Clarifications to the DNS
Specification", RFC 2181, July 1997
RFC 2219: Hamilton, M., Wright, R., "Use of DNS Aliases for Network
Services", BCP 17, RFC 2219, October 1997
Acknowledgements
The algorithm used to select from the weighted SRV RRs of equal
priority is adapted from one supplied by Dan Bernstein.
Authors' Addresses
Arnt Gulbrandsen Paul Vixie
Troll Tech Internet Software Consortium
Postboks 6133 Etterstad 950 Charter Street
N-0602 Oslo, Norway Redwood City, CA 94063
+47 22646966 +1 650 779 7001
<agulbra@troll.no> <paul@vix.com>
Gulbrandsen and Vixie Proposed [Page 10]

648
doc/expired/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]

663
doc/expired/draft-ietf-dnsind-sec-rr-00.txt Normal file
View file

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

164
doc/expired/draft-ietf-dnsind-sigalgopt-00.txt Normal file
View file

@ -0,0 +1,164 @@
Network Working Group R. Austein
draft-ietf-dnsind-sigalgopt-00.txt On Sabbatical
P. Vixie
Internet Software Consortium
October 1999
DNS SIGALGOPT
Status of this document
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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>
Distribution of this document is unlimited. Please send comments to
the namedroppers@internic.net mailing list.
Abstract
This document describes a mechanism for conserving packet space in a
DNS response message in the presence of multiple DNSSEC signature
algorithms.
Motivation and Scope
DNSSEC [DNSSEC] specifies a general framework for attaching
cryptographic signatures to DNS resource records. The framework
includes provisions for multiple signature protocols, possibly even
on a per-name basis. While this open-ended framework is good and
useful, it poses a problem when multiple signature protocols are in
use and DNS message sizes are limited by the underlying UDP transport
packet size. EDNS0 [EDNS0] provides a way to specify a larger
Austein & Vixie Expires 18 April 2000 [Page 1]
draft-ietf-dnsind-sigalgopt-00.txt October 1999
payload size, but this still does not entirely solve the problem for
large RRsets. Worse, in cases where multiple signature algorithms
generate a response packet so large that it must be truncated, the
signatures that fit into the truncated response will be useless if
the resolver doesn't know how to verify signatures generated with
that algorithm.
This note proposes a way for a resolver to indicate which signature
algorithms it understands to a name server in the form of an ordered
list. When this mechanism is in use, the name server can conserve
packet space by (a) not sending signatures with algorithms that the
resolver will not understand, and (b) not sending multiple signatures
for the same resource records.
Mechanism
[DNSSEC] SIG RRs include a one-octet code indicating the algorithm
associated with a particular signature. The SIGALGOPT option defined
below allows the resolver to specify an ordered list of signature
algorithms using the same one-octet codes that DNSSEC uses.
SIGALGOPT is encoded n the variable RDATA part of the OPT pseudo-RR
in the DNS request (see [EDNS0]).
The OPTION-CODE for SIGALGOPT is [TBD].
The OPTION-DATA for SIGALGOPT is an ordered list of the one-octet
codes used by DNSSEC.
If the SIGALGOPT option in a query specifies multiple signature
algorithms and signatures using more than one of those algorithms are
available in the zone, the server must respond with the signatures
corresponding to the first algorithm on the SIGALGOPT list that
matches, omitting any signatures corresponding to the remaining
algorithms.
We have deliberately not provided a mechanism to return all the
matching signatures, because the purpose of the SIGALGOPT mechanism
is to minimize packet size. If the resolver wants to see all
available signatures, it should just leave off the SIGALGOPT option
entirely.
Security Considerations
Good question. What horrible things could a bad guy do by
creating/altering/deleting SIGALGOPT? Are any of the possible
attacks more interesting than denial of service?
Austein & Vixie Expires 18 April 2000 [Page 2]
draft-ietf-dnsind-sigalgopt-00.txt October 1999
IANA Considerations
SIGALGOPT will need an option code.
The signature algorithm codes themselves are borrowed from DNSSEC and
do not create any new issues for IANA.
References
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and
facilities", RFC 1034, November 1987.
[DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation
and specification", RFC 1035, November 1987.
[EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999.
Author's addresses:
Rob Austein
On Sabbatical
sra@hactrn.net
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063
+1 650 779 7001
vixie@isc.org
Austein & Vixie Expires 18 April 2000 [Page 3]

290
doc/expired/draft-ietf-dnsind-test-tlds-13.txt Normal file
View file

@ -0,0 +1,290 @@
INTERNET-DRAFT Reserved TLDs
February 1999
Expires August 1999
Reserved Top Level DNS Names
-------- --- ----- --- -----
Donald E. Eastlake 3rd
Aliza R. Panitz
Status of This Document
This draft is file name draft-ietf-dnsind-test-tlds-13.txt.
Distribution of this document is unlimited. Comments should be sent
to the DNS 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.''
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).
D. Eastlake, A. Panitz [Page 1]
INTERNET-DRAFT Reserved TLDs
Abstract
To reduce the likelihood of conflict and confusion, a few top level
domain names are reserved for use in private testing, as examples in
documentation, and the like. In addition, a few second level domain
names reserved for use as examples are documented.
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Table of Contents..........................................2
1. Introduction............................................3
2. TLDs for Testing, & Documentation Examples..............3
3. Reserved Example Second Level Domain Names..............4
4. IANA Considerations.....................................4
5. Security Considerations.................................4
References.................................................5
Authors Addresses..........................................5
Expiration and File Name...................................5
D. Eastlake, A. Panitz [Page 2]
INTERNET-DRAFT Reserved TLDs
1. Introduction
The global Internet Domain Name System is documented in [RFC 1034,
1035, 1591] and numerous additional Requests for Comment. It defines
a tree of names starting with root, ".", immediately below which are
top level domain names such as ".com" and ".us". Below top level
domain names there are normally additional levels of names.
2. TLDs for Testing, & Documentation Examples
There is a need for top level domain (TLD) names that can be used for
creating names which, without fear of conflicts with current or
future actual TLD names in the global DNS, can be used for private
testing of existing DNS related code, examples in documentation, DNS
related experimentation, invalid DNS names, or other similar uses.
For example, without guidance, a site might set up some local
additional unused top level domains for testing of its local DNS code
and configuration. Later, these TLDs might come into actual use on
the global Internet. As a result, local attempts to reference the
real data in these zones could be thwarted by the local test
versions. Or test or example code might be written that accesses a
TLD that is in use with the thought that the test code would only be
run in a restricted testbed net or the example never actually run.
Later, the test code could escape from the testbed or the example be
actually coded and run on the Internet. Depending on the nature of
the test or example, it might be best for it to be referencing a TLD
permanently reserved for such purposes.
To safely satisfy these needs, four domain names are reserved as
listed and described below.
.test
.example
.invalid
.localhost
".test" is recommended for use in testing of current or new DNS
related code.
".example" is recommended for use in documentation or as
examples.
".invalid" is intended for use in online construction of domain
names that are sure to be invalid and which it is obvious at a glance
are invalid.
The ".localhost" TLD has traditionally been statically defined
D. Eastlake, A. Panitz [Page 3]
INTERNET-DRAFT Reserved TLDs
in host DNS implementations as having an A record pointing to the
loop back IP address and is reserved for such use. Any other use
would conflict with widely deployed code which assumes this use.
3. Reserved Example Second Level Domain Names
The Internet Assigned Numbers Authority (IANA) also currently has the
following second level domain names reserved which can be used as
examples.
example.com
example.net
example.org
4. IANA Considerations
IANA has agreed to the four top level domain name reservations
specified in this document and will reserve them for the uses
indicated.
5. Security Considerations
Confusion and conflict can be caused by the use of a current or
future top level domain name in experimentation or testing, as an
example in documentation, to indicate invalid names, or as a synonym
for the loop back address. Test and experimental software can escape
and end up being run against the global operational DNS. Even
examples used "only" in documentation can end up being coded and
released or cause conflicts due to later real use and the possible
acquisition of intellectual property rights in such "example" names.
The reservation of several top level domain names for these purposes
will minimize such confusion and conflict.
D. Eastlake, A. Panitz [Page 4]
INTERNET-DRAFT Reserved TLDs
References
RFC 1034 - P. Mockapetris, "Domain names - concepts and facilities",
11/01/1987.
RFC 1035 - P. Mockapetris, "Domain names - implementation and
specification", 11/01/1987.
RFC 1591 - J. Postel, "Domain Name System Structure and Delegation",
03/03/1994.
Authors Addresses
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road, RR #1
Carmel, NY 10512
Telephone: +1 914-276-1668(h)
+1 914-784-7913(w)
FAX: +1 914-784-3833(3)
email: dee3@us.ibm.com
Aliza R. Panitz
500 Stamford Dr. No. 310
Newark, DE 19711 USA
Telephone: +1 302-738-1554
email: buglady@fuschia.net
Expiration and File Name
This draft expires August 1999.
Its file name is draft-ietf-dnsind-test-tlds-13.txt.
D. Eastlake, A. Panitz [Page 5]

158
doc/expired/draft-ietf-dnsind-verify-00.txt Normal file
View file

@ -0,0 +1,158 @@
INTERNET-DRAFT Mark Andrews (ISC)
<draft-ietf-dnsind-verify-00.txt> February 1999
Verifying Resource Records Without Knowing Their Contents
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
This document is an Internet-Draft. 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
DNSSEC [RFC2065] provides a mechanism to cryptographically verify a
DNS resource record provided we can get it into canonical form.
The problem is how do we do this without knowing the contents of all
resource record types?
This document provides one possible solution to this problem.
1 - Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Expires August 1999 [Page 1]
INTERNET-DRAFT draft-ietf-dnsind-verify-00.txt February 1998
2 - Method
In order to be able to canonicalise a resource record a resolver needs
to know where in the data domain names exist so that the resolver can
decompress the domain names and convert the uppercase ASCII in ordinary
labels to lowercase prior to the data being feed into the encryption
routines.
This document propose that all new resource record types defined MUST
have a header at the start of the data section locating where the domain
names are in the data section. A new resource record for the purpose of
this document is any type NOT referenced in section 3 Old Types. Meta
queries such as MAILA (254), MAILB (253), AXFR (252) and IXFR (251) are
not covered by this document as they do not return data of this type.
This table would be a series of unsigned 16 bit words in network order.
The first word contains the length of the table as 16 bit words not
counting the first word. Subsequent words contain the offset from the
start of the data to the start of relevent domain name in the data
assuming all domain names are uncompressed. Offsets in the table are in
the same order as domain names in the data.
3 Old Types
The following types are deemed old and are NOT covered by this document.
A (1), NS (2), MD (3), MF (4), CNAME (5), SOA (6), MB (7), MG (8), MR
(9), NULL (10), WKS (11), PTR (12), HINFO (13), MINFO (14), MX (15), TXT
(16), RP (17), AFSDB (18), X25 (19), ISDN (20), RT (21), NSAP (22),
NSAP-PTR (23), SIG (24), KEY (25), PX (26), GPOS (27), AAAA (28), LOC
(29), NXT (30), EID (31), NIMLOC (32), SRV (33), ATMA (34), NAPTR (35),
KX (36), CERT (37), A6 (38), DNAME (39), UINFO (100), UID (101), GID
(102), UNSPEC (103), OPT (XXX), TKEY (249) and TSIG (250).
4 Security Considerations
It is believed that this document does not introduce any significant
additional security threats other that those that already exist when
using data from the DNS but rather enhances security by allowing new
resource record types to be checked by security aware resolvers.
5 IANA Considerations
This document places no requirements apon IANA.
Expires August 1999 [Page 2]
INTERNET-DRAFT draft-ietf-dnsind-verify-00.txt February 1998
References
[RFC2065]
Eastlake, D. 3rd. and Kaufman, C,. "Domain Name System Security
Extensions," RFC 2065, January 1997
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Lev­
els," BCP 14, RFC 2119, March 1997
Author's Address
Mark Andrews
Internet Software Consortium
1 Seymour St.
Dundas Valley
NSW 2117
AUSTRALIA
+61 2 9871 4742
<Mark_Andrews@isc.org>
Expires August 1999 [Page 3]

618
doc/expired/draft-ietf-dnssec-ar-00.txt Normal file
View file

@ -0,0 +1,618 @@
Domain Name System Security Working Group R. Watson
INTERNET DRAFT November 1997
<draft-ietf-dnssec-ar-00.txt> Expires in six months
DNSsec Authentication Referral Record (AR)
Status of this Document
This document is an Internet-Draft. 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."
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 (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
Authentication Referrals allow DNS to refer to authentication
mechanisms that supplement or replace the KEY RRs of DNSsec.
Five Authentication Service types are defined: DNSsec, Kerberos IV,
Kerberos V, Network Information Service (NIS+), and Radius.
Watson [Page 1]
Internet DRAFT DNSsec Authentication Referral November 1997
1. Introduction
Domain Name System Security [DNSSEC] extends the Domain Name System
(DNS) [RFC1034, RFC1035] to provide for data origin authentication,
public key distribution, and query and transaction authentication,
all based on public key cryptography and public key based digital
signatures. In many organizations, it is desirable to provide a
centralized source for authentication data, especially in
environments where multiple systems are used (for example, KerberosIV
and NIS+). Systems have been defined for distributing user
information in the DNS name-space [HESIOD], but DNS has traditionally
lacked the security necessary to safely distribute sensitive
authentication information. Authentication Referrals use DNSsec's
authenticated data capabilities to distribute mappings from entities
to authentication mechanisms.
1.1 Keywords Used
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
1.2 Definition of Terms
Service Desiring Authentication (SDA): A service requiring a user to
authenticate before providing access. For example, the login program
on a UNIX host is an SDA.
Authentication Service: A type of authentication system that allows
an SDA to verify the identity of a Client communicating with the SDA.
Services are typically accessed using an Authentication Server such
as a KerberosIV or Radius server. In a referral, both the type of
authentication service and the server address are provided.
Client: An entity that wishes to connect to a service, in particular,
to an SDA. Clients are identified using a unique DNS Fully Qualified
Domain Name (FQDN), which contains records providing information on
verifying authentication. Authentication Client may refer to both
humans and hosts in this document.
Authentication Username: In the event that an Authentication Service
is used, the Username may differ from the Client's FQDN in DNS.
Authentication Realm: Some distributed authentication systems allow
for multiple "realms" in which authentication takes place. Realms
typically represent a set of identities and services over which a
single authority is responsible for authentication. Where
appropriate, referrals contain the name of the realm against which
Watson [Page 2]
Internet DRAFT DNSsec Authentication Referral November 1997
they should be made.
Authentication Server: Many authentication systems rely on a
centralized database, which may be found on the Authentication
Server. This database can be identified using the DNS FQDN for the
host. It is assumed that the Authentication Service type will
provide all other information necessary to communicate with the
Authentication Server.
1.3 Authentication in DNSsec
DNSsec provides a mechanism for the authentication of entities it
describes via KEY records containing public keys. This is adequate
for IP Security [IPSEC] and other key-based protocols (such as Secure
Shell [SSH]), but it is not useful for individual user
authentication. Typically such an authentication process involves
the encryption of data using the Client's public key (extracted from
DNSsec), which must then be decrypted by the Client and returned in
some other form (often encrypted with the SDA's public key to protect
both the challenge and the response). Users may be reluctant to
replace their traditional alpha-numeric password with 514-bit private
keys and then perform computation-intensive key manipulation and
signature-operations in their heads. While devices are available
that perform this function in a more accessible manner, they are not
yet mainstream, and a standard has not yet been proposed for
interaction between these devices and DNSsec-based authentication
systems.
Existing distributed authentication systems commonly rely on a
password (shared secret) or a variable challenge-response mechanism
using a system-specific protocol. For example, both KerberosIV
[KERBEROSIV] and Radius [RADIUS] use protocols employing different
packet formats and privacy mechanisms. Because DNS was designed as a
publicly accessible distributed database, no mechanism for the
distribution of private data is provided, which makes the inclusion
of password data in the system both difficult and inappropriate.
The AR resource record (RR type TBD) allows DNSsec to refer an SDA to
an Authentication Service when direct authentication based on the KEY
RR cannot be used.
2. Authentication Referral Resource Record Format
To provide storage for authentication referral information, a new RR
type is defined with the mnemonic AR. More than one AR RR MAY exist
in an RRset; the RRset MUST contain the complete list of
authentication mechanisms allowed for the DNS name.
Watson [Page 3]
Internet DRAFT DNSsec Authentication Referral November 1997
2.1 Record Format
NAME The domain name of the entity to be authenticated.
TYPE AR (TBD)
CLASS IN (HS may also be appropriate)
TTL (as appropriate)
RdLen (variable)
RDATA
Field Name Data Type Notes
------------------------ ----------- -------------------------
Authentication Server dname FQDN of the server that
will provide
authentication data
Authentication Realm dname Realm in which
authentication occurs
Authentication Service 16-bit int Authentication Service
Type as defined in 2.3
Username Length 16-bit int Length of Authentication
Username string in octets
Authentication Username 8-bit int[] UTF-8 encoded name whose
use is defined by the
service type.
Other Data undefined Ignore any following
RDATA
All integer values are stored in network byte order. The
Authentication Username field is an octet stream of length Username
Length.
Meaning of Authentication Realm, Authentication Server,
Authentication Username are specific to each Authentication Service
type.
2.2 Text Representation
A simple text representation for the AR RR might be:
NAME. IN AR [Server] [Realm] [AuthMnemonic] [Username]
2.3 Authentication Service Types
Different Authentication Services types will be assigned numeric
value. New services MUST be registered with IANA.* A mnemonic is
associated with each type to simplify textual representation.
Watson [Page 4]
Internet DRAFT DNSsec Authentication Referral November 1997
Value Mnemonic Authentication Service Name
------ ----------- ---------------------------
0 DNSSEC DNSsec
1 KERBEROS_V4 Kerberos IV
2 KERBEROS_V5 Kerberos V
3 RADIUS Radius
4 NISPLUS NIS+
* A method for registration will be described in detail in a later
version of this document.
2.3.1 DNSsec Referral
It may be desirable to refer authentication to another FQDN. For
example, an organization may have several user zones defined, but one
Client may exist in several of them. Rather than requiring separate
AR RRs, authentication may be forwarded to one canonical AR RR
containing other useful data, or to a record with a KEY RR. Some
fields defined across the AR record are not used:
Field Name Value
------------------------ ----------------------------------
Authentication Server (empty)
Authentication Realm (empty)
Authentication Service 0 (DNSSEC)
Username Length (as appropriate)
Authentication Username FQDN of the entity referred to
When using DNSsec referrals, it is important to avoid referral loops.
The appropriate interpretation order of coexisting KEY and AR records
is discussed in section 3. Referrals may point to either another AR
record or a record with authentication KEYs. If a DNSsec referral
record points to a non-existent name or no authentication information
is available at that name, the authentication MUST fail.
2.3.1.1 DNSsec Referral Example
NAME ROBERT.USER.WATSON.ORG.
TYPE AR (TBD)
CLASS IN
TTL 3600
RdLen (as appropriate)
Watson [Page 5]
Internet DRAFT DNSsec Authentication Referral November 1997
RDATA
Field Name Value
------------------------ ----------------------------------
Authentication Server (empty)
Authentication Realm (empty)
Authentication Service 0 (DNSSEC)
Username Length 19
Authentication Username rnw.andrew.cmu.edu.
A textual representation of this record in zone USER.WATSON.ORG would
appears as:
ROBERT IN AR (. . DNSSEC "rnw.andrew.cmu.edu.")
2.3.2 Kerberos IV Referral
The Authentication Username is a "principal.instance" pair where
instance may be alphanumeric, null, or the wildcard "*". For
authentication against user robert in realm WATSON.ORG, an
appropriate Authentication Username would be "robert.", indicating
that no instance is to be used. To require authentication against
another instance, the form "robert.admin" is appropriate. In some
circumstances, a wild-card Username entry might be used, "robert.*",
indicating that the Client MAY be prompted for a specific instance.
Field Name Value
----------------------- --------------------------------------
Authentication Server Kerberos IV Server
Authentication Realm Kerberos IV Realm
Authentication Service 1 (Kerberos IV)
Username Length (length of Username in octets)
Authentication Username Kerberos IV principal.instance
2.3.2.1 Kerberos IV Referral Example
NAME ROBERT.USER.WATSON.ORG.
TYPE AR (TBD)
CLASS IN
TTL 3600
RdLen (as appropriate)
Watson [Page 6]
Internet DRAFT DNSsec Authentication Referral November 1997
RDATA
Field Name Value
----------------------- ----------------------
Authentication Server KERBEROS.WATSON.ORG.
Authentication Realm WATSON.ORG.
Authentication Service 1 (KERBEROS_V4)
Username Length 12
Authentication Username robert.admin
A textual representation of this record in zone USER.WATSON.ORG would
appear as:
ROBERT IN AR (KERBEROS.WATSON.ORG. WATSON.ORG.
KERBEROS_V4 "robert.admin")
2.3.3. Kerberos V Referral
The specifics of this type will be specified in a future draft. It
is expected that Kerberos V referrals will be almost identical to
Kerberos IV, but with the "." principal/instance separator replaced
with a "/".
2.3.4 Radius Referral
Field Name Value
----------------------- ---------------------------------
Authentication Server Radius Server
Authentication Realm (empty)
Authentication Service 3 (RADIUS)
Username Length (as appropriate)
Authentication Username Radius Username
2.3.4.1 Radius Referral Example
NAME ROBERT.USER.WATSON.ORG.
TYPE AR (TBD)
CLASS IN
TTL 3600
RdLen (as appropriate)
Watson [Page 7]
Internet DRAFT DNSsec Authentication Referral November 1997
RDATA
Field Name Value
----------------------- ----------------------
Authentication Server RADIUS.WATSON.ORG.
Authentication Realm (empty)
Authentication Service 5 (RADIUS)
Username Length 6
Authentication Username robert
A textual representation of this record in zone USER.WATSON.ORG would
appear as:
ROBERT IN AR (RADIUS.WATSON.ORG. .
RADIUS "robert")
2.3.5 NIS+ Referral
NIS+ referral will be documented in a separate document. Due to the
complex interactions between NIS and DNS, there are additional
concerns that must be addressed in greater detail than is appropriate
here.
2.4 DNS Server Handling of the AR Resource Record
When returning an AR RR as part of an RRset, a DNS server MAY include
Additional Records [RFC1034: Section 3.7] that it anticipates the SDA
requires.
3. AR Resource Record Evaluation
When performing a lookup on a Client's DNS entry, a signed RRset is
returned containing KEY RRs, SIG RRs, other data, and possibly an AR
RR. If KEY RRs are present and are permitted for use in user
authentication, public/private key authentication may take place.
Alternatively, the SDA may choose a different authentication
mechanism from the list of AR RRs.
3.1 Authentication Rules
Multiple AR RRs of different Authentication Service types may exist.
Similarly, multiple RRs of the same type may exist in an RRset. When
multiple RRs are returned, the SDA must select some subset of these
to try. A combination of local policy and and the desire for load
balancing determines the correct use of these RRs.
Where multiple AR RRs of different Authentication Service type exist,
one of the available Services SHOULD be selected. This choice could
Watson [Page 8]
Internet DRAFT DNSsec Authentication Referral November 1997
be made by local site policy (i.e., only to accept authentication by
Kerberos, or to not allow AR referral to another DNSsec name), or
with Client interaction (the user is prompted for the mechanism they
wish to authenticate against). If one Authentication Service fails,
the choice to retry against the same service or against different
Services should be made in accordance with local security policy.
Where multiple RRs with the same Authentication Service Type exist
but different Authentication Realm or Username are present, the SDA
should make a choice in accordance with local site policy. For
example, a site might choose only to accept authentication to their
own Kerberos realm.
Load balancing is desirable in the event that multiple RRs with the
same Authentication Realm, Authentication Service, and Username are
present. Such sets of related AR RRs may be considered to be
redundant records. DNS round-robin may be relied upon to reorder
them.
3.1.1 Successful Authentication
If the chain of signatures validates the initial Client records as
well as any further records referenced if a DNSsec referral is
performed, an authentication attempt MAY be performed. If an
attempted authentication succeeds, the SDA MUST accept the
authentication as valid.
3.1.2 Failure in Authentication
If any break in the signature chain occurs in DNSsec verification of
the records required for authentication, the authentication SHOULD
fail. If alternate mechanisms exist for authenticating the
Authentication Server, they MAY be used.
If an Authentication Service is selected, and the authentication
fails for non-technical reasons [different word?], then the
authentication MUST fail. If a technical failure occurs (such as
being unable to contact the Authentication Server), the SDA MAY
select another AR record to attempt or MAY retry on the same server.
If no further AR records are present and any retries have also
failed, then the authentication MUST fail.
4. Security Considerations
It is expected that some system of access control will be used to
determine what, if any, services are provided to the authenticated
Client.
Watson [Page 9]
Internet DRAFT DNSsec Authentication Referral November 1997
4.1 DNSsec Use
Spoofing of AR RRs could result in unauthorized authentication.
DNSsec MUST be used to verify the authenticity of the AR RRs, as well
as the chain to the DNS root. For example, if an AR refers to
Kerberos IV, DNSsec MUST be used to verify the retrieval of the
Client's AR record, and the retrieval of the Kerberos IV Server's IP
address from Authentication Server FQDN.
4.2 The Weakest Link
While DNSsec provides strong cryptography to protect data
authenticity and to allow expiration, many distributed security
mechanisms are not as strong. For example, while an AR record may be
valid, an NIS server connection may be spoofed, hijacked,
eavesdropped, etc.
4.3 Local Site Policy
Local site policy is relied upon for a number of key decisions in the
authentication process. For example, before attempting to follow an
AR chain, the SDA must first confirm that the initial name provided
is allowed to authenticate to it. It must also determine which
authentication service types in the AR list for the name are
appropriate for use. An SDA MAY choose not to accept authenticatino
to a weak Authentication Service. The definition of weak SHOULD be
defined in a local site policy.
A site might accept initial attempts at authentication to
*.user.watson.org. On a successful and verified referral, it might
then be willing to accept authentication against any strong
Authentication Service (e.g., KerberosIV or KerberosV), but not
against weaker services (e.g., NIS).
If AR information can be verified externally, do so. For example, if
Kerberos IV server to realm mapping information exists in a local
krb.conf, consistency should be verified.
Correct logging practice, as well as approaches for dealing with
various types of failures given the varied mechanisms provided may
also involve significant local determination. All authentication
events SHOULD be logged. Selective reporting of errors to the Client
may also improve security.
Watson [Page 10]
Internet DRAFT DNSsec Authentication Referral November 1997
5. References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and
Facilities,'' RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1034, ISI, November 1987.
[DNSSEC] D. Eastlake, C. Kaufman, ``Domain System Security
Extensions,'' RFC 2065, CyberCash & Irix, January 1997.
[HESIOD] S. Dryer, ``The Hesiod Name Server,'' MIT, January 1988.
[IPSEC] R. Atkinson, ``Security Architecture for the Internet
Protocol,'' RFC 1825, Navy Research Laboratory, August
1995.
[SSH] M. Ylonen, T. Kivinen, M. Saarinen, ``SSH Transport Layer
Protocol,'' draft-ietf-secsh-transport-02.txt, SSH,
October 1997.
[KERBEROSIV] S. Miller, B. Neuman, J. Schiller, J. Saltzer, ``Kerberos
Authentication and Authorization System,'' MIT, December
1988.
[RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, ``Remote
Authentication Dial In User Service (RADIUS),'' RFC 2138,
April 1997.
6. Author's Address
Robert Watson
Carnegie Mellon University
SMC 4105
PO Box 3015
Pittsburgh, PA 15230
Phone: (412) 862-2696
Email: robert+ietf@cyrus.watson.org
Watson [Page 11]

522
doc/expired/draft-ietf-dnssec-as-map-05.txt Normal file
View file

@ -0,0 +1,522 @@
INTERNET-DRAFT Mapping AS Number into the DNS
July 1997
Expires January 1998
Mapping Autonomous Systems Number into the Domain Name System
------- ---------- ------- ------ ---- --- ------ ---- ------
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-ietf-dnssec-as-map-05.txt, is intended to
be become a Best Current Practice RFC concerning utilization of the
Domain Name System (DNS) to support routing security. Distribution of
this document is unlimited. Comments should be sent to the DNS
Security Working Group mailing list <dns-security@tis.com> or to the
author.
This document is an Internet-Draft. 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.''
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 (East USA), ftp.isi.edu (West USA),
nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe),
munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa).
Donald E. Eastlake 3rd [Page 1]
INTERNET-DRAFT Mapping AS Numbers into the DNS
Abstract
One requirement of secure routing is that independent routing
entities, such as those identified by Internet Autonomous System
Numbers, be able to authenticate messages to each other. Additions
have developed to the Domain Name System to enable it to be used for
authenticated public key distribution [RFC 2065]. This draft maps
all Autonomous System numbers into DNS Domain Names so that the DNS
security can be used to distribute their public keys.
[Changes from previous version are to accommodate AS numbers larger
than 16 bits and to delegate on decimal boundaries rather than binary
boundaries.]
Acknowledgements
The contributions of the following persons, listed in alphabetic
order, to this draft are gratefully acknowledged:
Ran Atkinson
Christian Huitema
Tony Li
Michael A. Patton.
Donald E. Eastlake 3rd [Page 2]
INTERNET-DRAFT Mapping AS Numbers into the DNS
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Acknowledgements...........................................2
Table of Contents..........................................3
1. Introduction............................................4
2. Autonomous System Number Mapping........................5
3. Meaning of RRs..........................................6
4. Security Considerations.................................8
References.................................................8
Author's Address...........................................8
Expiration and File Name...................................9
Donald E. Eastlake 3rd [Page 3]
INTERNET-DRAFT Mapping AS Numbers into the DNS
1. Introduction
There are a number of elements required to secure routing in the
Internet. One of these is a way that independently operated routing
domains be able to authenticate messages to each other.
Sharing a private symmetric key between each pair of such domains is
impractical. Assuming 2**16 Autonomous System routing entities,
which is what is allowed in current versions of BGP, [RFC 1771], this
would imply approximately 2**31 pairs, an impractical number of keys
to securely generate, install, and periodically replace.
The solution is to use public key technology whereby each routing
domain has a private key it can use to sign messages. Other domains
that know the corresponding public key can then authenticate these
messages. Such authenticated messages can be used to set up and
maintain efficient symmetric keys on an as needed basis.
But how do the domains securely obtain the Autonomous System number
to public key mapping?
Extensions have been developed for the Domain Name System that enable
it to be conveniently used for authenticated public key distribution
[RFC 2065]. A variety of key types can be supported. All that is
required is a mapping of Autonomous System numbers into domain names,
which is provided by this draft.
It should be noted that the public keys retrieved from DNS will
likely be used primarily to authenticate initial connection set up
messages. Autonomous Systems that need to converse with any
frequency will probably negotiate more efficient symmetric session
keys.
Donald E. Eastlake 3rd [Page 4]
INTERNET-DRAFT Mapping AS Numbers into the DNS
2. Autonomous System Number Mapping
Autonomous System (AS) numbers are usually written as decimal number
and when blocks of AS numbers are delegated to a registry, it is
normally on decimal boundaries. Their current use in BGP is limited
to 16 bits providing a maximum value of 65,535. For example, ANS is
autonomous system 690. However, there is no inherent size limit in
the AS concept. AS numbers are mapped into a domain name as
described below.
Write the AS number, as usual, as a decimal number without any
"thousands" punctuation. If it is less than 5 digits, add leading
zeros to bring it up to five digits. Then simply reverse the order
of the digits, put a period between them, and append ".length.in-
as.arpa" where "length" is the number of AS digits. This mapping is
analogous to the IPv4 address mapping into the in-addr.arpa DNS
domain.
Thus the domain name correspond to Autonomous System 690 (decimal) is
0.9.6.0.0.5.in-as.arpa.
the domain corresponding to the largest possible AS number in BGP is
5.3.5.5.6.5.in-as.arpa.
the domain corresponding to AS number 65,000 is
0.0.0.5.6.5.in-as.arpa.
and the domain correspond to a hypothetical future greater than 16
bit AS number 1,234,567 is
7.6.5.4.3.2.1.7.in-as.arpa.
Donald E. Eastlake 3rd [Page 5]
INTERNET-DRAFT Mapping AS Numbers into the DNS
3. Meaning of RRs
The following guidance is given for some resource record (RR) types
that could be stored under the names mapped from AS numbers. The KEY
RR is given first, followed by the SIG RR, the NXT RR, and then some
additional RR types in alphabetic order.
KEY: This type of RR associates a public key with the owner name
which, in this case, corresponds to an Autonomous System (AS). Under
DNS security as proposed in RFC 2065 the KEY RR can be used to store
a variety of digital keys. A KEY for use in securing routing
communications between ASs will have the end entity flag bit on, the
authentication use prohibited flag bit off, and a protocol byte or
flag bit indicating routing communications use. Such a public key can
be used to authenticate communications with or between ASs. The
existence of such KEY RRs in the primary reason for mapping AS names
into the DNS.
SIG: The SIG signature resource record authenticates the RRs
that it signs as described in RFC 2065. Assuming the signer who
generated the SIG is trustworthy, such as the in-as.arpa zone owner,
then the signed RRs can be trusted.
NXT: An NXT RR is used in DNS security to provide authenticated
denial of the existence of types and names as described in RFC 2065.
A, AAAA: Type A or AAAA RRs SHOULD NOT be placed at AS nodes.
AS domain names are reserved for Autonomous Systems only and should
NOT be used for a host or any type of end entity other than an
Autonomous System.
CNAME: This type of RR is an alias pointing to another domain
name. An AS could have a CNAME pointing to a different AS but this
is not likely to be very useful as AS RRs will normally be looked up
when the AS number is actually encountered in use.
MX: There is no special use for an MX RR for an AS name. It
could point to a host that would accept mail related to that AS.
NS: The presence of NS records under an AS name means that it
has been carved out as a subzone. This gives the AS complete control
over the zone refresh parameters and control over the creation of
inferior names. No special meaning is currently assigned to such
inferior names so, although this is not advised, they could be used
for hosts or whatever. In this case, the will also be a zone KEY at
the AS name, indicated by having the zone flag bit on.
PTR: The part of the forward domain tree that administratively
corresponds to the AS SHOULD be indicated by a PTR RR. If some
entity, say example.xx, has several ASs, there would be PTRs to
Donald E. Eastlake 3rd [Page 6]
INTERNET-DRAFT Mapping AS Numbers into the DNS
example.xx from several names in the in-as.arpa hierarchy.
RP: A Responsible Person RR SHOULD appear under each AS name
telling you who you should contact in the case of problems with that
AS
TXT: Text RRs can be used for comments, postal address, or
similar notes under an AS name.
Donald E. Eastlake 3rd [Page 7]
INTERNET-DRAFT Mapping AS Numbers into the DNS
4. Security Considerations
This document concerns a means to map Internet Autonomous System
numbers into the Domain Name System (DNS) so that DNS can be used to
provide secure distribution of Autonomous System's public keys. The
security of the resulting AS to key mapping is dependent on the
security of the DNS security extensions and of the DNS zone where the
key is stored.
The most obvious way of using the AS keys retrieved from DNS is to
authenticate communications with a directly connected AS. However,
this does not prove that any routing information exchanged is
actually correct and note that routing information communicated over
this secured path may be indirectly forwarded from or to yet other
ASs.
References
[RFC 1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
November 1987
[RFC 1035] - Domain Names - Implementation and Specifications, P.
Mockapetris, November 1987.
[RFC 1771] - Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-
4)", 03/21/1995.
[RFC 2065] - Domain Name System Security Extensions, D. Eastlake, C.
Kaufman, January 1997.
Author's Address
Donald E. Eastlake 3rd
CyberCash, Inc.
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 508 287 4877
+1 703 620-4200 (main office, Reston, VA)
FAX: +1 508 371 7148
EMail: dee@cybercash.com
Donald E. Eastlake 3rd [Page 8]
INTERNET-DRAFT Mapping AS Numbers into the DNS
Expiration and File Name
This draft expires January 1998.
Its file name is draft-ietf-dnssec-as-map-05.txt.
Donald E. Eastlake 3rd [Page 9]

464
doc/expired/draft-ietf-dnssec-indirect-key-01.txt Normal file
View file

@ -0,0 +1,464 @@
INTERNET-DRAFT Indirect KEY RRs
November 1997
Expires May 1998
Indirect KEY RRs in the Domain Name System
-------- --- --- -- --- ------ ---- ------
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-ietf-dnssec-indirect-key-01.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. 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.''
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 (East USA), ftp.isi.edu (West USA),
nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe),
munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa).
Abstract
RFC 2065 defines a means for storing cryptogrpahic public keys in the
Domain Name System. An additional code point is defined for the KEY
resource record (RR) algorithm field to indicate that the key itself
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.
Donald E. 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...........................4
2.1 The Target Type Field..................................4
2.2 The Target Algorithm Field.............................5
2.3 The Hash Fields........................................5
3. Performance Considerations..............................7
4. Security Considerations.................................7
References.................................................8
Author's Address...........................................8
Expiration and File Name...................................8
Donald E. Eastlake 3rd [Page 2]
INTERNET-DRAFT Indirect KEY RRs
1. Introduction
The Domain Name System (DNS) security extensions [RFC 2065] 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, in many cases it will 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 [see draft-ietf-dnssec-
certs-*.txt] 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.
Donald E. Eastlake 3rd [Page 3]
INTERNET-DRAFT Indirect KEY RRs
2. The Indirect KEY RR Algorithm
Domain Name System (DNS) KEY Resource Record (RR) [RFC 2065]
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 thae 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 (varible size) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
2.1 The Target Type Field
Target type specifies the type of the key containing data being
pointed at.
Target types 0 and 65535 are reserved.
Target type 1 indicates that the pointer is a domain name from which
KEY RRs [RFC 2065] should be retrieved. Name compression in the
pointer field is prohibited.
Target type 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 schmes may be
defined which return multiple keys.)
Target type 2 indicates that the pointer is a domain name from which
CERT RRs [draft-ietf-dnssec-certs-*.txt] should be retrieved. Name
compression in the pointer field is prohibiited.
Target type 3 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 [draft-ietf-dnssec-
Donald E. Eastlake 3rd [Page 4]
INTERNET-DRAFT Indirect KEY RRs
certs-*.txt]. (New URL schmes may be defined which return multiple
such data blocks.)
Target type 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 a
PKCS#1 format key. (New URL schmes may be defined which return
multiple keys.)
The target types 5 through 255 are available for assignment by IANA.
Target type 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 [draft-
ietf-dnssec-certs-*.txt] 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 schmes may be defined which return multiple such
certificates.)
Target types 512 through 65534 are available for assignment by IANA.
2.2 The Target Algorithm Field
The algorithm field is as defined in RFC 2065. 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 RR 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 RR
including any direct keys. This may or may not be true of any
indirect key pointed to. If that 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 inclduing a hash in a secure indirecting RR,
this secure hash can be checked against the hash of the actual keying
Donald E. Eastlake 3rd [Page 5]
INTERNET-DRAFT Indirect KEY RRs
material
Type Hash Algorithm
---- --------------
0 indicates no hash present
1 MD5 [RFC 1321]
2 SHA-1
3 RIPEMD
4-254 available for assignment
255 reserved
The hash size field is an unsigned octet count of the hash size. 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 hash algorithm 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.
Donald E. Eastlake 3rd [Page 6]
INTERNET-DRAFT Indirect KEY RRs
3. Performance Considerations
With current public key technology, an indirect key will sometimes be
shorter than the keying material it points at. This may improve DNS
permformace in the retrieval of the initial KEY RR. However, an
additional retrieval step then needs to be done to get the actualy
keying material which must be added to the overall time to get the
public key.
4. 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,
point to a key which can not be securely retrieved and is not
validatated by a secure hash in the indirect key RR, you have no
security.
Donald E. Eastlake 3rd [Page 7]
INTERNET-DRAFT Indirect KEY RRs
References
PKCS#1
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 2065 - D. Eastlake, C. Kaufman, "Domain Name System Security
Extensions", 01/03/1997.
draft-ietf-dnssec-certs-*.txt
Author's Address
Donald E. Eastlake 3rd
CyberCash, Inc.
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 978 287 4877
+1 703 620-4200 (main office, Reston, VA)
FAX: +1 978 371 7148
EMail: dee@cybercash.com
Expiration and File Name
This draft expires May 1998.
Its file name is draft-ietf-dnssec-indirect-key-01.txt.
Donald E. Eastlake 3rd [Page 8]

473
doc/expired/draft-ietf-dnssec-key-handling-00.txt Normal file
View file

@ -0,0 +1,473 @@
Domain Name System Security WG Edward Lewis
INTERNET DRAFT Olafur Gudmundsson
<draft-ietf-dnssec-key-handling-00.txt> Trusted Information Systems
November 21, 1997
Zone KEY RRSet Signing Procedure
<draft-ietf-dnssec-key-handling-00.txt>
0.0 Status of this Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
This Internet Draft expires on 21 May 1998.
Please send comments to the authors and dns-security@tis.com.
1.0 Abstract
Under the security extensions to DNS, as defined in RFC 2065 and
RFC 2137, a secured zone will have a KEY RRSet associated with
the domain name at the apex of the zone. This document covers
the manner in which this RRSet is generated, signed, and inserted
into the name servers.
1.5 Change Log
Version 01 - draft-lewis-dnskey-handling-01.txt:
Minor editorial changes.
Added paragraph in section 3.1 elaborating on off-net versus off-
net signing.
Added paragraph in section 4.0, step 2, requiring proof of
private key ownership.
Added Change Log section.
Version 02 - draft-ietf-dnssec-key-handling-00.txt:
Minor editorial changes.
Dynamic update reference changed from a draft to an RFC.
Expires November 21, 1997 [Page 1]
Internet Draft May 21, 1998
2.0 Introduction
Under the security extensions to DNS, as defined in RFC 2065
[RFC2065] and [RFC2137], a secured zone will have a KEY RRSet
associated with the domain name at the apex of the zone. At
least one of the KEY RR's will be a public key that is used
to verify SIG RR's in the zone. The SIG(KEY) RR covering this
RRSet must itself be signed by some other domain name, "some
other" being required to build a chain of trusted verifications.
(The alternative to requiring a different signer is to have
each name server hold all the public keys it will ever need in
a trusted place, which is not a scaleable solution.) A key
administration protocol external to the existing DNS protocol
is needed to produce the signature of the KEY RR's and to get
it into the DNS name servers.
As this is a first document on the subject, the "administration
protocol" will be described more as an "administrative procedure
or method."
The challenge is to design a secure procedure for handling the
unsigned public keys as they move from the place of generation
to a place where they are signed. The procedure must also
eventually lead to the insertion of the keys and signature into
the zone master file on a primary name server. The place of
generation and the place of the signing are recommended to be
disconnected from the Internet in order to protect the private
keys produced and/or used in the procedure. The two locations
may also be disconnected from each other.
The security of the public keys in this procedure is crucial to
the operation of the secure zone. An attack in which a false
public key is submitted for signing would enable a masquerade of
the true zone data by the attacker.
2.1 Terminology convention
In the literature on DNS, different terms are used to describe
the relationship of zones. "Super-zone and sub-zone," "parent
and child," and "delegator and delegatee" each refer to two
zones joined at a "zone cut." For each of the set of terms, the
former is the zone above the cut point, the latter is below the
cut point. In this document, we use the terms delegator and
delegatee.
3.0 DNSSEC Configuration Variants
There are a number of variants in the way in which DNSSEC can be
configured that impact a discussion of key management. The
discussion in section 4.0 will assume a nominal configuration
(defined in section 3.4) to simplify this document. In this
section, pertinent configuration decisions are described, and
how the choices make a particular configuration differ from the
so-called nominal configuration.
Expires November 21, 1997 [Page 2]
Internet Draft May 21, 1998
3.1 Off/On-Net Signing
In DNSSEC the configuration of DNS operations and signing fall
into two categories. The most secure is the use of an "off-net"
signer. The alternative is to use an "on-net" signer. These
two alternatives correspond to the Mode A and Mode B distinction
in UPDATE. (Mode A's initial zone signing is performed off-
net.)
The decision whether off-net or on-net signing is used is based
upon the risk assessment of the site's network management. An
on-net key is more vulnerable to attack than an off-net key just
by being present somewhere on the network. Off-net signing is
recommended for tighter security. Being behind a firewall might
be deemed insufficient if the administration does not trust the
protection in other parts of the network. This is matter of
choice for sites.
In off-net signing, the machinery performing the act of creating
the keyed signature is not reachable from the network the DNS
(name server set) is serving. I.e., there is no direct
mechanism for data transfer from the signing machine to a name
server. Without loss of generality, the DNS served network may
be thought of as the Internet.
The off-net signer need not be a stand-alone machine it may be
on an "air-gapped" (not physically connected) network. This
network may be just a very local network (i.e., within one
office or machine room), reserved for sensitive network
administration use. For the purposes of this document, this
will be labeled the back-room network (even if just a stand-
alone machine is on it).
The back-room network needs to be able to get information from
the Internet to derive the unsigned zone master files (among
other things). The back-room network generates the signed
files, which are inserted to the Internet DNS servers. The
mechanism to carry this out may be removable "static" media.
ADDED for draft-01:
(The preceding discussion focuses on the original signing of a
zone. Dynamic update requests for both off-net and on-net
situations are signed on-net, in the case of off-net, a
different key is used to sign the updates. The choice of off-
net or on-net is a comparison of the administrative effort to
maintain off-net signing versus the risk of an on-net private-
key compromise.)
For the purposes of this document, if off-net signing is used,
we assume key generation is also performed off-net.
On-net signing simply means the signer is accessible over the
Internet. If the back-room network exists, it is connected to
Expires November 21, 1997 [Page 3]
Internet Draft May 21, 1998
the Internet. In the procedures described below, the steps used
to transfer information from the Internet to the back-room
network are obviously unnecessary.
3.2 Relationship of Zone and Key Signer
In a nominal state, a zone's delegator will also be the signer
of the delegated zone's KEY RR set. E.g., for a zone named
"xz.test." with an NS RRSet at that name, the domain name
"test." would be the delegator of "xz.test." and signer of its
KEY RRSet. However, there may be cases in which some other
entity is the signer.
The role and composition of the "other entity" is not yet
defined, and may or may not ever be defined. This entity has
been referred to as a Signing Authority, whose sole purpose is
to sign records for clients. This may be more or less a
certification authority for DNS KEY RRSets. For the purposes of
this document, this entity will be assumed to be the delegating
zone, and it will be referred to as the "signing entity."
3.3 Name Server Topology
The separation between two delegated zones may mean that the two
do not share any name servers, such as most names under .COM and
.COM itself. In general, the set of name servers for two zones
may overlap. This document will focus on cases in which zones
do not share name servers or other facilities.
If the two zones share the same name servers they likely will
share the mechanism for the generation of zone keys. In this
case, the transfer of information between the zones becomes a
moot point because the problem may degenerate into accessing a
file in a shared file system. For zones sharing a back-room
network, the data for the two zones (between the off-net and on-
net machines) can be transferred together.
3.4 The Nominal Configuration
The nominal configuration used within the context of this
document is that the zones involved (one being the zone
generating the keys and the other zone performs the signing)
each employ off-line signing, and employ distinct sets of name
servers. In addition, the zone performing the signing is the
zone above the delegation point that creates the zone which is
generating and requesting the signing of its keys.
4.0 Key Signing Protocol/Procedure
The steps described here assume the nominal configuration in
section 3.4. In some configurations, the steps listed in this
section may degenerate into null or very simple operations.
Additionally, some steps can be carried out in parallel even
with the nominal configuration, so the strict ordering described
Expires November 21, 1997 [Page 4]
Internet Draft May 21, 1998
here need not be followed.
Step 0. A delegation needs to be instituted. A means to
authenticate both the delegator to the delegatee and vice versa
is also needed.
A delegation may only need to be created once. A NS RRSet and a
KEY RRSet must be installed by the delegating zone. Until a key
pair is generated the KEY RRSet will have a null zone key,
indicating that the delegated zone is initially unsecured.
Instituting means to authenticate the participants must occur
initially, and then again if the means of authentication (e.g.,
a secret key) is ever compromised.
How a delegation comes about is a subject for registries and/or
local network administration policies and procedures. These
groups should be aware of the responsibilities entailed in
instituting DNS security, especially the need for an active
recurring relationship, as the remaining steps describe.
It is assumed that at some point, the delegated zone acquires a
trusted public key(s) for at least one other entity. This could
be for root, the delegating zone, or for a signing authority.
These keys may be DNS zone keys or keys for some application,
e.g., trusted mail. This will enable the use of other secure
services to achieve the following steps. Selecting the services
may be within the scope of this document, but which should be
selected is still open for discussion.
Step 1. Delegated zone generates zone keys. A new pair may be
generated without changing the other pairs in use (assuming
others exist).
Step 2. The delegated zone sends keys to the signing entity.
All of the public key information, encoded in such a way that
the KEY RR's can be generated from it, crosses from the back-
room net to the Internet, and is shipped securely to the signing
entity. (Implementing "securely" is still an open issue.) It
is important that both the delegated zone and the signing entity
authenticate themselves to each other.
All public keys must be included, both newly generated and those
in current use. Keys are retired through omission.
ADDED for draft-01:
The delegated zone must prove ownership of the private keys
corresponding to each public key. This may be done by signing
the collection of public key data with each of the private keys.
Thus the submission would consist of one copy of each public key
and as many signatures as there were public keys. (For example,
submitting five public keys would require sending all five plus
five signatures.) This signing is only done to prove the
Expires November 21, 1997 [Page 5]
Internet Draft May 21, 1998
ownership of the private key, not for authentication.
Step 3. The signing entity signs the key set. The algorithm
used to sign the KEY RRSet need not be the same as the
algorithm(s) for which the keys were generated.
Step 4. The delegated zone receives KEY RRSet and SIG(KEY) RR
from the signing entity. The delegated zone must verify the
keys and signature locally. The zone must also verify that the
KEY RRSet is identical to the set of keys submitted for
signature in step 2, to protect against a masquerader from
submitting keys for signature. Once the records are signed,
there is no requirement for enhanced security while transmitting
the information across the Internet because the DNS signature
provides non-repudiation.
Step 5. Delegating zone gets the KEY RRSet and SIG(KEY) RR.
The KEY RRSet and the SIG(KEY) RR are sent from the signing
entity to the delegating zone's master files and optionally the
name servers. In the nominal case, the signing entity and the
delegating zone are one in the same, so this may be a trivial
step. (The latter is to ensure the public key will be available
for verifications once the signing process - step 7 - is
finished.)
Step 6. The delegating zone signs its zone data. This step may
be done in parallel with steps 2-5. Note: signing a zone does
not require that a new key pair be generated.
Step 7. The new zone data enters DNS. The KEY RRSet, SIG(KEY
RR) and the rest of the signed zone data and signatures traverse
from the back-room network and are inserted into the DNS primary
name server serving the Internet side.
Steps 1 through 7 are repeated whenever a new key pair is
required. Note that the signing in step 6 may not sign all
records; some records may have signature records from older keys
that are sufficient.
5.0 Resigning a KEY RRSet
When the delegating zone resigns itself, the KEY RRSet of a
delegated zone may be resigned. In this case, the newly created
SIG(RR) must be sent to the delegatee for inclusion.
The signing of a delegatee's keys in the manner of the previous
paragraph may be prompted by a request from the delegatee. A
SIG(RR) record may be approaching its expiration date, although
the KEY RRSet it is verifying has not changed.
6.0 Open Issues
This section is intentionally left undeveloped to encourage more
feedback.
Expires November 21, 1997 [Page 6]
Internet Draft May 21, 1998
Timing of steps, required response times.
The signing cycles of zones will likely be out of phase of each
other. If they were not, then there would be "signing crunches"
which would add variability to the spacing of events in the
procedure. One issue is how this should be addressed. Should
there be a recommended limit on signing entity's response?
Should this even be specified?
Can secure e-mail be used? Perhaps, and discussions to this
effect have occurred, using secure e-mail as a conduit for (at
least) the unsigned keys.
7.0 Operational Considerations
A widely delegated zone, such as .COM, or a zone publishing KEY
RR's for others, such as a large Internet access provider,
should expect a huge performance impact in signing the KEY
RRSets for it delegations. Running on a Pentium 166MHz
computer, simply signing the current .COM records, requires 40
hours. (Measured in January 1997.) This covers just the NXT
RRSets and a few other records. Having to sign a KEY RRSet for
each member of the zone will require about the same computing
resources, and much more overhead in the handling of the
individual KEY RRSets.
8.0 Security Considerations
This document discusses a procedure for handling the keys used
by DNS for its security and the keys for applications employing
DNS for key distribution. Once in DNS, keys are protected by
the presence of a keyed hash, which can be used to verify the
source and integrity of the public key data. During the process
described here, the keyed hash is not yet present, leaving the
keys vulnerable to modification. The security of this process
is crucial to the usefulness of DNS as a key distribution
mechanism. At this point many issue remain to be resolved, a
thorough security analysis of the process is premature.
9.0 References
[RFC2065] "Domain Name System Security Extensions," D. Eastlake,
3rd, and C. Kaufman
http://ds.internic.net/rfc/rfc2065.txt
[RFC2137] "Secure Domain Name System Dynamic Update," D.
Eastlake, 3rd
http://ds.internic.net/rfc/rfc2137.txt
Expires November 21, 1997 [Page 7]
Internet Draft May 21, 1998
10.0 Author's Addresses
Edward Lewis Olafur Gudmundsson
Trusted Information Systems Trusted Information Systems
3060 Washington Road 3060 Washington Road
Glenwood, MD 21738 Glenwood, MD 21738
+1 301 854 5794 +1 301 854 5700
<lewis@tis.com> <ogud@tis.com>
Expires November 21, 1997 [Page 8]

521
doc/expired/draft-ietf-dnssec-rollover-00.txt Normal file
View file

@ -0,0 +1,521 @@
INTERNET-DRAFT DNSSEC Key Rollover
October 1998
Expires April 1999
Domain Name System (DNS) Security Key Rollover
------ ---- ------ ----- -------- --- --------
Donald E. Eastlake 3rd, Mark Andrews
Status of This Document
This draft, file name draft-ietf-dnssec-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 security mailing
list <dns-security@tis.com> or to the authors.
This document is an Internet-Draft. 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.''
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
Practical 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 is
specified.
D. Eastlake 3rd, M. Andrews [Page 1]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................3
2. Key Rollover Scenarios..................................3
3. Rollover Operation......................................4
3.1 Rollover to Parent.....................................4
3.2 Rollover to Children...................................5
4. Rollover NOTIFY.........................................6
5. Security Considerations.................................7
References.................................................8
Authors Address............................................8
Expiration and File Name...................................9
D. Eastlake 3rd, M. Andrews [Page 2]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
1. Introduction
The Domain Name System (DNS) [RFC 1034, RFC 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 [draft-ietf-dnssec-secext2-*].
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
[draft-ietf-dnssec-secops-*.txt].
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 hundreds of thousands of new signatures on
the existing child public keys to the child zones.
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document are to be interpreted as described in RFC 2119.
2. Key Rollover Scenarios
Although DNSSEC provides for the storage of other keys in the DNS for
a variety of 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. 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 RRsets but they
will be necessary in practical cases. 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
D. Eastlake 3rd, M. Andrews [Page 3]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
generally be left due to clock skew and to avoid massive load on
large zones due to the signatures on their entire contents expiring
simultaneously.
Assume a zone with a secure parent and secure children 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 zone and these RRs may also exist at
the leaf node for this zone in its parent. The contents of the zone
and the zone KEY RRs of its secure children will have SIGs under the
old key.
The 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. It 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 the zone. Finally, it needs to
give new SIG RRs to its children that cover their KEY RRs if it has
these, or signal its children to ask for such SIG RRs.
3. Rollover Operation
Rollover operations use a DNS request syntactically identical to the
UPDATE request [RFC 2136] except that the operation is ROLLOVER which
is equal to TBD. Considerations for such request to the parent and
children of a zone are given in the subsections.
[This draft does not currently consider cross-certification key
rollover.]
3.1 Rollover to Parent
A zone rolling over its KEY RRset sends a ROLLOVER command to the
parent. The Zone should be specified as the parent zone and no
Prerequisites are included. The Update section has the 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 SIG are the
requested inception and expiration times for the parent SIG.
If the ROLLOVER command is erroneous or violates parental policy, an
Error response is returned.
If the ROLLOVER command is OK and the parent can sign online, its
response may include the new parent SIG(s) in the Update section.
D. Eastlake 3rd, M. Andrews [Page 4]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
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.
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). This
downward ROLLOVER request is distinguished from those in Section 3.2
below in that the Zone section is the parental zone.
The reason for sending the ROLLOVER request regardless of whether the
new SIG RR(s) were sent in the original response is to provide an
indication to the operators of the zone in the event someone is
trying to hijack the zone.
Although the parent zone need not hold or serve the child's key, the
ROLLOVER command MUST NOT actually 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 to the
controller of the child private key of future authoritative existence
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 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).
If the parent holds the KEY RRset for the child (whether or not it
actually serves it from the parent zone), it can simply do a ROLLOVER
request to to child specifying the child as the Zone in the request
and the new SIG(KEY)s to be added in the Update section. The
inception and expiration times in the SIG(s) indicate the time during
which the parent will be utilizing the new parent key. It is up to
the child when and how it adds the new parental SIG(s). The ROLLOVER
request may optionally indicate the deletion of old parental SIG(s)
D. Eastlake 3rd, M. Andrews [Page 5]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
but SHOULD only do so if the corresponding key is being withdrawn by
the parent in advance of the expiration time in the old SIG(s). It
is up to the child when and how it deletes the old parental SIG(s).
Even if the expiration of the old SIG(s) equals the inception time of
the new SIG(s), the child should serve both signatures for a fudge
time to account for clock skew.
A ROLLOVER request is used instead of an UPDATE because serves may
wish to support ROLLOVER via special techniques, such as notification
to the operator, even when they have not implemented UPDATE. With
adequate advance notice, even manual cut and paste editing of the
master file and restarting of a DNS server process could work.
If the parent does not retain knowledge of the child KEY RRset, then
the parent simply notifies the child via a ROLLOVER NOTIFY (see
Section 4 below) that the parent KEY(s) have changed. The child then
proceeds to do an upward ROLLOVER request to obtain the new parental
SIG(s). (This requires that a different method, such as TSIG, be
used to secure such ROLLOVER requests since we are assuming the
parent does not have authoritative knowledge of the child public key.
See Section 5 below.)
The NOTIFY technique MAY also be used by parents who retain knowledge
of their children's KEY RRsets.
4. Rollover NOTIFY
A ROLLOVER NOTIFY informs a child zone that the parent zone want it
to resubmit its keys for resigning.
A ROLLOVER NOTIFY MUST be signed and if not signed a BADAUTH response
generated.
A ROLLOVER NOTIFY is a NOTIFY reqeust [RFC 1996] that has a QTYPE of
SIG and the owner name of the child zone. The answer section is
empty.
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 saem 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
D. Eastlake 3rd, M. Andrews [Page 6]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
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. Care should be taken to rate limit
these message so prevent them being used to facilitate a denial of
service attack.
Once the message has been sent (or suppressed) to the child zone's
administrator the master server for the child zone is free to respond
to the ROLLOVER NOTIFY request.
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 authentication by request SIG(s)under the
old zone KEY(s) of the requestor [draft-ietf-dnssec-secext2-*.txt].
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-dnssec-tsig-*.txt]. (TSIG
security could be used to rollover a zone to unsecured and to
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.
D. Eastlake 3rd, M. Andrews [Page 7]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
References
[RFC 1034] - P. Mockapetris, "Domain names - concepts and
facilities", 11/01/1987.
[RFC 1035] - P. Mockapetris, "Domain names - implementation and
specification", 11/01/1987.
[RFC 1996] - P. Vixie, "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", August 1996.
[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]
[draft-ietf-dnssec-update2-*.txt]
[draft-ietf-dnssec-secext2-*.txt]
[draft-ietf-dnssec-secops-*.txt]
Authors Address
Donald E. Eastlake 3rd
IBM
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 978-287-4877
+1 914-784-7913
FAX: +1 978-371-7148
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 8]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
Expiration and File Name
This draft expires in April 1999.
Its file name is draft-ietf-dnssec-rollover-00.txt.
D. Eastlake 3rd, M. Andrews [Page 9]

291
doc/expired/draft-ietf-dnssec-secfail-00.txt Normal file
View file

@ -0,0 +1,291 @@
Internet-Draft B. Wellington, O. Gudmundsson
DNSSEC Working Group TISLabs
<draft-ietf-dnssec-secfail-00.txt> August 1998
Intermediate Security Failures in DNSSEC
<draft-ietf-dnssec-secfail-00.txt>
Status of this Memo
This document is an Internet-Draft. 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."
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).
Distribution of this memo is unlimited.
Abstract
This document identifies the situations where a signature
verification fails in a recursive security aware DNS server, and
how DNS servers should handle these cases, and the errors that
should be reported to DNS resolvers. This document proposes a new
error to be returned by DNSSEC capable servers.
A DNSSEC server acting as a recursive server MUST validate the
signatures on RRsets in a response it passes on; this draft
addresses the case when the data it receives fails signature
Wellington, Gudmundsson Expires February 1999 [Page 1]
Internet-Draft dnssec-secfail-00.txt August 1998
verification. The end resolver must be notified of this occurence
in such a way that it will not confuse it with another error.
1. Description
A DNS [RFC1034, RFC1035] transaction is defined by a query/response
pair. The resolver (client) sends a query to a name server. The
name server will respond if it contains the necessary information,
or forward the request to an authoritative server. The response
consists of the answer to the query, as well as authority records
showing that the response came from a valid source, and additional
records.
DNSSEC [RFC2065, SECEXT2] adds security to the DNS protocol. Each
RRset (set of DNS records with the same name/class/type) is
digitally signed, and the signature is verified by any server or
resolver who receives it. The receiver must therefore have a valid
key for verifying that data, as specified by a name/footprint pair.
A key's validity is determined by recursively verifying that it was
signed by a valid key; this recursion ends when a trusted key is
reached. Trusted keys must be obtained out of band, for example
through manual configuration.
Consider a recursive name server (R) that forwards a query to
another server (S). R receives an response from S, and attempts to
verify the included RRsets using a key that it trusts. Note that
this key may either be implicitly trusted or authenticated. The
signature verification fails for one or more RRsets in the answer
or authority section. The name server must communicate this error
in its response. To do this, a new return code (RCODE) will be
used, denoted SECFAIL (value TBD).
When a resolver receives a DNS response with an RCODE of SECFAIL,
that one of the following is true:
1) server S has sent invalid data to server R.
2) the data has been corrupted (possibly maliciously) between R and S.
3) server R has preconfigured S's key incorrectly.
4) There is more than one KEY with the same footprint and algorithm
for that name, and server R contains one different from the one used
by S to sign the data. This should not happen.
None of the current RCODE values sufficiently describe the case
where the data exists, but cannot be successfully retrieved and/or
transmitted. It is the responsibility of both R and the resolver
to attempt to identify the source of the problem.
Wellington, Gudmundsson Expires February 1999 [Page 2]
Internet-Draft dnssec-secfail-00.txt August 1998
2. Proposal
When the recursive name server (R) fails to verify a signed RRset
in the answer or authority section of a response that it receives,
it sets the RCODE of the response to SECFAIL before forwarding the
response to the entity that originated the query. There are
several possible modifications that could be made to the data by R:
1) all records could be passed unchanged
2) all records could be dropped
3) only the records that failed verification could be dropped
4) the SIGs of all records that failed verification could be dropped
A solution to this problem has not yet been decided.
If R receives a response with SECFAIL set, it does no processing on
the response, simply forwarding it if necessary. An intelligent
resolver MAY use additional queries to determine which of the
RRsets was invalid. The ERR record [ERR] or EDNS [EDNS] could also
be used to provide a more fine-grained description of the error.
When R fails to verify an RRset, it can determine whether or not
the key used has successfully verified other data (a flag or
timestamp could be stored along with the key). If it has, then the
key has not been misconfigured, and the error is due to data
corruption (possibly malicious) or a data error on the
authoritative server (S). R cannot further quantify the problem.
If the key has never successfully verified data, then the problem
may be a misconfigured key, or it could be due to malicious
corruption or a very unreliable network. In any case, this should
be logged, and the maintainer of R should determine (out of band)
whether the preconfigured key is erroneous. R MAY elect to retry
the query; this would succeed if the error was due to transient
network problems or a partial attack. Unless a retransmission
yields success, R should always send a response with SECFAIL set.
3. Limitations
If the path between a resolver and an authoritative server is
several hops, there is no way to determine at which recursive
server the SECFAIL error occurred. The data will be passed through
successive servers unchanged.
There is no way to distinguish a server continuously reporting
invalid data from an active attack. For instance, if a server has
an preconfigured key that is invalid, all queries using that key
will fail. An attack could easily simulate this behavior. There
is no way to split SECFAIL into more specific errors, since the
Wellington, Gudmundsson Expires February 1999 [Page 3]
Internet-Draft dnssec-secfail-00.txt August 1998
cause of the error cannot always be determined.
4. Security Considerations
Unless transaction signatures of some form are used [RFC2065,
TSIG], the RCODE field of a DNS response is not protected, so the
SECFAIL RCODE could be added or stripped by an attacker.
5. References
[EDNS] P. Vixie, "Extensions to DNS (EDNS)", Internet
Draft <draft-ietf-dnsind-edns-02.txt>, March 1998
[ERR] R. Watson, O. Gudmundsson, "Error Record (ERR)
for DNS" Internet Draft <draft-ietf-dnsind-dns-
error-00.txt>, March 1998
[RFC1034] P. Mockapetris, "Domain Names - Concepts and
Facilities", RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, "Domain Names - Implementation
and Specification", RFC 1034, ISI, November 1987.
[RFC2065] D. Eastlake, C. Kaufman, "Domain Name System
Security Extensions", RFC 2065, January 1997.
[SECEXT2] D. Eastlake, "Domain Name System Security Exten­
sions", Internet Draft <draft-ietf-dnssec-
secext2-05.txt>, April 1998.
[TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, "Secret
Key Transaction Signatures for DNS (TSIG)" Inter­
net Draft <draft-ietf-dnsind-tsig-05.txt>, June
1998.
Wellington, Gudmundsson Expires February 1999 [Page 4]
Internet-Draft dnssec-secfail-00.txt August 1998
6. Author address
Brian Wellington, Olafur Gudmundsson
TIS Labs at Network Associates
3060 Washington Road
Glenwood, MD 21738
+1 301 854 6889
bwelling@tis.com, ogud@tis.com
Wellington, Gudmundsson Expires February 1999 [Page 5]

278
doc/expired/draft-ietf-dnssec-simple-update-01.txt Normal file
View file

@ -0,0 +1,278 @@
DNSSEC Working Group Brian Wellington (TISLabs)
INTERNET-DRAFT February 1999
<draft-ietf-dnssec-simple-update-01.txt>
Updates: RFC 2065, RFC 2136, [TSIG]
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 August 1999 [Page 1]
INTERNET-DRAFT Simple Secure Dynamic Update February 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
[RFC2065, secext2] 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 August 1999 [Page 2]
INTERNET-DRAFT Simple Secure Dynamic Update February 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 August 1999 [Page 3]
INTERNET-DRAFT Simple Secure Dynamic Update February 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.
[RFC2065] D. Eastlake, C. Kaufman, ``Domain Name System Security
Extensions,'' RFC 2065, CyberCash & Iris, January 1997.
[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.
[secext2] D. Eastlake ``Domain Name System Security Extensions,''
draft-ietf-dnssec-secext2-07.txt, IBM, December 1998.
Expires August 1999 [Page 4]
INTERNET-DRAFT Simple Secure Dynamic Update February 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.
[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 August 1999 [Page 5]

1045
doc/expired/draft-ietf-dnssec-tkey-01.txt Normal file
View file

File diff suppressed because it is too large Load diff

871
doc/expired/draft-ietf-dnssec-update2-00.txt Normal file
View file

@ -0,0 +1,871 @@
INTERNET-DRAFT Donald E. Eastlake 3rd
OBSOLETES RFC 2137 Transfinite Systems Company
Expires: February 1999 August 1998
Secure Domain Name System (DNS) Dynamic Update
------ ------ ---- ------ ----- ------- ------
Status of This Document
This draft, file name draft-ietf-dnssec-update2-00.txt, is intended
to become a Proposed Standard RFC obsoleting RFC 2137. Distribution
of this document is unlimited. Comments should be sent to the DNS
security mailing list <dns-security@tis.com> or the author.
This document is an Internet-Draft. 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.''
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).
Donald E. Eastlake 3rd [Page 1]
INTERNET-DRAFT Secure DNS Update August 1998
Abstract
Revised Domain Name System (DNS) protocol extensions to authenticate
the data in DNS and provide key distribution services have been
defined in draft-ietf-dnssec-secext2-*.txt, which obsoletes the
original DNS security protocol definition in RFC 2065. In addition,
symetric key DNS transaction signatures have been defined in draft-
ietf-dnsind-tsig-*.txt. Secure DNS Dynamic Update operations were
also been defined [RFC 2137] in connection RFC 2065. This document
updates secure dynamic update in light of draft-ietf-dnssec-secext2-
*.txt and draft-ietf-dnsind-tsig-*.txt. It describes how to use
digital signatures covering requests and data to secure updates and
restrict updates to those authorized to perform them as indicated by
the updater's possession of cryptographic keys.
Donald E. Eastlake 3rd [Page 2]
INTERNET-DRAFT Secure DNS Update August 1998
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Table of Contents..........................................3
1. Introduction............................................4
1.1. Overview of DNS Dynamic Update........................4
1.2. Overview of Public Key DNS Security...................4
1.3 Overview of Secret Key DNS Security....................5
2. Two Basic Modes.........................................6
2.1. Mode A................................................6
2.2. Mode B................................................7
3. Keys....................................................8
3.1. Update Keys...........................................8
3.1.1. Public Update Key Name Scope........................8
3.1.2. Public Update Key Class Scope.......................8
3.1.3. Public Update Key Signatory Field...................9
3.2. Zone Keys and Update Modes...........................10
3.3. Wildcard Public Key Punch Through....................11
4. Update Signatures......................................13
4.1. Update Request Signatures............................13
4.2. Update Data Signatures...............................13
5. Security Considerations................................14
6. IANA Considerations....................................14
References................................................15
Author's Address..........................................15
Expiration and File Name..................................15
Donald E. Eastlake 3rd [Page 3]
INTERNET-DRAFT Secure DNS Update August 1998
1. Introduction
Dynamic update operations have been defined for the Domain Name
System (DNS) in RFC 2136 but that RFC does not include a description
of security for those updates. Public key means of securing DNS data
and transactions and using it for public key distribution were
defined in RFC 2065 which has been updated by draft-ietf-dnssec-
sexect2-*.txt, and secret key means of securing DNS transactions are
defined in draft-ietf-dnsind-tsig-*.txt.
This document provides techniques based on the updated DNS security
RFC draft-ietf-dnssec-sexect2-*.txt and draft-ietf-dnsind-tsig-*.txt
to authenticate DNS updates of secure zones. (Secret key signatures
could be used to authenticate updates on non-secured DNS zones. That
case In not considered in this document.)
Familiarity with the DNS system [RFC 1034, 1035] is assumed.
Familiarity with the DNS security and dynamic update will be helpful.
1.1. Overview of DNS Dynamic Update
DNS dynamic update defines a new DNS opcode, new DNS request and
response structure if that opcode is used, and new error codes. An
update can specify complex combinations of deletion and insertion
(with or without pre-existence testing) of resource records (RRs)
with one or more owner names; however, all testing and changes for
any particular DNS update request are restricted to a single zone.
Updates occur at the primary server for a zone.
The primary server for a dynamic zone must increment the zone SOA
serial number when an update occurs or the next time the SOA is
retrieved if one or more updates have occurred since the previous SOA
retrieval and the updates themselves did not update the SOA.
1.2. Overview of Public Key DNS Security
DNS security authenticates data in the DNS by also storing digital
signatures in the DNS as SIG resource records (RRs). A SIG RR
provides a digital signature on the set of all RRs with the same
owner name and class as the SIG and whose type is the type covered by
the SIG. The SIG RR cryptographically binds the covered RR set to
the signer, signature inception and expiration date, etc. There are
one or more keys associated with every secure zone and all data in
the secure zone is signed either by a zone key or by a dynamic update
key tracing its authority to a zone key.
Donald E. Eastlake 3rd [Page 4]
INTERNET-DRAFT Secure DNS Update August 1998
DNS security also defines transaction SIGs and request SIGs.
Transaction SIGs appear at the end of a response. They authenticate
the response and bind it to the corresponding request using the key
of the host where the responding DNS server is.
Request SIGs appear at the end of a request and authenticate the
request with the key of the submitting entity.
DNS security also permits the storage of public keys in the DNS via
KEY RRs. These KEY RRs are also, of course, authenticated by SIG
RRs. KEY RRs for zones may be stored in their superzone and/or their
authoritive subzone servers so that the secure DNS tree of zones can
be traversed by a security aware resolver.
1.3 Overview of Secret Key DNS Security
draft-ietf-dnsind-tsig-*.txt provides a means for two processes that
share a secret key to authenticate DNS requests and responses sent
between them by appending TSIG digital signature RRs to those
requests and responses. Secret key digital signatures are generally
much faster to calculate and verify than public key digital
signatures. In addition, the need, in general, to cache KEY RRs and
perform the KEY-SIG chain verifications is avoided.
However, the cost for this speed and simplicity in TSIG use is the
requirement to securely achieve key distribution or agreement between
the communicating processes and to achieve agreement as to the
authority represented by a correct TSIG on a requested using a
partciular key.
Donald E. Eastlake 3rd [Page 5]
INTERNET-DRAFT Secure DNS Update August 1998
2. Two Basic Modes
A dynamic secure zone is any secure DNS zone that
(1) has a zone KEY RR signatory field indicates that updates are
implemented and either
(2a) contains one or more KEY RRs that can authorize dynamic
updates, i.e., entity or user KEY RRs with the signatory field
non-zero, or
(2b) has a primary server with one or more secret keys configured
to authorize updates requests and shared with one or more
update requesters.
Note: 2a and 2b can both be true for a zone.
There are two basic modes of dynamic secure zone which relate to the
update strategy, mode A and mode B. A summary comparison table is
given below and then each mode is described.
SUMMARY OF DYNAMIC SECURE ZONE MODES
CRITERIA: | MODE A | MODE B
=========================+====================+===================
Definition: | Zone Key Off line | Zone Key On line
=========================+====================+===================
Server Workload | Medium | High
-------------------------+--------------------+-------------------
Key Restrictions | Fine grain | Coarse grain
-------------------------+--------------------+-------------------
Dynamic Data Temporality | Transient | Permanent
-------------------------+--------------------+-------------------
Dynamic Key Rollover | No | Yes
-------------------------+--------------------+-------------------
NOTE: The Mode A / Mode B distinction only effects the validation
and performance of update requests. It has no effect on retrievals.
2.1. Mode A
For mode A, the zone owner private key and static zone master file
are kept off-line for maximum security of the static zone contents.
As a consequence, any dynamicly added or changed RRs are signed in
the secure zone by their authorizing dynamic update key and they are
backed up, along with this SIG RR, in a separate online dynamic
master file. In this type of zone, server computation is generally
reduced since the server need only check signatures on the update
data and request, which have already been signed by the updater
(generally a much faster operation than signing data) and update the
Donald E. Eastlake 3rd [Page 6]
INTERNET-DRAFT Secure DNS Update August 1998
NXT RRs which need to be changed, if any. Because the dynamicly
added RRs retain their update KEY signed SIG, finer grained control
of updates can be implemented via the KEY RR signatory field (unique
name restriction and weak update key restriction). Because dynamic
data is only stored in the online dynamic master file and only
authenticated by dynamic keys which expire, updates are transient in
nature. Key rollover for an entity that can authorize dynamic
updates is more cumbersome since the authority of their key must be
traceable to a zone key and so, in general, they must securely
communicate a new key to the zone authority for manual transfer to
the off line static master file. NOTE: for this mode the zone SOA and
NXT RRs must be signed by a dynamic update key, which will be an end
entity key with an owner name of the zone name, and that private key
must be kept on line so that the SOA and NXTs can be changed for
updates.
2.2. Mode B
For mode B, the zone owner private key and master file are kept on-
line at the zone primary server. When authenticated updates succeed,
SIGs under the zone key for the resulting data (as well as possible
NXT and SOA changes) are calculated and these SIG (and possible
SOA/NXT) changes are entered into the zone and the unified on-line
master file.
As a consequence, this mode generally requires more computational
effort on the part of the server as it computes zone data signatures
in addition to verifying the signatures on requests. Because signing
generally takes more effort than verification, these signatures
generally will take more effort to calculate than it would take to
verify the data signatures required in Mode A. Because the zone key
is used to sign all the zone data, the information as to who
originated the current state of dynamic RR sets and even that data is
the result of a dynamic update as opposed to coming from an original
master file, is lost, making unavailable the fine grain control of
some values of the KEY RR signatory field. In addition, the
incorporation of the updates into the primary master file and their
authentication by the zone key makes them permanent in nature.
Maintaining the zone key on-line also means that dynamic update keys
which are signed by the zone key can be dynamically updated in real
time since the zone key is available to dynamically sign new values.
Donald E. Eastlake 3rd [Page 7]
INTERNET-DRAFT Secure DNS Update August 1998
3. Keys
Dynamic update requests depend on update keys as described in section
3.1 below. In addition, the zone secure dynamic update mode and
availability of some options is indicated in the zone KEY(s).
Finally, a special rule is used in searching for KEYs to validate
updates as described in section 3.3.
3.1. Update Keys
All update requests to a secure zone must include signature(s) by one
or more private or secret keys that together can authorize that
update. In order for the Domain Name System (DNS) server executing
the update request to confirm this (1) any secret keys must be know
to it, along with the authority represented by the secret key, and
(2) any private key or keys must have the corresponding public key or
keys available to and authenticatable by that server as specially
flagged KEY Resource Records (RRs).
The scope of authority of any secret keys is as configured at the
Server. Methods of describing and configuring such authority are not
discussed in this document.
The scope of authority of public update keys is indicated by their
KEY RR owner name, class, and signatory field flags as described
below. In addition, such KEY RRs MUST be entity or user keys and not
have the authentication use prohibited bit on.
All parts of the actual update MUST be within the scope/authority of
at least one of the keys used for a request SIG or TSIG on the update
request as described in section 4.
3.1.1. Public Update Key Name Scope
The owner name of any update authorizing KEY RR must (1) be the same
as the owner name of any RRs being added or deleted or (2) a wildcard
name including within its extended scope (see section 3.3) the name
of any RRs being added or deleted and those RRs must be in the same
zone.
3.1.2. Public Update Key Class Scope
The class of any update authorizing KEY RR must be the same as the
class of any RR's being added or deleted.
Donald E. Eastlake 3rd [Page 8]
INTERNET-DRAFT Secure DNS Update August 1998
3.1.3. Public Update Key Signatory Field
The four bit "signatory field" (see draft-ietf-dnssec-secext2-*.txt)
of any update authorizing KEY RR must be non-zero. The bits have the
meanings described below for non-zone keys (see section 3.2 for zone
type keys).
UPDATE KEY RR SIGNATORY FIELD BITS
0 1 2 3
+-----------+-----------+-----------+-----------+
| zone | strong | unique | general |
+-----------+-----------+-----------+-----------+
Bit 0, zone control - If nonzero, this key is authorized to attach,
detach, and move zones by creating and deleting NS, glue A, and
zone KEY RR(s). If zero, the key can not authorize any update
that would effect such RRs. This bit is meaningful for both
type A and type B dynamic secure zones. An update attempting to
add an NS or zone KEY RR to a node (i.e., make the node a
delegation point) is illegal if there are any deeper nodes in
the zone.
NOTE: do not confuse the "zone" signatory field bit with the
"zone" key type bit.
Bit 1, strong update - If zero, the key can only authorize updates
where any existing RRs of the same owner and class are
authenticated by a SIG using the same key. If nonzero, this key
is authorized to add and delete RRs even if there are other RRs
with the same owner name and class that are authenticated by a
SIG signed with a different dynamic update KEY. This bit is
meaningful only for type A dynamic zones that have a zone KEY
advertising that the feature is available. It is ignored in
type B dynamic zones.
Keeping this bit zero on multiple KEY RRs with the same or
nested wild card owner names permits multiple entities to exist
that can create and delete names but can not effect RRs with
different owner names from any they created. In effect, this
creates two levels of dynamic update key, strong and weak, where
weak keys are prohibited from interfering with each other but a
strong key can interfere with any weak keys or other strong
keys.
Bit 2, unique name update - This bit is useful only if the owner name
is a wildcard. (Any dynamic update KEY with a non-wildcard name
is, in effect, a unique name update key.) If zero, this key is
authorized to add and updates RRs for any number of names within
its wildcard scope. If nonzero, this key is authorized to add
Donald E. Eastlake 3rd [Page 9]
INTERNET-DRAFT Secure DNS Update August 1998
and update RRs for only a single owner name. If there already
exist RRs with one or more names signed by this key, they may be
updated but no new name created until the number of existing
names is reduced to zero. This bit is meaningful only for mode
A dynamic zones that have a zone KEY advertising that the
feature is available. It is ignored in mode B dynamic zones.
This bit can be used to restrict a KEY from flooding a zone with
new names. In conjunction with a local administratively imposed
limit on the number of dynamic RRs with a particular name, it
can completely restrict a KEY from flooding a zone with RRs.
Bit 3, general update - The general update signatory field bit has no
special meaning. If the other three bits are all zero, it must
be one so that the field is non-zero to designate that the key
is an update key. The meaning of all values of the signatory
field with the general bit on and one or more other signatory
field bits on is reserved.
All the signatory bit update authorizations described above only
apply if the update is within the name and class scope as per
sections 3.1.1 and 3.1.2.
3.2. Zone Keys and Update Modes
Zone type keys are automatically authorized to sign anything in their
zone, of course, regardless of the value of their signatory field.
For zone keys, the signatory field bits have different means than
they they do for update keys, as shown below. The signatory field
MUST be zero if dynamic update is not supported for a secure zone and
MUST be non-zero if it is.
ZONE KEY RR SIGNATORY FIELD BITS
0 1 2 3
+-----------+-----------+-----------+-----------+
| mode | strong | unique | general |
+-----------+-----------+-----------+-----------+
Bit 0, mode - This bit indicates the update mode for this zone. Zero
indicates mode A while a one indicates mode B.
Bit 1, strong update - If nonzero, this indicates that the "strong"
key feature described in section 3.1.3 above is implemented and
enabled for this secure zone. If zero, the feature is not
available and all update keys are treated as strong. Has no
effect if the zone is a mode B secure update zone.
Donald E. Eastlake 3rd [Page 10]
INTERNET-DRAFT Secure DNS Update August 1998
Bit 2, unique name update - If nonzero, this indicates that the
"unique name" feature described in section 3.1.3 above is
implemented and enabled for this secure zone. If zero, this
feature is not available and no wildcard update key is treated
as restricted to a single name. Has no effect if the zone is a
mode B secure update zone.
Bit 3, general - This bit has no special meaning. If dynamic update
for a zone is supported and the other bits in the zone key
signatory field are zero, it must be a one. The meaning of zone
keys where the signatory field has the general bit and one or
more other bits on is reserved.
If there are multiple zone KEY RRs with non-zero signatory fields and
zone policy is in transition, they might have different signatory
field values. In that case, strong and unique name restrictions MUST
be enforced as long as there is a non-expired zone key being
advertised that indicates mode A with the strong or unique name bit
on respectively. Mode B updates (i.e., no data signatures) MUST be
supported as long as there is a non-expired zone key that indicates
mode B. Mode A or mode ambiguous updates may be treated as mode B
updates at server option if non-expired zone keys indicate that both
are supported.
A server that will be executing update operations on a zone, that is,
the primary master server, MUST NOT advertize a zone key that will
attract requests for a mode or features that it can not support.
3.3. Wildcard Public Key Punch Through
Just as a zone key is valid throughout the entire zone, public update
keys with wildcard names are valid throughout their extended scope,
within the zone. That is, they remain valid for any name that would
match them, even existing specific names within their apparent scope.
(If this were not so, then whenever a name within a wildcard scope
was created by dynamic update using a wildcard named public update
key for authorization, it would be necessary to first create a copy
of the KEY RR with this name, because otherwise the existence of the
more specific name would hide the authorizing KEY RR and would make
later updates impossible. An updater could create such a KEY RR but
could not zone sign it with their authorizing signer. They would
have to sign it with the same key using the wildcard name as signer.
(This would create update KEYs signed by update KEYs which was
permitted in RFC 2065 but, for simplicity, is prohibit in draft-
ietf-dnssec-secext2-*.txt which requires all KEYs to be signed by
zone keys.) Thus in creating, for example, one hundred type A RRs
authorized by a *.1.1.1.in-addr.arpa KEY RR, without key punch
Donald E. Eastlake 3rd [Page 11]
INTERNET-DRAFT Secure DNS Update August 1998
through 100 As, 100 KEYs, and 200 SIGs would have to be created as
opposed to merely 100 As and 100 SIGs with wildcard key punch
through.)
Donald E. Eastlake 3rd [Page 12]
INTERNET-DRAFT Secure DNS Update August 1998
4. Update Signatures
Two kinds of signatures can appear in updates. Request signatures,
which are always required, cover the entire request and authenticate
the DNS header, including opcode, counts, etc., as well as the data.
Data signatures, on the other hand, appear only among the RRs to be
added and are only required for mode A operation. These two types of
signatures are described further below.
4.1. Update Request Signatures
An update can effect multiple owner names in a zone. It may be that
these different names are covered by different public or secret
dynamic update keys. For every owner name effected, the updater must
know a private or secret key valid to authorize updates for that name
(and the zone's class) and must prove this by appending request SIG
and/or TSIG RRs under each such key.
Request signatures occur in the Additional Information section. As
specified in draft-ietf-dnssec-secext2-*.txt, a public request
signature is a SIG RR occurring at the end of a request with a type
covered field of zero. As specified in draft-ietf-dnsind-tsig-*.txt,
a secret key request signature is a TSIG RR occuring at the end of
the request. Each request SIG or TSIG signs the entire request,
including DNS header, but excluding any other request signatures and
with the ARCOUNT in the DNS header set to what it would be without
the request signatures.
4.2. Update Data Signatures
Mode A dynamic secure zones require that the update requester provide
SIG RRs that will authenticate the after-update state of all RR sets
that are changed by the update and are non-empty after the update.
These SIG RRs appear in the request as RRs to be added and the
request must delete any previous data SIG RRs that are invalidated by
the request.
In Mode B dynamic secure zones, all zone data is authenticated by
zone key SIG RRs. In this case, data signatures need not be included
with the update. A prospective updater can determine which mode an
updatable secure zone is using by examining the signatory field bits
of the zone KEY RR or RRs (see section 3.2).
Donald E. Eastlake 3rd [Page 13]
INTERNET-DRAFT Secure DNS Update August 1998
5. Security Considerations
Any secure zone permitting dynamic updates is inherently less secure
than a static secure zone maintained off line as recommended in
draft-ietf-dnssec-secops-*.txt. If nothing else, secure dynamic
update requires on line change to and re-signing of the zone SOA
resource record (RR) to increase the SOA serial number. This means
that compromise of the primary server host could lead to arbitrary
serial number changes.
Isolation of dynamic RRs to separate zones from those holding most
static RRs can limit the damage that could occur from breach of a
dynamic zone's security.
6. IANA Considerations
Allocations of values of the KEY RR Signatory field described herein
as "reserved" requires an IETF consensus.
Donald E. Eastlake 3rd [Page 14]
INTERNET-DRAFT Secure DNS Update August 1998
References
[RFC1035] - Domain Names - Implementation and Specifications, P.
Mockapetris, November 1987.
[RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
November 1987.
[RFC2065] - Domain Name System Security Extensions. D. Eastlake, 3rd,
C. Kaufman. January 1997
[RFC2136] - Dynamic Updates in the Domain Name System (DNS UPDATE).
P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997.
[RFC2137] - Secure Domain Name System Dynamic Update. D. Eastlake.
April 1997.
draft-ietf-dnsind-tsig-*.txt
draft-ietf-dnssec-secext2-*.txt.
draft-ietf-dnssec-secops-*.txt.
Author's Address
Donald E. Eastlake, 3rd
Transfinite Systems Company
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 978-287-4877
+1 978-371-7148 (fax)
email: dee3@torque.pothole.com
Expiration and File Name
This draft expires February 1999.
Its file name is draft-ietf-dnssec-update2-00.txt.
Donald E. Eastlake 3rd [Page 15]

3531
doc/expired/draft-ietf-ipngwg-2292bis-00.txt Normal file
View file

File diff suppressed because it is too large Load diff

2176
doc/expired/draft-ietf-ipngwg-bsd-api-new-06.txt Normal file
View file

File diff suppressed because it is too large Load diff

813
doc/expired/draft-ietf-ipngwg-dns-lookups-05.txt Normal file
View file

@ -0,0 +1,813 @@
IPng Working Group Matt Crawford
Internet Draft Fermilab
Christian Huitema
Susan Thomson
Bellcore
October 14, 1999
DNS Extensions to Support IPv6 Address Aggregation and Renumbering
<draft-ietf-ipngwg-dns-lookups-05.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
1. Abstract
This document defines changes to the Domain Name System to support
renumberable and aggregatable IPv6 addressing. The changes include
a new resource record type to store an IPv6 address in a manner
which expedites network renumbering, one new query type and updated
definitions of existing query types that return Internet addresses
as part of additional section processing.
For lookups keyed on IPv6 addresses (often called reverse lookups),
this document defines a new zone structure which allows a zone to be
used without modification for parallel copies of an address space
(as for a multihomed provider or site) and across network
renumbering events.
Expires April 19, 2000 Crawford et al. [Page 1]
Internet Draft IPv6 DNS October 14, 1999
2. Introduction
Maintenance of address information in the DNS is one of several
obstacles which have prevented site and provider renumbering from
being feasible in IP version 4. Arguments about the importance of
network renumbering for the preservation of a stable routing system
and for other purposes may be read in documents cited here as
[RENUM]. To support the storage of IPv6 addresses without impeding
renumbering we define the following extensions.
o A new resource record type, "A6", is defined to map a domain
name to an IPv6 address, with a provision for indirection for
leading "prefix" bits.
o Existing queries that perform additional section processing to
locate IPv4 addresses are redefined to do that processing for
both IPv4 and IPv6 addresses.
o A new domain, IP6.INT, is defined to support lookups based on
IPv6 address.
o A new prefix-delegation method is defined, relying on new DNS
features [BITLBL, DNAME].
The changes are designed to be compatible with existing application
programming interfaces. The existing support for IPv4 addresses is
retained. Transition issues related to the coexistence of both IPv4
and IPv6 addresses in DNS are discussed in [TRANS].
This memo proposes a replacement for the specification in RFC 1886
and a departure from current implementation practices. The changes
are designed to facilitate network renumbering and multihoming.
Domains employing the A6 record for IPv6 addresses can insert
automatically-generated AAAA records in zone files to ease
transition. It is expected that after a reasonable period, RFC 1886
will become Historic.
The next three major sections of this document are an overview of
the facilities defined or employed by this specification, the
specification itself, and examples of use.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KWORD]. The key
word "SUGGESTED" signifies a strength between MAY and SHOULD: it is
believed that compliance with the suggestion has tangible benefits
in most instances.
Expires April 19, 2000 Crawford et al. [Page 2]
Internet Draft IPv6 DNS October 14, 1999
3. Overview
This section provides an overview of the DNS facilities for storage
of IPv6 addresses and for lookups based on IPv6 address, including
those defined here and elsewhere.
3.1. Name-to-Address Lookup
IPv6 addresses are stored in one or more A6 resource records. A
single A6 record may include a complete IPv6 address, or a
contiguous portion of an address and information leading to one or
more prefixes. Prefix information comprises a prefix length and a
DNS name which is in turn the owner of one or more A6 records
defining the prefix or prefixes which are needed to form one or more
complete IPv6 addresses. When the prefix length is zero, no DNS
name is present and all the leading bits of the address are
significant. There may be multiples levels of indirection and the
existence of multiple A6 records at any level multiplies the number
of IPv6 addresses which are formed.
An application looking up an IPv6 address will generally cause the
DNS resolver to access several A6 records, and multiple IPv6
addresses may be returned even if the queried name was the owner of
only one A6 record. The authenticity of the returned address(es)
cannot be directly verified by DNS Security [DNSSEC]. The A6
records which contributed to the address(es) may of course be
verified if signed.
3.2. Underlying Mechanisms for Reverse Lookups
This section describes the new DNS features which this document
exploits. This section is an overview, not a specification of those
features. The reader is directed to the referenced documents for
more details on each.
3.2.1. Delegation on Arbitrary Boundaries
This new scheme for reverse lookups relies on a new type of DNS
label called the "bit-string label" [BITLBL]. This label compactly
represents an arbitrary string of bits which is treated as a
hierarchical sequence of one-bit domain labels. Resource records
can thereby be stored on arbitrary bit-boundaries.
Examples in section 6 will employ the following textual
representation for bit-string labels, which is a subset of the
Expires April 19, 2000 Crawford et al. [Page 3]
Internet Draft IPv6 DNS October 14, 1999
syntax defined in [BITLBL]. A base indicator "x" for hexadecimal
and a sequence of hexadecimal digits is enclosed between "\[" and
"]". The bits denoted by the digits represent a sequence of one-bit
domain labels ordered from most to least significant. (This is the
opposite of the order they would appear if listed one bit at a time,
but it appears to be a convenient notation.) The digit string may
be followed by a slash ("/") and a decimal count. If omitted, the
implicit count is equal to four times the number of hexadecimal
digits.
Consecutive bit-string labels are equivalent (up to the limit
imposed by the size of the bit count field) to a single bit-string
label containing all the bits of the consecutive labels in the
proper order. As an example, either of the following domain names
could be used in a QCLASS=IN, QTYPE=PTR query to find the name of
the node with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32.
\[x3FFE07C0004000090A0020FFFE812B32/128].IP6.INT.
\[x0A0020FFFE812B32/64].\[x0009/16].
\[x07C00040/32].\[xFFF0/13].\[x2/3].IP6.INT.
Note that bits are left-justified in a hexadecimal string.
3.2.2. Reusable Zones
DNS address space delegation is implemented not by zone cuts and NS
records, but by a new analogue to the CNAME record, called the DNAME
resource record [DNAME]. The DNAME record provides alternate naming
to an entire subtree of the domain name space, rather than to a
single node. It causes some suffix of a queried name to be
substituted with a name from the DNAME record's RDATA.
For example, a resolver or server providing recursion, while looking
up a QNAME a.b.c.d.e.f may encounter a DNAME record
d.e.f. DNAME w.xy.
which will cause it to look for a.b.c.w.xy.
Expires April 19, 2000 Crawford et al. [Page 4]
Internet Draft IPv6 DNS October 14, 1999
4. Specifications
4.1. The A6 Record Type
The A6 record type is specific to the IN (Internet) class and has
type number 38 (decimal).
4.1.1. Format
The RDATA portion of the A6 record contains two or three fields.
+-----------+------------------+-------------------+
|Prefix len.| Address suffix | Prefix name |
| (1 octet) | (0..16 octets) | (0..255 octets) |
+-----------+------------------+-------------------+
o A prefix length, encoded as an eight-bit unsigned integer with
value between 0 and 128 inclusive.
o An IPv6 address suffix, encoded in network order (high-order
octet first). There MUST be exactly enough octets in this field
to contain a number of bits equal to 128 minus prefix length,
with 0 to 7 leading pad bits to make this field an integral
number of octets. Pad bits, if present, MUST be set to zero
when loading a zone file and ignored (other than for SIG
[DNSSEC] verification) on reception.
o The name of the prefix, encoded as a domain name. By the rules
of [DNSIS], this name MUST NOT be compressed.
The domain name component SHALL NOT be present if the prefix length
is zero. The address suffix component SHALL NOT be present if the
prefix length is 128.
It is SUGGESTED that an A6 record intended for use as a prefix for
other A6 records have all the insignificant trailing bits in its
address suffix field set to zero.
4.1.2. Processing
A query with QTYPE=A6 causes type A6 and type NS additional section
processing for the prefix names, if any, in the RDATA field of the
A6 records in the answer section. This processing SHOULD be
recursively applied to the prefix names of A6 records included as
Expires April 19, 2000 Crawford et al. [Page 5]
Internet Draft IPv6 DNS October 14, 1999
additional data. When space in the reply packet is a limit,
inclusion of additional A6 records takes priority over NS records.
It is an error for a A6 record with prefix length L1 > 0 to refer to
a domain name which owns a A6 record with a prefix length L2 > L1.
If such a situation is encountered by a resolver, the A6 record with
the offending (larger) prefix length MUST be ignored. Robustness
precludes signaling an error if addresses can still be formed from
valid A6 records, but it is SUGGESTED that zone maintainers from
time to time check all the A6 records their zones reference.
4.1.3. Textual Representation
The textual representation of the RDATA portion of the A6 resource
record in a zone file comprises two or three fields separated by
whitespace.
o A prefix length, represented as a decimal number between 0 and
128 inclusive,
o the textual representation of an IPv6 address as defined in
[AARCH] (although some leading and/or trailing bits may not be
significant),
o a domain name, if the prefix length is not zero.
The domain name MUST be absent if the prefix length is zero. The
IPv6 address MAY be be absent if the prefix length is 128. A number
of leading address bits equal to the prefix length SHOULD be zero,
either implicitly (through the :: notation) or explicitly, as
specified in section 4.1.1.
4.1.4. Name Resolution Procedure
To obtain the IPv6 address or addresses which belong to a given
hostname, a DNS client MUST obtain one or more complete chains of A6
records, each chain beginning with a record owned by the given
hostname and including a record owned by the prefix name in that
record, and so on recursively, ending with an A6 record with a
prefix length of zero. One IPv6 address is formed from one such
chain by taking the value of each bit position from the earliest A6
record which validly covers that position, as indicated by the
prefix length. The set of all IPv6 addresses for the given hostname
comprises the addresses formed from all complete chains of A6
records beginning at that hostname, discarding records which have
invalid prefix lengths as defined in section 4.1.2.
Expires April 19, 2000 Crawford et al. [Page 6]
Internet Draft IPv6 DNS October 14, 1999
If some A6 queries fail and others succeed, a client might obtain a
non-empty but incomplete set of IPv6 addresses for a host. In many
situations this may be acceptable. The completeness of a set of A6
records may always be determined by inspection.
4.2. Zone Structure for Reverse Lookups
Very little of the new scheme's data actually appears under IP6.INT;
only the first level of delegation needs to be under that domain.
More levels of delegation could be placed under IP6.INT if some
top-level delegations were done via NS records instead of DNAME
records, but this would incur some cost in renumbering ease at the
level of TLAs [AGGR]. Therefore, it is declared here that all
address space delegations SHOULD be done by the DNAME mechanism
rather than NS.
In addition, since uniformity in deployment will simplify
maintenance of address delegations, it is SUGGESTED that address and
prefix information be stored immediately below a DNS label "IP6".
Stated another way, conformance with this suggestion would mean that
"IP6" is the first label in the RDATA field of DNAME records which
support IPv6 reverse lookups.
When any "reserved" or "must be zero" bits are adjacent to a
delegation boundary, the higher-level entity MUST retain those bits
in its own control and delegate only the bits over which the lower-
level entity has authority.
To find the name of a node given its IPv6 address, a DNS client MUST
perform a query with QCLASS=IN, QTYPE=PTR on the name formed from
the 128 bit address as one or more bit-string labels [BITLBL],
followed by the two standard labels "IP6.INT". If recursive service
was not obtained from a server and the desired PTR record was not
returned, the resolver MUST handle returned DNAME records as
specified in [DNAME] and iterate.
5. Modifications to Existing Query Types
All existing query types that perform type A additional section
processing, i.e. the name server (NS), mail exchange (MX), and
mailbox (MB) query types, and the experimental AFS data base (AFSDB)
and route through (RT) types, must be redefined to perform type A,
A6 and AAAA additional section processing, with type A having the
highest priority for inclusion and type AAAA the lowest. This
redefinition means that a name server may add any relevant IPv4 and
IPv6 address information available locally to the additional section
Expires April 19, 2000 Crawford et al. [Page 7]
Internet Draft IPv6 DNS October 14, 1999
of a response when processing any one of the above queries. The
recursive inclusion of A6 records referenced by A6 records already
included in the additional section is OPTIONAL.
6. Usage Illustrations
This section provides examples of use of the mechanisms defined in
the previous section. All addresses and domains mentioned here are
intended to be fictitious and for illustrative purposes only.
Example delegations will be on 4-bit boundaries solely for
readability; this specification is indifferent to bit alignment.
Use of the IPv6 aggregatable address format [AGGR] is assumed in the
examples.
6.1. A6 Record Chains
Let's take the example of a site X that is multi-homed to two
"intermediate" providers A and B. The provider A is itself multi-
homed to two "transit" providers, C and D. The provider B gets its
transit service from a single provider, E. For simplicity suppose
that C, D and E all belong to the same top-level aggregate (TLA)
with identifier (including format prefix) '2345', and the TLA
authority at ALPHA-TLA.ORG assigns to C, D and E respectively the
next level aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28
and 2345:000E::/32.
C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the
prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to
B.
A assigns to X the subscriber identification '11' and B assigns the
subscriber identification '22'. As a result, the site X inherits
three address prefixes:
o 2345:00C1:CA11::/48 from A, for routes through C.
o 2345:00D2:DA11::/48 from A, for routes through D.
o 2345:000E:EB22::/48 from B, for routes through E.
Let us suppose that N is a node in the site X, that it is assigned
to subnet number 1 in this site, and that it uses the interface
identifier '1234:5678:9ABC:DEF0'. In our configuration, this node
will have three addresses:
Expires April 19, 2000 Crawford et al. [Page 8]
Internet Draft IPv6 DNS October 14, 1999
o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
6.1.1. Authoritative Data
We will assume that the site X is represented in the DNS by the
domain name X.EXAMPLE, while A, B, C, D and E are represented by
A.NET, B.NET, C.NET, D.NET and E.NET. In each of these domains, we
assume a subdomain "IP6" that will hold the corresponding prefixes.
The node N is identified by the domain name N.X.EXAMPLE. The
following records would then appear in X's DNS.
$ORIGIN X.EXAMPLE.
N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
SUBNET-1.IP6 A6 48 0:0:0:1:: IP6
IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
And elsewhere there would appear
SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET.
SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.
SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.
B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG.
C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0::
D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0::
E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
6.1.2. Glue
When, as is common, some or all DNS servers for X.EXAMPLE are within
the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry
enough "glue" information to enable DNS clients to reach those
nameservers. This is true in IPv6 just as in IPv4. However, the A6
record affords the DNS administrator some choices. The glue could
be any of
Expires April 19, 2000 Crawford et al. [Page 9]
Internet Draft IPv6 DNS October 14, 1999
o a minimal set of A6 records duplicated from the X.EXAMPLE zone,
o a (possibly smaller) set of records which collapse the structure
of that minimal set,
o or a set of A6 records with prefix length zero, giving the
entire global addresses of the servers.
The trade-off is ease of maintenance against robustness. The best
and worst of both may be had together by implementing either the
first or second option together with the third. To illustrate the
glue options, suppose that X.EXAMPLE is served by two nameservers
NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface identifiers
::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively.
Then the top-level zone EXAMPLE would include one (or more) of the
following sets of A6 records as glue.
$ORIGIN EXAMPLE. ; first option
X NS NS1.X
NS NS2.X
NS1.X A6 64 ::1:11:111:1111 SUBNET-1.IP6.X
NS2.X A6 64 ::2:22:222:2222 SUBNET-2.IP6.X
SUBNET-1.IP6.X A6 48 0:0:0:1:: IP6.X
SUBNET-2.IP6.X A6 48 0:0:0:2:: IP6.X
IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
$ORIGIN EXAMPLE. ; second option
X NS NS1.X
NS NS2.X
NS1.X A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET.
A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET.
NS2.X A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET.
A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET.
$ORIGIN EXAMPLE. ; third option
X NS NS1.X
NS NS2.X
NS1.X A6 0 2345:00C1:CA11:1:1:11:111:1111
A6 0 2345:00D2:DA11:1:1:11:111:1111
A6 0 2345:000E:EB22:1:1:11:111:1111
NS2.X A6 0 2345:00C1:CA11:2:2:22:222:2222
A6 0 2345:00D2:DA11:2:2:22:222:2222
A6 0 2345:000E:EB22:2:2:22:222:2222
The first and second glue options are robust against renumbering of
Expires April 19, 2000 Crawford et al. [Page 10]
Internet Draft IPv6 DNS October 14, 1999
X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail if
those providers' own DNS is unreachable. The glue records of the
third option are robust against DNS failures elsewhere than the
zones EXAMPLE and X.EXAMPLE themselves, but must be updated when X's
address space is renumbered.
If the EXAMPLE zone includes redundant glue, for instance the union
of the A6 records of the first and third options, then under normal
circumstances duplicate IPv6 addresses will be derived by DNS
clients. But if provider DNS fails, addresses will still be
obtained from the zero-prefix-length records, while if the EXAMPLE
zone lags behind a renumbering of X.EXAMPLE, half of the addresses
obtained by DNS clients will still be up-to-date.
The zero-prefix-length glue records can of course be automatically
generated and/or checked in practice.
6.1.3. Variations
Several more-or-less arbitrary assumptions are reflected in the
above structure. All of the following choices could have been made
differently, according to someone's notion of convenience or an
agreement between two parties.
First, that site X has chosen to put subnet information in a
separate A6 record rather than incorporate it into each node's
A6 records.
Second, that site X is referred to as "SUBSCRIBER-X" by both of
its providers A and B.
Third, that site X chose to indirect its provider information
through A6 records at IP6.X.EXAMPLE containing no significant
bits. An alternative would have been to replicate each subnet
record for each provider.
Fourth, B and E used a slightly different prefix naming
convention between themselves than did A, C and D. Each
hierarchical pair of network entities must arrange this naming
between themselves.
Fifth, that the upward prefix referral chain topped out at
ALPHA-TLA.ORG. There could have been another level which
assigned the TLA values and holds A6 records containing those
bits.
Finally, the above structure reflects an assumption that address
fields assigned by a given entity are recorded only in A6 records
Expires April 19, 2000 Crawford et al. [Page 11]
Internet Draft IPv6 DNS October 14, 1999
held by that entity. Those bits could be entered into A6 records in
the lower-level entity's zone instead, thus:
IP6.X.EXAMPLE. A6 40 0:0:11:: IP6.A.NET.
IP6.X.EXAMPLE. A6 40 0:0:22:: IP6.B.NET.
IP6.A.NET. A6 28 0:1:CA00:: IP6.C.NET.
and so on.
Or the higher-level entities could hold both sorts of A6 records
(with different DNS owner names) and allow the lower-level entities
to choose either mode of A6 chaining. But the general principle of
avoiding data duplication suggests that the proper place to store
assigned values is with the entity that assigned them.
It is possible, but not necessarily recommended, for a zone
maintainer to forego the renumbering support afforded by the
chaining of A6 records and to record entire IPv6 addresses within
one zone file.
6.2. Reverse Mapping Zones
Supposing that address space assignments in the TLAs with Format
Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in
zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then
the IP6.INT zone would include
$ORIGIN IP6.INT.
\[x234500/24] DNAME IP6.ALPHA-TLA.ORG.
\[x267800/24] DNAME IP6.BRAVO-TLA.ORG.
\[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY.
Eight trailing zero bits have been included in each TLA ID to
reflect the eight reserved bits in the current aggregatable global
unicast addresses format [AGGR].
6.2.1. The TLA level
ALPHA-TLA's assignments to network providers C, D and E are
reflected in the reverse data as follows.
\[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
\[xD/4].IP6.ALPHA-TLA.ORG. DNAME IP6.D.NET.
\[x0E/8].IP6.ALPHA-TLA.ORG. DNAME IP6.E.NET.
Expires April 19, 2000 Crawford et al. [Page 12]
Internet Draft IPv6 DNS October 14, 1999
6.2.2. The ISP level
The providers A through E carry the following delegation information
in their zone files.
\[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
\[x2DA/12].IP6.D.NET. DNAME IP6.A.NET.
\[xEB/8].IP6.E.NET. DNAME IP6.B.NET.
\[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
\[x22/8].IP6.B.NET. DNAME IP6.X.EXAMPLE.
Note that some domain names appear in the RDATA of more than one
DNAME record. In those cases, one zone is being used to map
multiple prefixes.
6.2.3. The Site Level
Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to-
name translations. This domain is now referenced by two different
DNAME records held by two different providers.
$ORIGIN IP6.X.EXAMPLE.
\[x0001/16] DNAME SUBNET-1
\[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE.
and so on.
SUBNET-1 need not have been named in a DNAME record; the subnet bits
could have been joined with the interface identifier. But if
subnets are treated alike in both the A6 records and in the reverse
zone, it will always be possible to keep the forward and reverse
definition data for each prefix in one zone.
6.3. Lookups
A DNS resolver looking for a hostname for the address
2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the
DNAME records shown above and would form new queries. Assuming that
it began the process knowing servers for IP6.INT, but that no server
it consulted provided recursion and none had other useful additional
information cached, the sequence of queried names and responses
would be (all with QCLASS=IN, QTYPE=PTR):
Expires April 19, 2000 Crawford et al. [Page 13]
Internet Draft IPv6 DNS October 14, 1999
To a server for IP6.INT:
QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.INT.
Answer:
\[x234500/24].IP6.INT. DNAME IP6.ALPHA-TLA.ORG.
To a server for IP6.ALPHA-TLA.ORG:
QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.
Answer:
\[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
To a server for IP6.C.NET.:
QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.
Answer:
\[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
To a server for IP6.A.NET.:
QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.
Answer:
\[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
To a server for IP6.X.EXAMPLE.:
QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE.
Answer:
\[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE.
\[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE.
All the DNAME (and NS) records acquired along the way can be cached
to expedite resolution of addresses topologically near to this
address. And if another global address of N.X.EXAMPLE were resolved
within the TTL of the final PTR record, that record would not have
to be fetched again.
6.4. Deployment Note
In the illustrations in section 6.1, hierarchically adjacent
entities, such as a network provider and a customer, must agree on a
DNS name which will own the definition of the delegated prefix(es).
One simple convention would be to use a bit-string label
representing exactly the bits which are assigned to the lower-level
entity by the higher. For example, "SUBSCRIBER-X" could be replaced
by "\[x11/8]". This would place the A6 record(s) defining the
Expires April 19, 2000 Crawford et al. [Page 14]
Internet Draft IPv6 DNS October 14, 1999
delegated prefix at exactly the same point in the DNS tree as the
DNAME record associated with that delegation. The cost of this
simplification is that the lower-level zone must update its upward-
pointing A6 records when it is renumbered. This cost may be found
quite acceptable in practice.
7. Transition from AAAA Records on coexistence with A Records
Administrators of zones which contain A6 records can easily
accommodate deployed resolvers which understand AAAA records but not
A6 records. Such administrators can do automatic generation of AAAA
records for all of a zone's names which own A6 records by a process
which mimics the resolution of a hostname to an IPv6 address (see
section 4.1.4). Attention must be paid to the TTL assigned to a
generated AAAA record, which MUST be no more than the minimum of the
TTLs of the A6 records that were used to form the IPv6 address in
that record. For full robustness, those A6 records which were in
different zones should be monitored for changes (in TTL or RDATA)
even when there are no changes to zone for which AAAA records are
being generated. If the zone is secure [DNSSEC], the generated AAAA
records SHOULD be signed along with the rest of the zone data.
A zone-specific heuristic MAY be used to avoid generation of AAAA
records for A6 records which record prefixes, although such
superfluous records would be relatively few in number and harmless.
Examples of such heuristics include omitting A6 records with a
prefix length less than the largest value found in the zone file, or
records with an address suffix field with a certain number of
trailing zero bits.
On the client side, when looking up and IPv6 address, the order of
A6 and AAAA queries MAY be configurable to be one of: A6, then AAAA;
AAAA, then A6; A6 only; or both in parallel. The default order (or
only order, if not configurable) MUST be to try A6 first, then AAAA.
If and when the AAAA becomes deprecated a new document will change
the default.
The guidelines and options for precedence between IPv4 and IPv6
addresses are specified in [TRANS]. All mentions of AAAA records in
that document are henceforth to be interpreted as meaning A6 and/or
AAAA records in the order specified in the previous paragraph.
8. Security Considerations
The signing authority [DNSSEC] for the A6 records which determine an
IPv6 address is distributed among several entities, reflecting the
Expires April 19, 2000 Crawford et al. [Page 15]
Internet Draft IPv6 DNS October 14, 1999
delegation path of the address space which that address occupies.
DNS Security is fully applicable to bit-string labels and DNAME
records. However, just as with IPv4's IN-ADDR.ARPA, authentication
of data in the reverse zones is not equivalent to authentication of
any forward data.
9. IANA Considerations
The A6 resource record has been assigned a Type value of 38.
10. Acknowledgments
The authors would like to thank the following persons for valuable
discussions and reviews: Mark Andrews, Rob Austein, Jim Bound,
Randy Bush, Brian Carpenter, David Conrad, Steve Deering, Francis
Dupont, Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob
Hinden, Bill Manning, Keith Moore, Thomas Narten, Erik Nordmark,
Mike O'Dell, Michael Patton and Ken Powell.
11. References
[AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable
Global Unicast Address Format". RFC 2374, July 1998.
[BITLBL] Crawford, M., "Binary Labels in the Domain Name System",
RFC 2673, August 1999.
[DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672,
August 1999.
[DNSIS] Mockapetris, P. V., "Domain names - implementation and
specification", RFC 1035, November 1987.
[DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System
Security Extensions", RFC 2535, March 1999.
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
[RENUM] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
1900, February 1996.
Expires April 19, 2000 Crawford et al. [Page 16]
Internet Draft IPv6 DNS October 14, 1999
Ferguson, P. and H. Berkowitz, "Network Renumbering Overview:
Why would I want it and what is it anyway?", RFC 2071, January
1997.
Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
Behaviour Today", RFC 2101, February 1997.
[TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 1933, April 1996.
12. Authors' Addresses
Matt Crawford Christian Huitema Susan Thomson
Fermilab Bellcore Bellcore
MS 368 MCC 1J236B MCC 1C259B
PO Box 500 445 South Street 445 South Street
Batavia, IL 60510 Morristown, NJ 07960 Morristown, NJ 07960
USA USA USA
+1 630 840-3461 +1 201 829-4266 +1 201 829-4514
crawdad@fnal.gov
huitema@research.telcordia.comset@research.telcordia.com
Expires April 19, 2000 Crawford et al. [Page 17]

869
doc/expired/draft-schroeppel-dnsind-ecc-00.txt Normal file
View file

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