As per Relevance of the word security, we have this rfc below:
Network Working Group E.
Request for Comments: 3130 NAI
Category: Informational June 2001
Notes from the State-Of-The-Technology:
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This is a memo of a DNSSEC (Domain Name System Security Extensions
status meeting
1.0
A meeting of groups involved in the development of the DNS
Extensions (DNSSEC) was held in conjunction with the 49th IETF.
discussion covered the extent of current efforts, a discussion
what questions are being asked of DNSSEC, and what is needed by
IETF to progress the definition to the Draft Standard level
DNSSEC [RFC 2535] has been under consideration for quite a few years
with RFC 2535 being the core of the most recent definition.
is part of the charter of two working groups, DNSEXT and DNSOP
ISC's BIND v8.2 implemented part of the specification, BIND v
represents the first full implementation. In 1999 and 2000,
than a half dozen workshops have been held to test the concepts
the earliest versions of implementations. But to date, DNSSEC is
in common use
The current collective wisdom is that DNSSEC is 1) important, 2)
buzzword, 3) hard, 4) immature. To capture the true state of
technology and identify where work is needed, an informal
of groups known to be involved in DNSSEC was held in conjunction
the 49th IETF. The attendees represented NLnet Labs, The
for Internet Infrastructure, RIPE NCC, ARIN, CAIRN (ISI and
Labs), NIST, DISA, RSSAC, Network Associates and
(COM/NET/ORG TLDs).
Lewis Informational [Page 1]
RFC 3130 DNSSEC Status Meeting Report June 2001
The agenda of the meeting consisted of three items. Reports
each group on their current research goals were followed by
discussion of questions being asked of DNSSEC. Finally,
reaching Draft Standard status as a goal, what was needed to
this happen was considered
This report is not simply a transcript of the meeting, it is
summary. Some of the information presented here was obtained
direct contact with participants after the meeting
1.1 What does the term "DNSSEC" mean
One of the comments made during discussions is that DNSSEC does
refer to just one monolithic technology. The term has come to
to "toolbox" of techniques and methodologies, that when used
can improve the integrity of the DNS. Given this observation, it
be seen that some portions of DNSSEC are evolving much more
than other portions. In particular, TSIG [RFC 2845] has
reached a level "being deployable" for zone transfers
The following four components are considered to be part of DNSSEC
The concept of digital signature protection of DNS traffic
described in RFC 2535 and a few support documents (such as [
3008]), which is designed to protect the transfer of data on
Internet scale. The concept of protecting queries and
through the less-scalable but more efficient TSIG mechanism [
2845], which has applicability to zone transfers, DHCP registrations
and other resolver to name server traffic. Secure dynamic
[RFC 3007], by virtue of using TSIG, can be considered to be part
DNSSEC. Finally, the definition of the CERT resource record [
2538] gives DNS the ability to become a distribution mechanism
security data
This definition of the components of DNSSEC is in no way definitive
To be honest, this is a somewhat artificial grouping. DNSSEC
not encompass all of the security practiced in DNS today,
example, the redefinition of when and how data is cached [RFC 2181],
plays a big role in hardening the DNS system. The four elements
DNSSEC described in the previous paragraph are grouped
mostly because they do interrelate, but also they were developed
approximately the same time
2.0 Group
The first part of the meeting consisted of reports of goals.
this a taxonomy of efforts has been made to see if there are gaps
the work
Lewis Informational [Page 2]
RFC 3130 DNSSEC Status Meeting Report June 2001
2.1 NLnet
Efforts by NLnet Labs are directed towards yielding an
of the impact of DNSSEC on ccTLDs, specifically .de (Germany), .
(The Netherlands), and .se (Sweden). Work to date has studied
problem of applying digital signatures and NXT records to a zone
The conclusion drawn is that there are no real problems
memory or CPU speed when signing large zones, not even for ".com."
NLnet Labs has offered to work with Verisign to examine this further
NLnet Labs is trying to define and document procedures for
registries, registrars and registrants to properly handle
like zone-resigning and key-rollover at the root, TLD, and
levels. The outcome so far is that the DNSOP Roll Over
seems impractical or possibly even impossible to implement at
TLDs. NLnet Labs will produce a draft on an alternative KEY+
handling scheme where SIGs are only kept in the zone where
corresponding zone-KEY is located. This scheme reduces the
actions for resigning zones from 2 levels (current zone and
children) to 1 level (current zone), and for key-rollover from 3
levels (parent, current zone and all children) to 2 levels (
and current zone).
2.2
Verisign's registry operations and corporate components have
investigating what DNSSEC means to very large zones, not just from
hardware point of view, but from an institutional point of view
With the service of providing delegations already commercialized
they are attempting to define what it would take to provide a
service. An important issue is the parent validation of
delegated zone's keys
2.3 The Foundation for Internet
The Foundation for Internet Infrastructure, an organization
Sweden, is running a project with two parts. One part is directed
the "topology" of the participants in DNSSEC, the other part of
project is directed towards general development of tools
The study is examining the administrative issues of running DNSSEC
One issue is the possible 4-party interaction in the use of DNSSEC
The four parties are the registry, the registrar, the registrant,
the DNS operator. Of these four parties, any combination may
within one entity, such as a registrant that operates their own
as part of their information technology department
Lewis Informational [Page 3]
RFC 3130 DNSSEC Status Meeting Report June 2001
The other part of the study is looking at what happens in
resolver. Goals include DNSSEC-enabling tools such as ISAKMPd (
IPSEC key negotiation software) secure NTP4, and e-mail. Part
this effort is implemented in the sigz.net experiment, information
this exists at www.sigz.net
2.4
The RSSAC (Root Server System Advisory Committee) has come to
conclusion that TSIG is worthwhile and should be deployed. There
no schedule for deployment, however
As for the rest of DNSSEC, there is a need to better understand
impact of the new features before being introduced into production
Currently issues regarding potential testbeds are being documented
Two fundamental assumptions are that a DNSSEC testbed involving
root servers is desirable and that such a testbed would allow
long term testing. The latter assumption is based upon the need
understand how repeated zone key validations can occur at
independent levels of the DNS hierarchy
2.5
CAIRN (Collaborative Advanced Interagency Research Network) is
DARPA-sponsored network for collaborative research. A
activity that involves DNSSEC is FMESHD, shorthand for Fault-
Mesh of Trust in DNSSEC. The effort of this activity is to
a means of building a resolver's chain of trust when some of the
tree is unavailable or unsecured. An early deliverable of this is
extension of secure shell to retrieve keys from DNSSEC. As part
this activity, the use of DNSSEC in a non-major provider zone
being implemented and studied
2.6
NIST is collecting performance information regarding DNSSEC. One
the fears in adopting DNSSEC is the workload it adds to existing
machine workload. The hopes of this effort is to quantify the fear
to see if it is real or imagined
If time permits, there may be an effort to implement a zone
checking program (implemented in Java) that will look for missteps
the use of DNSSEC. Base code exists, but needs work (beyond
current baseline).
Lewis Informational [Page 4]
RFC 3130 DNSSEC Status Meeting Report June 2001
2.7
The U.S. Defense Information Systems Agency is providing funds
have DNSSEC implemented in BIND. Of particular interest is
sure that the DNSSEC specifications are correct, that BIND adheres
the specifications, and that BIND is available on the
systems in use by the US Department of Defense. DISA expects
every line of code developed through this effort be made
available as part of stock BIND releases
2.8 RIPE
The RIPE NCC is looking at the impact of DNSSEC on IP-registries
The RIPE NCC is planning to coordinate and assist in the
of DNSSEC. Because the RIPE NCC is the Regional Internet
for Europe the focus will be on the deployment of DNSSEC on
reverse map tree (in-addr.arpa for IPv4).
2.9
ARIN is investigating DNSSEC for use in signing its delegated
under in-addr.arpa. It participated in a dnssec workshop
NANOG 20 held in Washington, DC in October, 2000. It
participated in an ipv6-dnssec workshop that followed IETF 49 in
Diego, California. Additionally, ARIN has stood up a
dedicated to testing various dns experimentation, including
and carrying out limited testing
2.10 Network
NAI is pressing to get the tislabs.com zone running in
with DNSSEC. This is an example of a non-Internet service
(neither an IP transit, IP address allocation, nor a domain
managing entity) making use of DNSSEC within the normal operations
the Information Technology department
2.11 ip6.int.
The name servers authoritative for the ip6.int. domain are
upgraded to be able to support CERT records and TSIG. Once this
fully accomplished and proposals are approved, TSIG and CERT
will be used. Further DNSSEC work is unknown
2.12 Topology Based Domain
Topology Based Domain Search (TBDS), is a DARPA funded
investigating how DNS may continue to run in disconnected parts
the Internet. Topics of interest (either covered by this project,
Lewis Informational [Page 5]
RFC 3130 DNSSEC Status Meeting Report June 2001
associated with the project) are the use of split keys, self-
zone (keys), and multiple signing algorithms. A goal is
establishment of signed infrastructure zones, facilitating
creation of a distributed CA for activities like IPSEC and FreeSwan
3.0 Taxonomy of efforts and What is
The efforts being undertaken appear to cover a broad range of
areas, from large domain registries to domain name consumers.
has been progressing in the production of zones (signing,
management), and is starting in the use (resolver) of DNSSEC
data
From the discussion, there were no apparent areas lacking attention
Additional input in some areas is needed however, particularly
making use (applications and IT department) of DNSSEC
4.0 Questions facing
By the 49th IETF meeting, the most pressing question on DNSSEC is "
it deployable?" From just the emphasis placed on this question,
meeting generated a list of questions and made sure that either
answer was known, or work was being done to address the question
4.1 Is it deployable? When
The usual answer to this has been "not now." When is always off
the future - "about a year." To get to a deployable point, a
of workshops have been held since the spring of 1999.
At this point, it is becoming clearer that longer term workshops
needed. In going through the motions of any workshop, the number
issues raised that impact the protocol's specification
diminishing, as well as implementation issues. As such, one or
day workshops have been helping less and less in reaching deployment
What is needed is to run longer term test configurations,
workshops that are help in conjunction with other events and
assume continuity. This will allow a better assessment of the
that involve the passage of time - expirations on key validations
etc
As was noted in section 1.1, and touched on in section 2,
component of DNSSEC, TSIG, is more advanced that the others. Use
TSIG to protect zone transfers is already matured to the "really
idea to do stage" even if other elements of DNSSEC are not.
TSIG to protect traffic between local resolver and their "default
recursive name server still needs more work, however
Lewis Informational [Page 6]
RFC 3130 DNSSEC Status Meeting Report June 2001
4.2 Does DNSSEC work? Is it the right approach
Currently there is a lot of effort into making the specification
proposed work. There is some effort in assessing the
at this point, particularly the value of the NXT records and
replacements of it
There seems little question on value of the KEY and SIG records
There is some research still needed on KEY validation across
boundaries. Such work is at least scheduled
4.3 How will client software make use of DNSSEC
There are a number of efforts to take existing applications and
them make direct use of DNSSEC to carry out their functions.
such example is secure shell
When or whether DNSSEC will be understood in the (using POSIX-
terms) operating systems "gethostbyname" and similar routines has
been addressed
4.4 What are the remaining issues
There are still a few protocol issues. The NXT resource record
designed to provide a means to authentically deny data exists.
problem is that the solution proposed may be worse than the problem
in the eyes of some. There is an alternative proposal, the
resource record, under consideration in the DNSEXT working group.
the present time, the DNSEXT working is considering the
question: Is there a need to authentically deny existence of data,
so, which is better, NXT (being incumbent) or NO
Another less defined issue is the mechanism for parent validation
children signatures. Although the protocol elements of this
becoming settled, the operational considerations are not,
evidenced by work mentioned in section 2. DNSSEC interactions
also been referenced in discussions over a standard registry
registrar protocol
5.0 Progressing to Draft
The IETF goal for DNSSEC is to progress the documents through
standards track [RFC 2026]. Currently, RFC 2535 is the
iteration at the Proposed standard level. There is a need to
through Proposed once more. Following this, the next goal is Draft
Lewis Informational [Page 7]
RFC 3130 DNSSEC Status Meeting Report June 2001
To pass to the Draft Standard level, two main requirements must
met. There must be two or more interoperable implementations.
must also be sufficient successful operational experience
5.1 Revision of RFC 2535 via
DNSEXT will soon begin a rewrite of the RFC 2535 specification (
its support documents), rolling in updates and clarifications
upon implementation and testing experience
5.2 Operations document(s) via
DNSOP will continue to be the forum for operations documents
upon DNSSEC activity. There is a need for the community to
more documents to this group
5.3
Demonstrating interoperability of DNSSEC, meaning the interaction
two different implementations when performing DNSSEC work, poses
issue because, to date, only BIND is seriously being fitted
DNSSEC. There are other partial implementations of
functionality, so the potential for partial
demonstrations may exist
During the meeting, it was realized that given goals stated, a
DNSSEC implementation is needed in 18 months. Various folks in
room mentioned that they would begin see what could be done
this
6.0
The following people attended the meeting and/or provided text
this report (in no particular order): Mark Kosters (
Solutions), Patrik Faltstrom (Cisco), Ted Lindgreen and Miek
(NLnet Labs), Jaap Akerhuis (SIDN), Olaf Kolkmann (RIPE NCC),
Manning and Dan Massey (ISI), Martin Fredriksson, Hakan Olsson
Jakob Schlyter (Carlstedt Research & Technology), Doug Montgomery
Scott Rose (NIST), Johan Ihren and Lars-Johan Liman (Autonomica),
Brian Wellington (Nominum), Kevin Meynell (CENTR), Ed Lewis
Olafur Gudmundsson (NAI Labs).
7.0 IANA
This document does not involve assigned numbers in any way
Lewis Informational [Page 8]
RFC 3130 DNSSEC Status Meeting Report June 2001
8.0 Security
This document, although a discussion of security enhancements to
DNS, does not itself impact security. Where security issues arise
they will be discussed in the Security Considerations of
appropriate document
9.0
The text of any RFC may be retrieved by a web browser by
the URL: ftp://ftp.isi.edu/in-notes/rfc.txt, where "wxyz"
the number of the RFC
[RFC 2026] Bradner, S., "The Internet Standards Process --
3", BCP 9, RFC 2026, October 1996.
[RFC 2181] Elz, R. and R. Bush, "Clarifications to the
Specification", July 1997.
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
March 1999.
[RFC 2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates
the Domain Name System", March 1999.
[RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B
Wellington, "Secret Key Transaction Authentication for
(TSIG)", May 2000.
[RFC 3007] Wellington, B., "Secure Domain Name System
Update", November 2000.
[RFC 3008] Wellington, B., "Domain Name System Security
Authority", November 2000.
10.0 Editor's
Edward
3060 Washington Rd (Rte 97)
Glenwood, MD 21738
Phone: +1(443)259-2352
EMail: lewis@tislabs.
Lewis Informational [Page 9]
RFC 3130 DNSSEC Status Meeting Report June 2001
11.0 Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Lewis Informational [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
