upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-03-17 08:03:44 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

This commit was manufactured by cvs2git to create branch 'v9_3'.

Browse source
This commit is contained in:
cvs2git 2006-09-25 04:24:01 +00:00
commit 5dbe4ddabe
8 changed files with 13400 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

955
doc/rfc/rfc4367.txt Normal file
View file

@ -0,0 +1,955 @@
Network Working Group J. Rosenberg, Ed.
Request for Comments: 4367 IAB
Category: Informational February 2006
What's in a Name: False Assumptions about DNS Names
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Domain Name System (DNS) provides an essential service on the
Internet, mapping structured names to a variety of data, usually IP
addresses. These names appear in email addresses, Uniform Resource
Identifiers (URIs), and other application-layer identifiers that are
often rendered to human users. Because of this, there has been a
strong demand to acquire names that have significance to people,
through equivalence to registered trademarks, company names, types of
services, and so on. There is a danger in this trend; the humans and
automata that consume and use such names will associate specific
semantics with some names and thereby make assumptions about the
services that are, or should be, provided by the hosts associated
with the names. Those assumptions can often be false, resulting in a
variety of failure conditions. This document discusses this problem
in more detail and makes recommendations on how it can be avoided.
Rosenberg Informational [Page 1]
RFC 4367 Name Assumptions February 2006
Table of Contents
1. Introduction ....................................................2
2. Target Audience .................................................4
3. Modeling Usage of the DNS .......................................4
4. Possible Assumptions ............................................5
4.1. By the User ................................................5
4.2. By the Client ..............................................6
4.3. By the Server ..............................................7
5. Consequences of False Assumptions ...............................8
6. Reasons Why the Assumptions Can Be False ........................9
6.1. Evolution ..................................................9
6.2. Leakage ...................................................10
6.3. Sub-Delegation ............................................10
6.4. Mobility ..................................................12
6.5. Human Error ...............................................12
7. Recommendations ................................................12
8. A Note on RFC 2219 and RFC 2782 ................................13
9. Security Considerations ........................................14
10. Acknowledgements ..............................................14
11. IAB Members ...................................................14
12. Informative References ........................................15
1. Introduction
The Domain Name System (DNS) [1] provides an essential service on the
Internet, mapping structured names to a variety of different types of
data. Most often it is used to obtain the IP address of a host
associated with that name [2] [1] [3]. However, it can be used to
obtain other information, and proposals have been made for nearly
everything, including geographic information [4].
Domain names are most often used in identifiers used by application
protocols. The most well known include email addresses and URIs,
such as the HTTP URL [5], Real Time Streaming Protocol (RTSP) URL
[6], and SIP URI [7]. These identifiers are ubiquitous, appearing on
business cards, web pages, street signs, and so on. Because of this,
there has been a strong demand to acquire domain names that have
significance to people through equivalence to registered trademarks,
company names, types of services, and so on. Such identifiers serve
many business purposes, including extension of brand, advertising,
and so on.
People often make assumptions about the type of service that is or
should be provided by a host associated with that name, based on
their expectations and understanding of what the name implies. This,
in turn, triggers attempts by organizations to register domain names
based on that presumed user expectation. Examples of this are the
Rosenberg Informational [Page 2]
RFC 4367 Name Assumptions February 2006
various proposals for a Top-Level Domain (TLD) that could be
associated with adult content [8], the requests for creation of TLDs
associated with mobile devices and services, and even phishing
attacks.
When these assumptions are codified into the behavior of an
automaton, such as an application client or server, as a result of
implementor choice, management directive, or domain owner policy, the
overall system can fail in various ways. This document describes a
number of typical ways in which these assumptions can be codified,
how they can be wrong, the consequences of those mistakes, and the
recommended ways in which they can be avoided.
Section 4 describes some of the possible assumptions that clients,
servers, and people can make about a domain name. In this context,
an "assumption" is defined as any behavior that is expected when
accessing a service at a domain name, even though the behavior is not
explicitly codified in protocol specifications. Frequently, these
assumptions involve ignoring parts of a specification based on an
assumption that the client or server is deployed in an environment
that is more rigid than the specification allows. Section 5
overviews some of the consequences of these false assumptions.
Generally speaking, these consequences can include a variety of
different interoperability failures, user experience failures, and
system failures. Section 6 discusses why these assumptions can be
false from the very beginning or become false at some point in the
future. Most commonly, they become false because the environment
changes in unexpected ways over time, and what was a valid assumption
before, no longer is. Other times, the assumptions prove wrong
because they were based on the belief that a specific community of
clients and servers was participating, and an element outside of that
community began participating.
Section 7 then provides some recommendations. These recommendations
encapsulate some of the engineering mantras that have been at the
root of Internet protocol design for decades. These include:
Follow the specifications.
Use the capability negotiation techniques provided in the
protocols.
Be liberal in what you accept, and conservative in what you send.
[18]
Overall, automata should not change their behavior within a protocol
based on the domain name, or some component of the domain name, of
the host they are communicating with.
Rosenberg Informational [Page 3]
RFC 4367 Name Assumptions February 2006
2. Target Audience
This document has several audiences. Firstly, it is aimed at
implementors who ultimately develop the software that make the false
assumptions that are the subject of this document. The
recommendations described here are meant to reinforce the engineering
guidelines that are often understood by implementors, but frequently
forgotten as deadlines near and pressures mount.
The document is also aimed at technology managers, who often develop
the requirements that lead to these false assumptions. For them,
this document serves as a vehicle for emphasizing the importance of
not taking shortcuts in the scope of applicability of a project.
Finally, this document is aimed at domain name policy makers and
administrators. For them, it points out the perils in establishing
domain policies that get codified into the operation of applications
running within that domain.
3. Modeling Usage of the DNS
+--------+
| |
| |
| DNS |
|Service |
| |
+--------+
^ |
| |
| |
| |
/--\ | |
| | | V
| | +--------+ +--------+
\--/ | | | |
| | | | |
---+--- | Client |-------------------->| Server |
| | | | |
| | | | |
/\ +--------+ +--------+
/ \
/ \
User
Figure 1
Rosenberg Informational [Page 4]
RFC 4367 Name Assumptions February 2006
Figure 1 shows a simple conceptual model of how the DNS is used by
applications. A user of the application obtains an identifier for
particular content or service it wishes to obtain. This identifier
is often a URL or URI that contains a domain name. The user enters
this identifier into its client application (for example, by typing
in the URL in a web browser window). The client is the automaton (a
software and/or hardware system) that contacts a server for that
application in order to provide service to the user. To do that, it
contacts a DNS server to resolve the domain name in the identifier to
an IP address. It then contacts the server at that IP address. This
simple model applies to application protocols such as HTTP [5], SIP
[7], RTSP [6], and SMTP [9].
>From this model, it is clear that three entities in the system can
potentially make false assumptions about the service provided by the
server. The human user may form expectations relating to the content
of the service based on a parsing of the host name from which the
content originated. The server might assume that the client
connecting to it supports protocols that it does not, can process
content that it cannot, or has capabilities that it does not.
Similarly, the client might assume that the server supports
protocols, content, or capabilities that it does not. Furthermore,
applications can potentially contain a multiplicity of humans,
clients, and servers, all of which can independently make these false
assumptions.
4. Possible Assumptions
For each of the three elements, there are many types of false
assumptions that can be made.
4.1. By the User
The set of possible assumptions here is nearly boundless. Users
might assume that an HTTP URL that looks like a company name maps to
a server run by that company. They might assume that an email from a
email address in the .gov TLD is actually from a government employee.
They might assume that the content obtained from a web server within
a TLD labeled as containing adult materials (for example, .sex)
actually contains adult content [8]. These assumptions are
unavoidable, may all be false, and are not the focus of this
document.
Rosenberg Informational [Page 5]
RFC 4367 Name Assumptions February 2006
4.2. By the Client
Even though the client is an automaton, it can make some of the same
assumptions that a human user might make. For example, many clients
assume that any host with a hostname that begins with "www" is a web
server, even though this assumption may be false.
In addition, the client concerns itself with the protocols needed to
communicate with the server. As a result, it might make assumptions
about the operation of the protocols for communicating with the
server. These assumptions manifest themselves in an implementation
when a standardized protocol negotiation technique defined by the
protocol is ignored, and instead, some kind of rule is coded into the
software that comes to its own conclusion about what the negotiation
would have determined. The result is often a loss of
interoperability, degradation in reliability, and worsening of user
experience.
Authentication Algorithm: Though a protocol might support a
multiplicity of authentication techniques, a client might assume
that a server always supports one that is only optional according
to the protocol. For example, a SIP client contacting a SIP
server in a domain that is apparently used to identify mobile
devices (for example, www.example.cellular) might assume that the
server supports the optional Authentication and Key Agreement
(AKA) digest technique [10], just because of the domain name that
was used to access the server. As another example, a web client
might assume that a server with the name https.example.com
supports HTTP over Transport Layer Security (TLS) [16].
Data Formats: Though a protocol might allow a multiplicity of data
formats to be sent from the server to the client, the client might
assume a specific one, rather than using the content labeling and
negotiation capabilities of the underlying protocol. For example,
an RTSP client might assume that all audio content delivered to it
from media.example.cellular uses a low-bandwidth codec. As
another example, a mail client might assume that the contents of
messages it retrieves from a mail server at mail.example.cellular
are always text, instead of checking the MIME headers [11] in the
message in order to determine the actual content type.
Protocol Extensions: A client may attempt an operation on the server
that requires the server to support an optional protocol
extension. However, rather than implementing the necessary
fallback logic, the client may falsely assume that the extension
is supported. As an example, a SIP client that requires reliable
provisional responses to its request (RFC 3262 [17]) might assume
that this extension is supported on servers in the domain
Rosenberg Informational [Page 6]
RFC 4367 Name Assumptions February 2006
sip.example.telecom. Furthermore, the client would not implement
the fallback behavior defined in RFC 3262, since it would assume
that all servers it will communicate with are in this domain and
that all therefore support this extension. However, if the
assumptions prove wrong, the client is unable to make any phone
calls.
Languages: A client may support facilities for processing text
content differently depending on the language of the text. Rather
than determining the language from markers in the message from the
server, the client might assume a language based on the domain
name. This assumption can easily be wrong. For example, a client
might assume that any text in a web page retrieved from a server
within the .de country code TLD (ccTLD) is in German, and attempt
a translation to Finnish. This would fail dramatically if the
text was actually in French. Unfortunately, this client behavior
is sometimes exhibited because the server has not properly labeled
the language of the content in the first place, often because the
server assumed such a labeling was not needed. This is an example
of how these false assumptions can create vicious cycles.
4.3. By the Server
The server, like the client, is an automaton. Let us consider one
servicing a particular domain -- www.company.cellular, for example.
It might assume that all clients connecting to this domain support
particular capabilities, rather than using the underlying protocol to
make this determination. Some examples include:
Authentication Algorithm: The server can assume that a client
supports a particular, optional, authentication technique, and it
therefore does not support the mandatory one.
Language: The server can serve content in a particular language,
based on an assumption that clients accessing the domain speak a
particular language, or based on an assumption that clients coming
from a particular IP address speak a certain language.
Data Formats: The server can assume that the client supports a
particular set of MIME types and is only capable of sending ones
within that set. When it generates content in a protocol
response, it ignores any content negotiation headers that were
present in the request. For example, a web server might ignore
the Accept HTTP header field and send a specific image format.
Rosenberg Informational [Page 7]
RFC 4367 Name Assumptions February 2006
Protocol Extensions: The server might assume that the client supports
a particular optional protocol extension, and so it does not
support the fallback behavior necessary in the case where the
client does not.
Client Characteristics: The server might assume certain things about
the physical characteristics of its clients, such as memory
footprint, processing power, screen sizes, screen colors, pointing
devices, and so on. Based on these assumptions, it might choose
specific behaviors when processing a request. For example, a web
server might always assume that clients connect through cell
phones, and therefore return content that lacks images and is
tuned for such devices.
5. Consequences of False Assumptions
There are numerous negative outcomes that can arise from the various
false assumptions that users, servers, and clients can make. These
include:
Interoperability Failure: In these cases, the client or server
assumed some kind of protocol operation, and this assumption was
wrong. The result is that the two are unable to communicate, and
the user receives some kind of an error. This represents a total
interoperability failure, manifesting itself as a lack of service
to users of the system. Unfortunately, this kind of failure
persists. Repeated attempts over time by the client to access the
service will fail. Only a change in the server or client software
can fix this problem.
System Failure: In these cases, the client or server misinterpreted a
protocol operation, and this misinterpretation was serious enough
to uncover a bug in the implementation. The bug causes a system
crash or some kind of outage, either transient or permanent (until
user reset). If this failure occurs in a server, not only will
the connecting client lose service, but other clients attempting
to connect will not get service. As an example, if a web server
assumes that content passed to it from a client (created, for
example, by a digital camera) is of a particular content type, and
it always passes image content to a codec for decompression prior
to storage, the codec might crash when it unexpectedly receives an
image compressed in a different format. Of course, it might crash
even if the Content-Type was correct, but the compressed bitstream
was invalid. False assumptions merely introduce additional
failure cases.
Rosenberg Informational [Page 8]
RFC 4367 Name Assumptions February 2006
Poor User Experience: In these cases, the client and server
communicate, but the user receives a diminished user experience.
For example, if a client on a PC connects to a web site that
provides content for mobile devices, the content may be
underwhelming when viewed on the PC. Or, a client accessing a
streaming media service may receive content of very low bitrate,
even though the client supported better codecs. Indeed, if a user
wishes to access content from both a cellular device and a PC
using a shared address book (that is, an address book shared
across multiple devices), the user would need two entries in that
address book, and would need to use the right one from the right
device. This is a poor user experience.
Degraded Security: In these cases, a weaker security mechanism is
used than the one that ought to have been used. As an example, a
server in a domain might assume that it is only contacted by
clients with a limited set of authentication algorithms, even
though the clients have been recently upgraded to support a
stronger set.
6. Reasons Why the Assumptions Can Be False
Assumptions made by clients and servers about the operation of
protocols when contacting a particular domain are brittle, and can be
wrong for many reasons. On the server side, many of the assumptions
are based on the notion that a domain name will only be given to, or
used by, a restricted set of clients. If the holder of the domain
name assumes something about those clients, and can assume that only
those clients use the domain name, then it can configure or program
the server to operate specifically for those clients. Both parts of
this assumption can be wrong, as discussed in more detail below.
On the client side, the notion is similar, being based on the
assumption that a server within a particular domain will provide a
specific type of service. Sub-delegation and evolution, both
discussed below, can make these assumptions wrong.
6.1. Evolution
The Internet and the devices that access it are constantly evolving,
often at a rapid pace. Unfortunately, there is a tendency to build
for the here and now, and then worry about the future at a later
time. Many of the assumptions above are predicated on
characteristics of today's clients and servers. Support for specific
protocols, authentication techniques, or content are based on today's
standards and today's devices. Even though they may, for the most
part, be true, they won't always be. An excellent example is mobile
devices. A server servicing a domain accessed by mobile devices
Rosenberg Informational [Page 9]
RFC 4367 Name Assumptions February 2006
might try to make assumptions about the protocols, protocol
extensions, security mechanisms, screen sizes, or processor power of
such devices. However, all of these characteristics can and will
change over time.
When they do change, the change is usually evolutionary. The result
is that the assumptions remain valid in some cases, but not in
others. It is difficult to fix such systems, since it requires the
server to detect what type of client is connecting, and what its
capabilities are. Unless the system is built and deployed with these
capability negotiation techniques built in to begin with, such
detection can be extremely difficult. In fact, fixing it will often
require the addition of such capability negotiation features that, if
they had been in place and used to begin with, would have avoided the
problem altogether.
6.2. Leakage
Servers also make assumptions because of the belief that they will
only be accessed by specific clients, and in particular, those that
are configured or provisioned to use the domain name. In essence,
there is an assumption of community -- that a specific community
knows and uses the domain name, while others outside of the community
do not.
The problem is that this notion of community is a false one. The
Internet is global. The DNS is global. There is no technical
barrier that separates those inside of the community from those
outside. The ease with which information propagates across the
Internet makes it extremely likely that such domain names will
eventually find their way into clients outside of the presumed
community. The ubiquitous presence of domain names in various URI
formats, coupled with the ease of conveyance of URIs, makes such
leakage merely a matter of time. Furthermore, since the DNS is
global, and since it can only have one root [12], it becomes possible
for clients outside of the community to search and find and use such
"special" domain names.
Indeed, this leakage is a strength of the Internet architecture, not
a weakness. It enables global access to services from any client
with a connection to the Internet. That, in turn, allows for rapid
growth in the number of customers for any particular service.
6.3. Sub-Delegation
Clients and users make assumptions about domains because of the
notion that there is some kind of centralized control that can
enforce those assumptions. However, the DNS is not centralized; it
Rosenberg Informational [Page 10]
RFC 4367 Name Assumptions February 2006
is distributed. If a domain doesn't delegate its sub-domains and has
its records within a single zone, it is possible to maintain a
centralized policy about operation of its domain. However, once a
domain gets sufficiently large that the domain administrators begin
to delegate sub-domains to other authorities, it becomes increasingly
difficult to maintain any kind of central control on the nature of
the service provided in each sub-domain.
Similarly, the usage of domain names with human semantic connotation
tends to lead to a registration of multiple domains in which a
particular service is to run. As an example, a service provider with
the name "example" might register and set up its services in
"example.com", "example.net", and generally example.foo for each foo
that is a valid TLD. This, like sub-delegation, results in a growth
in the number of domains over which it is difficult to maintain
centralized control.
Not that it is not possible, since there are many examples of
successful administration of policies across sub-domains many levels
deep. However, it takes an increasing amount of effort to ensure
this result, as it requires human intervention and the creation of
process and procedure. Automated validation of adherence to policies
is very difficult to do, as there is no way to automatically verify
many policies that might be put into place.
A less costly process for providing centralized management of
policies is to just hope that any centralized policies are being
followed, and then wait for complaints or perform random audits.
Those approaches have many problems.
The invalidation of assumptions due to sub-delegation is discussed in
further detail in Section 4.1.3 of [8] and in Section 3.3 of [20].
As a result of the fragility of policy continuity across sub-
delegations, if a client or user assumes some kind of property
associated with a TLD (such as ".wifi"), it becomes increasingly more
likely with the number of sub-domains that this property will not
exist in a server identified by a particular name. For example, in
"store.chain.company.provider.wifi", there may be four levels of
delegation from ".wifi", making it quite likely that, unless the
holder of ".wifi" is working diligently, the properties that the
holder of ".wifi" wishes to enforce are not present. These
properties may not be present due to human error or due to a willful
decision not to adhere to them.
Rosenberg Informational [Page 11]
RFC 4367 Name Assumptions February 2006
6.4. Mobility
One of the primary value propositions of a hostname as an identifier
is its persistence. A client can change IP addresses, yet still
retain a persistent identifier used by other hosts to reach it.
Because their value derives from their persistence, hostnames tend to
move with a host not just as it changes IP addresses, but as it
changes access network providers and technologies. For this reason,
assumptions made about a host based on the presumed access network
corresponding to that hostname tend to be wrong over time. As an
example, a PC might normally be connected to its broadband provider,
and through dynamic DNS have a hostname within the domain of that
provider. However, one cannot assume that any host within that
network has access over a broadband link; the user could connect
their PC over a low-bandwidth wireless access network and still
retain its domain name.
6.5. Human Error
Of course, human error can be the source of errors in any system, and
the same is true here. There are many examples relevant to the
problem under discussion.
A client implementation may make the assumption that, just because a
DNS SRV record exists for a particular protocol in a particular
domain, indicating that the service is available on some port, that
the service is, in fact, running there. This assumption could be
wrong because the SRV records haven't been updated by the system
administrators to reflect the services currently running. As another
example, a client might assume that a particular domain policy
applies to all sub-domains. However, a system administrator might
have omitted to apply the policy to servers running in one of those
sub-domains.
7. Recommendations
Based on these problems, the clear conclusion is that clients,
servers, and users should not make assumptions on the nature of the
service provided to, or by, a domain. More specifically, however,
the following can be said:
Follow the specifications: When specifications define mandatory
baseline procedures and formats, those should be implemented and
supported, even if the expectation is that optional procedures
will most often be used. For example, if a specification mandates
a particular baseline authentication technique, but allows others
to be negotiated and used, implementations need to implement the
baseline authentication algorithm even if the other ones are used
Rosenberg Informational [Page 12]
RFC 4367 Name Assumptions February 2006
most of the time. Put more simply, the behavior of the protocol
machinery should never change based on the domain name of the
host.
Use capability negotiation: Many protocols are engineered with
capability negotiation mechanisms. For example, a content
negotiation framework has been defined for protocols using MIME
content [13] [14] [15]. SIP allows for clients to negotiate the
media types used in the multimedia session, as well as protocol
parameters. HTTP allows for clients to negotiate the media types
returned in requests for content. When such features are
available in a protocol, client and servers should make use of
them rather than making assumptions about supported capabilities.
A corollary is that protocol designers should include such
mechanisms when evolution is expected in the usage of the
protocol.
"Be liberal in what you accept, and conservative in what you send"
[18]: This axiom of Internet protocol design is applicable here
as well. Implementations should be prepared for the full breadth
of what a protocol allows another entity to send, rather than be
limiting in what it is willing to receive.
To summarize -- there is never a need to make assumptions. Rather
than doing so, utilize the specifications and the negotiation
capabilities they provide, and the overall system will be robust and
interoperable.
8. A Note on RFC 2219 and RFC 2782
Based on the definition of an assumption given here, the behavior
hinted at by records in the DNS also represents an assumption. RFC
2219 [19] defines well-known aliases that can be used to construct
domain names for reaching various well-known services in a domain.
This approach was later followed by the definition of a new resource
record, the SRV record [2], which specifies that a particular service
is running on a server in a domain. Although both of these
mechanisms are useful as a hint that a particular service is running
in a domain, both of them represent assumptions that may be false.
However, they differ in the set of reasons why those assumptions
might be false.
A client that assumes that "ftp.example.com" is an FTP server may be
wrong because the presumed naming convention in RFC 2219 was not
known by, or not followed by, the owner of domain.com. With RFC
2782, an SRV record for a particular service would be present only by
explicit choice of the domain administrator, and thus a client that
Rosenberg Informational [Page 13]
RFC 4367 Name Assumptions February 2006
assumes that the corresponding host provides this service would be
wrong only because of human error in configuration. In this case,
the assumption is less likely to be wrong, but it certainly can be.
The only way to determine with certainty that a service is running on
a host is to initiate a connection to the port for that service, and
check. Implementations need to be careful not to codify any
behaviors that cause failures should the information provided in the
record actually be false. This borders on common sense for robust
implementations, but it is valuable to raise this point explicitly.
9. Security Considerations
One of the assumptions that can be made by clients or servers is the
availability and usage (or lack thereof) of certain security
protocols and algorithms. For example, a client accessing a service
in a particular domain might assume a specific authentication
algorithm or hash function in the application protocol. It is
possible that, over time, weaknesses are found in such a technique,
requiring usage of a different mechanism. Similarly, a system might
start with an insecure mechanism, and then decide later on to use a
secure one. In either case, assumptions made on security properties
can result in interoperability failures, or worse yet, providing
service in an insecure way, even though the client asked for, and
thought it would get, secure service. These kinds of assumptions are
fundamentally unsound even if the records themselves are secured with
DNSSEC.
10. Acknowledgements
The IAB would like to thank John Klensin, Keith Moore and Peter Koch
for their comments.
11. IAB Members
Internet Architecture Board members at the time of writing of this
document are:
Bernard Aboba
Loa Andersson
Brian Carpenter
Leslie Daigle
Patrik Faltstrom
Rosenberg Informational [Page 14]
RFC 4367 Name Assumptions February 2006
Bob Hinden
Kurtis Lindqvist
David Meyer
Pekka Nikander
Eric Rescorla
Pete Resnick
Jonathan Rosenberg
12. Informative References
[1] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[2] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403,
October 2002.
[4] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means
for Expressing Location Information in the Domain Name System",
RFC 1876, January 1996.
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[6] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[8] Eastlake, D., ".sex Considered Dangerous", RFC 3675,
February 2004.
[9] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
Rosenberg Informational [Page 15]
RFC 4367 Name Assumptions February 2006
[10] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
Protocol (HTTP) Digest Authentication Using Authentication and
Key Agreement (AKA)", RFC 3310, September 2002.
[11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[12] Internet Architecture Board, "IAB Technical Comment on the
Unique DNS Root", RFC 2826, May 2000.
[13] Klyne, G., "Indicating Media Features for MIME Content",
RFC 2912, September 2000.
[14] Klyne, G., "A Syntax for Describing Media Feature Sets",
RFC 2533, March 1999.
[15] Klyne, G., "Protocol-independent Content Negotiation
Framework", RFC 2703, September 1999.
[16] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[17] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262,
June 2002.
[18] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[19] Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
Services", BCP 17, RFC 2219, October 1997.
[20] Faltstrom, P., "Design Choices When Expanding DNS", Work in
Progress, June 2005.
Author's Address
Jonathan Rosenberg, Editor
IAB
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Rosenberg Informational [Page 16]
RFC 4367 Name Assumptions February 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Rosenberg Informational [Page 17]

955
doc/rfc/rfc4398.txt Normal file
View file

@ -0,0 +1,955 @@
Network Working Group S. Josefsson
Request for Comments: 4398 March 2006
Obsoletes: 2538
Category: Standards Track
Storing Certificates in the Domain Name System (DNS)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Cryptographic public keys are frequently published, and their
authenticity is demonstrated by certificates. A CERT resource record
(RR) is defined so that such certificates and related certificate
revocation lists can be stored in the Domain Name System (DNS).
This document obsoletes RFC 2538.
Josefsson Standards Track [Page 1]
RFC 4398 Storing Certificates in the DNS February 2006
Table of Contents
1. Introduction ....................................................3
2. The CERT Resource Record ........................................3
2.1. Certificate Type Values ....................................4
2.2. Text Representation of CERT RRs ............................6
2.3. X.509 OIDs .................................................6
3. Appropriate Owner Names for CERT RRs ............................7
3.1. Content-Based X.509 CERT RR Names ..........................8
3.2. Purpose-Based X.509 CERT RR Names ..........................9
3.3. Content-Based OpenPGP CERT RR Names ........................9
3.4. Purpose-Based OpenPGP CERT RR Names .......................10
3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX ...........10
4. Performance Considerations .....................................11
5. Contributors ...................................................11
6. Acknowledgements ...............................................11
7. Security Considerations ........................................12
8. IANA Considerations ............................................12
9. Changes since RFC 2538 .........................................13
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................15
Appendix A. Copying Conditions ...................................16
Josefsson Standards Track [Page 2]
RFC 4398 Storing Certificates in the DNS February 2006
1. Introduction
Public keys are frequently published in the form of a certificate,
and their authenticity is commonly demonstrated by certificates and
related certificate revocation lists (CRLs). A certificate is a
binding, through a cryptographic digital signature, of a public key,
a validity interval and/or conditions, and identity, authorization,
or other information. A certificate revocation list is a list of
certificates that are revoked, and of incidental information, all
signed by the signer (issuer) of the revoked certificates. Examples
are X.509 certificates/CRLs in the X.500 directory system or OpenPGP
certificates/revocations used by OpenPGP software.
Section 2 specifies a CERT resource record (RR) for the storage of
certificates in the Domain Name System [1] [2].
Section 3 discusses appropriate owner names for CERT RRs.
Sections 4, 7, and 8 cover performance, security, and IANA
considerations, respectively.
Section 9 explains the changes in this document compared to RFC 2538.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [3].
2. The CERT Resource Record
The CERT resource record (RR) has the structure given below. Its RR
type code is 37.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | key tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| algorithm | /
+---------------+ certificate or CRL /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
The type field is the certificate type as defined in Section 2.1
below.
The key tag field is the 16-bit value computed for the key embedded
in the certificate, using the RRSIG Key Tag algorithm described in
Appendix B of [12]. This field is used as an efficiency measure to
Josefsson Standards Track [Page 3]
RFC 4398 Storing Certificates in the DNS February 2006
pick which CERT RRs may be applicable to a particular key. The key
tag can be calculated for the key in question, and then only CERT RRs
with the same key tag need to be examined. Note that two different
keys can have the same key tag. However, the key MUST be transformed
to the format it would have as the public key portion of a DNSKEY RR
before the key tag is computed. This is only possible if the key is
applicable to an algorithm and complies to limits (such as key size)
defined for DNS security. If it is not, the algorithm field MUST be
zero and the tag field is meaningless and SHOULD be zero.
The algorithm field has the same meaning as the algorithm field in
DNSKEY and RRSIG RRs [12], except that a zero algorithm field
indicates that the algorithm is unknown to a secure DNS, which may
simply be the result of the algorithm not having been standardized
for DNSSEC [11].
2.1. Certificate Type Values
The following values are defined or reserved:
Value Mnemonic Certificate Type
----- -------- ----------------
0 Reserved
1 PKIX X.509 as per PKIX
2 SPKI SPKI certificate
3 PGP OpenPGP packet
4 IPKIX The URL of an X.509 data object
5 ISPKI The URL of an SPKI certificate
6 IPGP The fingerprint and URL of an OpenPGP packet
7 ACPKIX Attribute Certificate
8 IACPKIX The URL of an Attribute Certificate
9-252 Available for IANA assignment
253 URI URI private
254 OID OID private
255 Reserved
256-65279 Available for IANA assignment
65280-65534 Experimental
65535 Reserved
These values represent the initial content of the IANA registry; see
Section 8.
The PKIX type is reserved to indicate an X.509 certificate conforming
to the profile defined by the IETF PKIX working group [8]. The
certificate section will start with a one-octet unsigned OID length
and then an X.500 OID indicating the nature of the remainder of the
Josefsson Standards Track [Page 4]
RFC 4398 Storing Certificates in the DNS February 2006
certificate section (see Section 2.3, below). (NOTE: X.509
certificates do not include their X.500 directory-type-designating
OID as a prefix.)
The SPKI and ISPKI types are reserved to indicate the SPKI
certificate format [15], for use when the SPKI documents are moved
from experimental status. The format for these two CERT RR types
will need to be specified later.
The PGP type indicates an OpenPGP packet as described in [5] and its
extensions and successors. This is used to transfer public key
material and revocation signatures. The data is binary and MUST NOT
be encoded into an ASCII armor. An implementation SHOULD process
transferable public keys as described in Section 10.1 of [5], but it
MAY handle additional OpenPGP packets.
The ACPKIX type indicates an Attribute Certificate format [9].
The IPKIX and IACPKIX types indicate a URL that will serve the
content that would have been in the "certificate, CRL, or URL" field
of the corresponding type (PKIX or ACPKIX, respectively).
The IPGP type contains both an OpenPGP fingerprint for the key in
question, as well as a URL. The certificate portion of the IPGP CERT
RR is defined as a one-octet fingerprint length, followed by the
OpenPGP fingerprint, followed by the URL. The OpenPGP fingerprint is
calculated as defined in RFC 2440 [5]. A zero-length fingerprint or
a zero-length URL are legal, and indicate URL-only IPGP data or
fingerprint-only IPGP data, respectively. A zero-length fingerprint
and a zero-length URL are meaningless and invalid.
The IPKIX, ISPKI, IPGP, and IACPKIX types are known as "indirect".
These types MUST be used when the content is too large to fit in the
CERT RR and MAY be used at the implementer's discretion. They SHOULD
NOT be used where the DNS message is 512 octets or smaller and could
thus be expected to fit a UDP packet.
The URI private type indicates a certificate format defined by an
absolute URI. The certificate portion of the CERT RR MUST begin with
a null-terminated URI [10], and the data after the null is the
private format certificate itself. The URI SHOULD be such that a
retrieval from it will lead to documentation on the format of the
certificate. Recognition of private certificate types need not be
based on URI equality but can use various forms of pattern matching
so that, for example, subtype or version information can also be
encoded into the URI.
Josefsson Standards Track [Page 5]
RFC 4398 Storing Certificates in the DNS February 2006
The OID private type indicates a private format certificate specified
by an ISO OID prefix. The certificate section will start with a
one-octet unsigned OID length and then a BER-encoded OID indicating
the nature of the remainder of the certificate section. This can be
an X.509 certificate format or some other format. X.509 certificates
that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
type, not the OID private type. Recognition of private certificate
types need not be based on OID equality but can use various forms of
pattern matching such as OID prefix.
2.2. Text Representation of CERT RRs
The RDATA portion of a CERT RR has the type field as an unsigned
decimal integer or as a mnemonic symbol as listed in Section 2.1,
above.
The key tag field is represented as an unsigned decimal integer.
The algorithm field is represented as an unsigned decimal integer or
a mnemonic symbol as listed in [12].
The certificate/CRL portion is represented in base 64 [16] and may be
divided into any number of white-space-separated substrings, down to
single base-64 digits, which are concatenated to obtain the full
signature. These substrings can span lines using the standard
parenthesis.
Note that the certificate/CRL portion may have internal sub-fields,
but these do not appear in the master file representation. For
example, with type 254, there will be an OID size, an OID, and then
the certificate/CRL proper. However, only a single logical base-64
string will appear in the text representation.
2.3. X.509 OIDs
OIDs have been defined in connection with the X.500 directory for
user certificates, certification authority certificates, revocations
of certification authority, and revocations of user certificates.
The following table lists the OIDs, their BER encoding, and their
length-prefixed hex format for use in CERT RRs:
Josefsson Standards Track [Page 6]
RFC 4398 Storing Certificates in the DNS February 2006
id-at-userCertificate
= { joint-iso-ccitt(2) ds(5) at(4) 36 }
== 0x 03 55 04 24
id-at-cACertificate
= { joint-iso-ccitt(2) ds(5) at(4) 37 }
== 0x 03 55 04 25
id-at-authorityRevocationList
= { joint-iso-ccitt(2) ds(5) at(4) 38 }
== 0x 03 55 04 26
id-at-certificateRevocationList
= { joint-iso-ccitt(2) ds(5) at(4) 39 }
== 0x 03 55 04 27
3. Appropriate Owner Names for CERT RRs
It is recommended that certificate CERT RRs be stored under a domain
name related to their subject, i.e., the name of the entity intended
to control the private key corresponding to the public key being
certified. It is recommended that certificate revocation list CERT
RRs be stored under a domain name related to their issuer.
Following some of the guidelines below may result in DNS names with
characters that require DNS quoting as per Section 5.1 of RFC 1035
[2].
The choice of name under which CERT RRs are stored is important to
clients that perform CERT queries. In some situations, the clients
may not know all information about the CERT RR object it wishes to
retrieve. For example, a client may not know the subject name of an
X.509 certificate, or the email address of the owner of an OpenPGP
key. Further, the client might only know the hostname of a service
that uses X.509 certificates or the Key ID of an OpenPGP key.
Therefore, two owner name guidelines are defined: content-based owner
names and purpose-based owner names. A content-based owner name is
derived from the content of the CERT RR data; for example, the
Subject field in an X.509 certificate or the User ID field in OpenPGP
keys. A purpose-based owner name is a name that a client retrieving
CERT RRs ought to know already; for example, the host name of an
X.509 protected service or the Key ID of an OpenPGP key. The
content-based and purpose-based owner name may be the same; for
example, when a client looks up a key based on the From: address of
an incoming email.
Implementations SHOULD use the purpose-based owner name guidelines
described in this document and MAY use CNAME RRs at content-based
owner names (or other names), pointing to the purpose-based owner
name.
Josefsson Standards Track [Page 7]
RFC 4398 Storing Certificates in the DNS February 2006
Note that this section describes an application-based mapping from
the name space used in a certificate to the name space used by DNS.
The DNS does not infer any relationship amongst CERT resource records
based on similarities or differences of the DNS owner name(s) of CERT
resource records. For example, if multiple labels are used when
mapping from a CERT identifier to a domain name, then care must be
taken in understanding wildcard record synthesis.
3.1. Content-Based X.509 CERT RR Names
Some X.509 versions, such as the PKIX profile of X.509 [8], permit
multiple names to be associated with subjects and issuers under
"Subject Alternative Name" and "Issuer Alternative Name". For
example, the PKIX profile has such Alternate Names with an ASN.1
specification as follows:
GeneralName ::= CHOICE {
otherName [0] OtherName,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER }
The recommended locations of CERT storage are as follows, in priority
order:
1. If a domain name is included in the identification in the
certificate or CRL, that ought to be used.
2. If a domain name is not included but an IP address is included,
then the translation of that IP address into the appropriate
inverse domain name ought to be used.
3. If neither of the above is used, but a URI containing a domain
name is present, that domain name ought to be used.
4. If none of the above is included but a character string name is
included, then it ought to be treated as described below for
OpenPGP names.
5. If none of the above apply, then the distinguished name (DN)
ought to be mapped into a domain name as specified in [4].
Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/
DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)
string "John (the Man) Doe", (b) domain name john-doe.com, and (c)
URI <https://www.secure.john-doe.com:8080/>. The storage locations
recommended, in priority order, would be
Josefsson Standards Track [Page 8]
RFC 4398 Storing Certificates in the DNS February 2006
1. john-doe.com,
2. www.secure.john-doe.com, and
3. Doe.com.xy.
Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
(c) string "James Hacker <hacker@mail.widget.foo.example>". The
storage locations recommended, in priority order, would be
1. widget.foo.example,
2. 201.13.251.10.in-addr.arpa, and
3. hacker.mail.widget.foo.example.
3.2. Purpose-Based X.509 CERT RR Names
Due to the difficulty for clients that do not already possess a
certificate to reconstruct the content-based owner name,
purpose-based owner names are recommended in this section.
Recommendations for purpose-based owner names vary per scenario. The
following table summarizes the purpose-based X.509 CERT RR owner name
guidelines for use with S/MIME [17], SSL/TLS [13], and IPsec [14]:
Scenario Owner name
------------------ ----------------------------------------------
S/MIME Certificate Standard translation of an RFC 2822 email
address. Example: An S/MIME certificate for
"postmaster@example.org" will use a standard
hostname translation of the owner name,
"postmaster.example.org".
TLS Certificate Hostname of the TLS server.
IPsec Certificate Hostname of the IPsec machine and/or, for IPv4
or IPv6 addresses, the fully qualified domain
name in the appropriate reverse domain.
An alternate approach for IPsec is to store raw public keys [18].
3.3. Content-Based OpenPGP CERT RR Names
OpenPGP signed keys (certificates) use a general character string
User ID [5]. However, it is recommended by OpenPGP that such names
include the RFC 2822 [7] email address of the party, as in "Leslie
Example <Leslie@host.example>". If such a format is used, the CERT
ought to be under the standard translation of the email address into
Josefsson Standards Track [Page 9]
RFC 4398 Storing Certificates in the DNS February 2006
a domain name, which would be leslie.host.example in this case. If
no RFC 2822 name can be extracted from the string name, no specific
domain name is recommended.
If a user has more than one email address, the CNAME type can be used
to reduce the amount of data stored in the DNS. For example:
$ORIGIN example.org.
smith IN CERT PGP 0 0 <OpenPGP binary>
john.smith IN CNAME smith
js IN CNAME smith
3.4. Purpose-Based OpenPGP CERT RR Names
Applications that receive an OpenPGP packet containing encrypted or
signed data but do not know the email address of the sender will have
difficulties constructing the correct owner name and cannot use the
content-based owner name guidelines. However, these clients commonly
know the key fingerprint or the Key ID. The key ID is found in
OpenPGP packets, and the key fingerprint is commonly found in
auxiliary data that may be available. In this case, use of an owner
name identical to the key fingerprint and the key ID expressed in
hexadecimal [16] is recommended. For example:
$ORIGIN example.org.
0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
F835EDA21E94B565716F IN CERT PGP ...
B565716F IN CERT PGP ...
If the same key material is stored for several owner names, the use
of CNAME may help avoid data duplication. Note that CNAME is not
always applicable, because it maps one owner name to the other for
all purposes, which may be sub-optimal when two keys with the same
Key ID are stored.
3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX
These types are stored under the same owner names, both purpose- and
content-based, as the PKIX, SPKI, PGP, and ACPKIX types.
Josefsson Standards Track [Page 10]
RFC 4398 Storing Certificates in the DNS February 2006
4. Performance Considerations
The Domain Name System (DNS) protocol was designed for small
transfers, typically below 512 octets. While larger transfers will
perform correctly and work is underway to make larger transfers more
efficient, it is still advisable at this time that every reasonable
effort be made to minimize the size of certificates stored within the
DNS. Steps that can be taken may include using the fewest possible
optional or extension fields and using short field values for
necessary variable-length fields.
The RDATA field in the DNS protocol may only hold data of size 65535
octets (64kb) or less. This means that each CERT RR MUST NOT contain
more than 64kb of payload, even if the corresponding certificate or
certificate revocation list is larger. This document addresses this
by defining "indirect" data types for each normal type.
Deploying CERT RRs to support digitally signed email changes the
access patterns of DNS lookups from per-domain to per-user. If
digitally signed email and a key/certificate lookup based on CERT RRs
are deployed on a wide scale, this may lead to an increased DNS load,
with potential performance and cache effectiveness consequences.
Whether or not this load increase will be noticeable is not known.
5. Contributors
The majority of this document is copied verbatim from RFC 2538, by
Donald Eastlake 3rd and Olafur Gudmundsson.
6. Acknowledgements
Thanks to David Shaw and Michael Graff for their contributions to
earlier works that motivated, and served as inspiration for, this
document.
This document was improved by suggestions and comments from Olivier
Dubuisson, Scott Hollenbeck, Russ Housley, Peter Koch, Olaf M.
Kolkman, Ben Laurie, Edward Lewis, John Loughney, Allison Mankin,
Douglas Otis, Marcos Sanz, Pekka Savola, Jason Sloderbeck, Samuel
Weiler, and Florian Weimer. No doubt the list is incomplete. We
apologize to anyone we left out.
Josefsson Standards Track [Page 11]
RFC 4398 Storing Certificates in the DNS February 2006
7. Security Considerations
By definition, certificates contain their own authenticating
signatures. Thus, it is reasonable to store certificates in
non-secure DNS zones or to retrieve certificates from DNS with DNS
security checking not implemented or deferred for efficiency. The
results may be trusted if the certificate chain is verified back to a
known trusted key and this conforms with the user's security policy.
Alternatively, if certificates are retrieved from a secure DNS zone
with DNS security checking enabled and are verified by DNS security,
the key within the retrieved certificate may be trusted without
verifying the certificate chain if this conforms with the user's
security policy.
If an organization chooses to issue certificates for its employees,
placing CERT RRs in the DNS by owner name, and if DNSSEC (with NSEC)
is in use, it is possible for someone to enumerate all employees of
the organization. This is usually not considered desirable, for the
same reason that enterprise phone listings are not often publicly
published and are even marked confidential.
Using the URI type introduces another level of indirection that may
open a new vulnerability. One method of securing that indirection is
to include a hash of the certificate in the URI itself.
If DNSSEC is used, then the non-existence of a CERT RR and,
consequently, certificates or revocation lists can be securely
asserted. Without DNSSEC, this is not possible.
8. IANA Considerations
The IANA has created a new registry for CERT RR: certificate types.
The initial contents of this registry is:
Decimal Type Meaning Reference
------- ---- ------- ---------
0 Reserved RFC 4398
1 PKIX X.509 as per PKIX RFC 4398
2 SPKI SPKI certificate RFC 4398
3 PGP OpenPGP packet RFC 4398
4 IPKIX The URL of an X.509 data object RFC 4398
5 ISPKI The URL of an SPKI certificate RFC 4398
6 IPGP The fingerprint and URL RFC 4398
of an OpenPGP packet
7 ACPKIX Attribute Certificate RFC 4398
8 IACPKIX The URL of an Attribute RFC 4398
Certificate
Josefsson Standards Track [Page 12]
RFC 4398 Storing Certificates in the DNS February 2006
9-252 Available for IANA assignment
by IETF Standards action
253 URI URI private RFC 4398
254 OID OID private RFC 4398
255 Reserved RFC 4398
256-65279 Available for IANA assignment
by IETF Consensus
65280-65534 Experimental RFC 4398
65535 Reserved RFC 4398
Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
only be assigned by an IETF standards action [6]. This document
assigns 0x0001 through 0x0008 and 0x00FD and 0x00FE. Certificate
types 0x0100 through 0xFEFF are assigned through IETF Consensus [6]
based on RFC documentation of the certificate type. The availability
of private types under 0x00FD and 0x00FE ought to satisfy most
requirements for proprietary or private types.
The CERT RR reuses the DNS Security Algorithm Numbers registry. In
particular, the CERT RR requires that algorithm number 0 remain
reserved, as described in Section 2. The IANA will reference the
CERT RR as a user of this registry and value 0, in particular.
9. Changes since RFC 2538
1. Editorial changes to conform with new document requirements,
including splitting reference section into two parts and
updating the references to point at latest versions, and to add
some additional references.
2. Improve terminology. For example replace "PGP" with "OpenPGP",
to align with RFC 2440.
3. In Section 2.1, clarify that OpenPGP public key data are binary,
not the ASCII armored format, and reference 10.1 in RFC 2440 on
how to deal with OpenPGP keys, and acknowledge that
implementations may handle additional packet types.
4. Clarify that integers in the representation format are decimal.
5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
terminology. Improve reference for Key Tag Algorithm
calculations.
6. Add examples that suggest use of CNAME to reduce bandwidth.
7. In Section 3, appended the last paragraphs that discuss
"content-based" vs "purpose-based" owner names. Add Section 3.2
for purpose-based X.509 CERT owner names, and Section 3.4 for
purpose-based OpenPGP CERT owner names.
8. Added size considerations.
9. The SPKI types has been reserved, until RFC 2692/2693 is moved
from the experimental status.
10. Added indirect types IPKIX, ISPKI, IPGP, and IACPKIX.
Josefsson Standards Track [Page 13]
RFC 4398 Storing Certificates in the DNS February 2006
11. An IANA registry of CERT type values was created.
10. References
10.1. Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
"Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
January 1998.
[5] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[7] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[8] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[9] Farrell, S. and R. Housley, "An Internet Attribute Certificate
Profile for Authorization", RFC 3281, April 2002.
[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[11] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[12] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
Josefsson Standards Track [Page 14]
RFC 4398 Storing Certificates in the DNS February 2006
10.2. Informative References
[13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[14] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[15] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
September 1999.
[16] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003.
[17] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004.
[18] Richardson, M., "A Method for Storing IPsec Keying Material in
DNS", RFC 4025, March 2005.
Josefsson Standards Track [Page 15]
RFC 4398 Storing Certificates in the DNS February 2006
Appendix A. Copying Conditions
Regarding the portion of this document that was written by Simon
Josefsson ("the author", for the remainder of this section), the
author makes no guarantees and is not responsible for any damage
resulting from its use. The author grants irrevocable permission to
anyone to use, modify, and distribute it in any way that does not
diminish the rights of anyone else to use, modify, and distribute it,
provided that redistributed derivative works do not contain
misleading author or version information. Derivative works need not
be licensed under similar terms.
Author's Address
Simon Josefsson
EMail: simon@josefsson.org
Josefsson Standards Track [Page 16]
RFC 4398 Storing Certificates in the DNS February 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Josefsson Standards Track [Page 17]

2691
doc/rfc/rfc4408.txt Normal file
View file

File diff suppressed because it is too large Load diff

227
doc/rfc/rfc4431.txt Normal file
View file

@ -0,0 +1,227 @@
Network Working Group M. Andrews
Request for Comments: 4431 Internet Systems Consortium
Category: Informational S. Weiler
SPARTA, Inc.
February 2006
The DNSSEC Lookaside Validation (DLV) DNS Resource Record
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines a new DNS resource record, called the DNSSEC
Lookaside Validation (DLV) RR, for publishing DNSSEC trust anchors
outside of the DNS delegation chain.
1. Introduction
DNSSEC [1] [2] [3] authenticates DNS data by building public-key
signature chains along the DNS delegation chain from a trust anchor,
ideally a trust anchor for the DNS root.
This document defines a new resource record for publishing such trust
anchors outside of the DNS's normal delegation chain. Use of these
records by DNSSEC validators is outside the scope of this document,
but it is expected that these records will help resolvers validate
DNSSEC-signed data from zones whose ancestors either aren't signed or
refuse to publish delegation signer (DS) records for their children.
2. DLV Resource Record
The DLV resource record has exactly the same wire and presentation
formats as the DS resource record, defined in RFC 4034, Section 5.
It uses the same IANA-assigned values in the algorithm and digest
type fields as the DS record. (Those IANA registries are known as
the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
Numbers" registries.)
Andrews & Weiler Informational [Page 1]
RFC 4431 DLV Resource Record February 2006
The DLV record is a normal DNS record type without any special
processing requirements. In particular, the DLV record does not
inherit any of the special processing or handling requirements of the
DS record type (described in Section 3.1.4.1 of RFC 4035). Unlike
the DS record, the DLV record may not appear on the parent's side of
a zone cut. A DLV record may, however, appear at the apex of a zone.
3. Security Considerations
For authoritative servers and resolvers that do not attempt to use
DLV RRs as part of DNSSEC validation, there are no particular
security concerns -- DLV RRs are just like any other DNS data.
Software using DLV RRs as part of DNSSEC validation will almost
certainly want to impose constraints on their use, but those
constraints are best left to be described by the documents that more
fully describe the particulars of how the records are used. At a
minimum, it would be unwise to use the records without some sort of
cryptographic authentication. More likely than not, DNSSEC itself
will be used to authenticate the DLV RRs. Depending on how a DLV RR
is used, failure to properly authenticate it could lead to
significant additional security problems including failure to detect
spoofed DNS data.
RFC 4034, Section 8, describes security considerations specific to
the DS RR. Those considerations are equally applicable to DLV RRs.
Of particular note, the key tag field is used to help select DNSKEY
RRs efficiently, but it does not uniquely identify a single DNSKEY
RR. It is possible for two distinct DNSKEY RRs to have the same
owner name, the same algorithm type, and the same key tag. An
implementation that uses only the key tag to select a DNSKEY RR might
select the wrong public key in some circumstances.
For further discussion of the security implications of DNSSEC, see
RFC 4033, RFC 4034, and RFC 4035.
4. IANA Considerations
IANA has assigned DNS type code 32769 to the DLV resource record from
the Specification Required portion of the DNS Resource Record Type
registry, as defined in [4].
The DLV resource record reuses the same algorithm and digest type
registries already used for the DS resource record, currently known
as the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
Numbers" registries.
Andrews & Weiler Informational [Page 2]
RFC 4431 DLV Resource Record February 2006
5. Normative References
[1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
[4] Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain Name
System (DNS) IANA Considerations", BCP 42, RFC 2929,
September 2000.
Authors' Addresses
Mark Andrews
Internet Systems Consortium
950 Charter St.
Redwood City, CA 94063
US
EMail: Mark_Andrews@isc.org
Samuel Weiler
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, Maryland 21046
US
EMail: weiler@tislabs.com
Andrews & Weiler Informational [Page 3]
RFC 4431 DLV Resource Record February 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Andrews & Weiler Informational [Page 4]

451
doc/rfc/rfc4470.txt Normal file
View file

@ -0,0 +1,451 @@
Network Working Group S. Weiler
Request for Comments: 4470 SPARTA, Inc.
Updates: 4035, 4034 J. Ihren
Category: Standards Track Autonomica AB
April 2006
Minimally Covering NSEC Records and DNSSEC On-line Signing
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes how to construct DNSSEC NSEC resource records
that cover a smaller range of names than called for by RFC 4034. By
generating and signing these records on demand, authoritative name
servers can effectively stop the disclosure of zone contents
otherwise made possible by walking the chain of NSEC records in a
signed zone.
Table of Contents
1. Introduction ....................................................1
2. Applicability of This Technique .................................2
3. Minimally Covering NSEC Records .................................2
4. Better Epsilon Functions ........................................4
5. Security Considerations .........................................5
6. Acknowledgements ................................................6
7. Normative References ............................................6
1. Introduction
With DNSSEC [1], an NSEC record lists the next instantiated name in
its zone, proving that no names exist in the "span" between the
NSEC's owner name and the name in the "next name" field. In this
document, an NSEC record is said to "cover" the names between its
owner name and next name.
Weiler & Ihren Standards Track [Page 1]
RFC 4470 NSEC Epsilon April 2006
Through repeated queries that return NSEC records, it is possible to
retrieve all of the names in the zone, a process commonly called
"walking" the zone. Some zone owners have policies forbidding zone
transfers by arbitrary clients; this side effect of the NSEC
architecture subverts those policies.
This document presents a way to prevent zone walking by constructing
NSEC records that cover fewer names. These records can make zone
walking take approximately as many queries as simply asking for all
possible names in a zone, making zone walking impractical. Some of
these records must be created and signed on demand, which requires
on-line private keys. Anyone contemplating use of this technique is
strongly encouraged to review the discussion of the risks of on-line
signing in Section 5.
1.2. Keywords
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
2. Applicability of This Technique
The technique presented here may be useful to a zone owner that wants
to use DNSSEC, is concerned about exposure of its zone contents via
zone walking, and is willing to bear the costs of on-line signing.
As discussed in Section 5, on-line signing has several security
risks, including an increased likelihood of private keys being
disclosed and an increased risk of denial of service attack. Anyone
contemplating use of this technique is strongly encouraged to review
the discussion of the risks of on-line signing in Section 5.
Furthermore, at the time this document was published, the DNSEXT
working group was actively working on a mechanism to prevent zone
walking that does not require on-line signing (tentatively called
NSEC3). The new mechanism is likely to expose slightly more
information about the zone than this technique (e.g., the number of
instantiated names), but it may be preferable to this technique.
3. Minimally Covering NSEC Records
This mechanism involves changes to NSEC records for instantiated
names, which can still be generated and signed in advance, as well as
the on-demand generation and signing of new NSEC records whenever a
name must be proven not to exist.
Weiler & Ihren Standards Track [Page 2]
RFC 4470 NSEC Epsilon April 2006
In the "next name" field of instantiated names' NSEC records, rather
than list the next instantiated name in the zone, list any name that
falls lexically after the NSEC's owner name and before the next
instantiated name in the zone, according to the ordering function in
RFC 4034 [2] Section 6.1. This relaxes the requirement in Section
4.1.1 of RFC 4034 that the "next name" field contains the next owner
name in the zone. This change is expected to be fully compatible
with all existing DNSSEC validators. These NSEC records are returned
whenever proving something specifically about the owner name (e.g.,
that no resource records of a given type appear at that name).
Whenever an NSEC record is needed to prove the non-existence of a
name, a new NSEC record is dynamically produced and signed. The new
NSEC record has an owner name lexically before the QNAME but
lexically following any existing name and a "next name" lexically
following the QNAME but before any existing name.
The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
bits set and SHOULD NOT have any other bits set. This relaxes the
requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
names that did not exist before the zone was signed.
The functions to generate the lexically following and proceeding
names need not be perfect or consistent, but the generated NSEC
records must not cover any existing names. Furthermore, this
technique works best when the generated NSEC records cover as few
names as possible. In this document, the functions that generate the
nearby names are called "epsilon" functions, a reference to the
mathematical convention of using the greek letter epsilon to
represent small deviations.
An NSEC record denying the existence of a wildcard may be generated
in the same way. Since the NSEC record covering a non-existent
wildcard is likely to be used in response to many queries,
authoritative name servers using the techniques described here may
want to pregenerate or cache that record and its corresponding RRSIG.
For example, a query for an A record at the non-instantiated name
example.com might produce the following two NSEC records, the first
denying the existence of the name example.com and the second denying
the existence of a wildcard:
exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
\).com 3600 IN NSEC +.com ( RRSIG NSEC )
Weiler & Ihren Standards Track [Page 3]
RFC 4470 NSEC Epsilon April 2006
Before answering a query with these records, an authoritative server
must test for the existence of names between these endpoints. If the
generated NSEC would cover existing names (e.g., exampldd.com or
*bizarre.example.com), a better epsilon function may be used or the
covered name closest to the QNAME could be used as the NSEC owner
name or next name, as appropriate. If an existing name is used as
the NSEC owner name, that name's real NSEC record MUST be returned.
Using the same example, assuming an exampldd.com delegation exists,
this record might be returned from the parent:
exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
Like every authoritative record in the zone, each generated NSEC
record MUST have corresponding RRSIGs generated using each algorithm
(but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
described in RFC 4035 [3] Section 2.2. To minimize the number of
signatures that must be generated, a zone may wish to limit the
number of algorithms in its DNSKEY RRset.
4. Better Epsilon Functions
Section 6.1 of RFC 4034 defines a strict ordering of DNS names.
Working backward from that definition, it should be possible to
define epsilon functions that generate the immediately following and
preceding names, respectively. This document does not define such
functions. Instead, this section presents functions that come
reasonably close to the perfect ones. As described above, an
authoritative server should still ensure than no generated NSEC
covers any existing name.
To increment a name, add a leading label with a single null (zero-
value) octet.
To decrement a name, decrement the last character of the leftmost
label, then fill that label to a length of 63 octets with octets of
value 255. To decrement a null (zero-value) octet, remove the octet
-- if an empty label is left, remove the label. Defining this
function numerically: fill the leftmost label to its maximum length
with zeros (numeric, not ASCII zeros) and subtract one.
In response to a query for the non-existent name foo.example.com,
these functions produce NSEC records of the following:
Weiler & Ihren Standards Track [Page 4]
RFC 4470 NSEC Epsilon April 2006
fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
\)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
The first of these NSEC RRs proves that no exact match for
foo.example.com exists, and the second proves that there is no
wildcard in example.com.
Both of these functions are imperfect: they do not take into account
constraints on number of labels in a name nor total length of a name.
As noted in the previous section, though, this technique does not
depend on the use of perfect epsilon functions: it is sufficient to
test whether any instantiated names fall into the span covered by the
generated NSEC and, if so, substitute those instantiated owner names
for the NSEC owner name or next name, as appropriate.
5. Security Considerations
This approach requires on-demand generation of RRSIG records. This
creates several new vulnerabilities.
First, on-demand signing requires that a zone's authoritative servers
have access to its private keys. Storing private keys on well-known
Internet-accessible servers may make them more vulnerable to
unintended disclosure.
Second, since generation of digital signatures tends to be
computationally demanding, the requirement for on-demand signing
makes authoritative servers vulnerable to a denial of service attack.
Last, if the epsilon functions are predictable, on-demand signing may
enable a chosen-plaintext attack on a zone's private keys. Zones
using this approach should attempt to use cryptographic algorithms
that are resistant to chosen-plaintext attacks. It is worth noting
that although DNSSEC has a "mandatory to implement" algorithm, that
is a requirement on resolvers and validators -- there is no
requirement that a zone be signed with any given algorithm.
The success of using minimally covering NSEC records to prevent zone
walking depends greatly on the quality of the epsilon functions
Weiler & Ihren Standards Track [Page 5]
RFC 4470 NSEC Epsilon April 2006
chosen. An increment function that chooses a name obviously derived
from the next instantiated name may be easily reverse engineered,
destroying the value of this technique. An increment function that
always returns a name close to the next instantiated name is likewise
a poor choice. Good choices of epsilon functions are the ones that
produce the immediately following and preceding names, respectively,
though zone administrators may wish to use less perfect functions
that return more human-friendly names than the functions described in
Section 4 above.
Another obvious but misguided concern is the danger from synthesized
NSEC records being replayed. It is possible for an attacker to
replay an old but still validly signed NSEC record after a new name
has been added in the span covered by that NSEC, incorrectly proving
that there is no record at that name. This danger exists with DNSSEC
as defined in [3]. The techniques described here actually decrease
the danger, since the span covered by any NSEC record is smaller than
before. Choosing better epsilon functions will further reduce this
danger.
6. Acknowledgements
Many individuals contributed to this design. They include, in
addition to the authors of this document, Olaf Kolkman, Ed Lewis,
Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
Jakob Schlyter, Bill Manning, and Joao Damas.
In addition, the editors would like to thank Ed Lewis, Scott Rose,
and David Blacka for their careful review of the document.
7. Normative References
[1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033, March
2005.
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions", RFC
4035, March 2005.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Weiler & Ihren Standards Track [Page 6]
RFC 4470 NSEC Epsilon April 2006
Authors' Addresses
Samuel Weiler
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, Maryland 21046
US
EMail: weiler@tislabs.com
Johan Ihren
Autonomica AB
Bellmansgatan 30
Stockholm SE-118 47
Sweden
EMail: johani@autonomica.se
Weiler & Ihren Standards Track [Page 7]
RFC 4470 NSEC Epsilon April 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Weiler & Ihren Standards Track [Page 8]

6051
doc/rfc/rfc4634.txt Normal file
View file

File diff suppressed because it is too large Load diff

1963
doc/rfc/rfc4641.txt Normal file
View file

File diff suppressed because it is too large Load diff

107
win32utils/updateopenssl.pl Normal file
View file

@ -0,0 +1,107 @@
#!/usr/bin/perl
#
# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
#
# Permission to use, copy, modify, and distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
# PERFORMANCE OF THIS SOFTWARE.
# $Id: updateopenssl.pl,v 1.3 2006/09/25 04:23:59 marka Exp $
# updateopenssl.pl
# This script locates the latest version of OpenSSL in the grandparent
# directory and updates the build scripts to use that version.
#
# Path and directory
$path = "..\\..\\";
$SSLDirprefix = "openssl-*";
# List of files that need to be updated with the actual version of the
# openssl directory
@filelist = ("BuildSetup.bat",
"../lib/dns/win32/libdns.mak",
"../lib/dns/win32/libdns.dsp");
# Locate the openssl directory
$substr = getdirectory();
if ($substr eq 0) {
print "No directory found\n";
}
else {
print "Found $substr directory\n";
}
#Update the list of files
if ($substr ne 0) {
$ind = 0;
foreach $file (@filelist) {
print "Updating file $file\n";
updatefile($file, $substr);
$ind++;
}
}
# Function to find the
sub getdirectory {
my(@namelist);
my($file, $name);
my($cnt);
opendir(DIR,$path) || die "No Directory: $!";
@namelist = grep (/^$SSLDirprefix/i, readdir(DIR));
closedir(DIR);
# Make sure we have something
if (scalar(@namelist) == 0) {
return (0);
}
# Now see if we have a directory or just a file.
# Make sure we are case insensitive
foreach $file (sort {uc($a) cmp uc($b)} @namelist) {
if (-d $path.$file) {
$name = $file;
}
}
# If we have one use it otherwise report the error
# Note that we are only interested in the last one
# since the sort should have taken care of getting
# the latest
if (defined($name)) {
return ($name);
}
else {
return (0);
}
}
# function to replace the openssl directory name with the latest one
sub updatefile {
my($filename, $substr, $line);
my(@Lines);
$filename = $_[0];
$substr = $_[1];
open (RFILE, $filename) || die "Can't open file $filename: $!";
@Lines = <RFILE>;
close (RFILE);
# Replace the string
foreach $line (@Lines) {
$line =~ s/openssl\-[0-9]+\.[0-9]+\.[0-9]+[a-z]/$substr/gi;
}
#update the file
open (RFILE, ">$filename") || die "Can't open file $filename: $!";
foreach $line (@Lines) {
print RFILE $line;
}
close(RFILE);
}