DDDS overview: Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS
The roadmap that says which documents together make up the Dynamic Delegation Discovery System.
Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, DOI 10.17487/RFC3401, October 2002, <https://www.rfc-editor.org/info/rfc3401>.
@misc{rfc3401,
series = {Request for Comments},
number = 3401,
howpublished = {RFC 3401},
publisher = {RFC Editor},
doi = {10.17487/RFC3401},
url = {https://www.rfc-editor.org/info/rfc3401},
author = {M. Mealling},
title = {{Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS}},
pagetotal = 6,
year = 2002,
month = oct,
} RFC text
Contents
Network Working Group M. Mealling
Request for Comments: 3401 VeriSign
Updates: 2276 October 2002
Obsoletes: 2915, 2168
Category: Informational
Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS
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 (2002). All Rights Reserved.
Abstract
This document specifies the exact documents that make up the complete
Dynamic Delegation Discovery System (DDDS). DDDS is an abstract
algorithm for applying dynamically retrieved string transformation
rules to an application-unique string.
This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC
2168 and RFC 2915, as well as updates RFC 2276.
1. Intended Audience
This document and the documents that it references are intended for
anyone attempting to implement or understand the generic DDDS
algorithm, URI Resolution, ENUM telephone number to URI resolution,
and the NAPTR DNS resource record. The reader is warned that reading
one of the documents in this series without reading the others will
probably lead to misunderstandings and interoperability problems.
2. Introduction
The Dynamic Delegation Discovery System is used to implement lazy
binding of strings to data, in order to support dynamically
configured delegation systems. The DDDS functions by mapping some
unique string to data stored within a DDDS Database by iteratively
applying string transformation rules until a terminal condition is
reached. This document defines the entire DDDS by listing the
documents that make up the complete specification at this time.
This document along with RFC 3402, RFC 3403 and RFC 3404 obsoletes
RFC 2168 [8] and RFC 2915 [6], as well as updates RFC 2276 [5]. This
document will be updated and or obsoleted when changes are made to
the DDDS specifications. Thus the reader is strongly encouraged to
check the IETF RFC repository for any documents that obsoletes or
updates this one.
3. The Algorithm
The DDDS algorithm is defined by RFC 3402 [1]. That document defines
the following DDDS concepts:
o The basic DDDS vocabulary.
o The algorithm.
o The requirements on applications using the algorithm.
o The requirements on databases that store DDDS rules.
RFC 3402 is the actual DDDS Algorithm specification. But the
specification by itself is useless without some additional document
that defines how and why the algorithm is used. These documents are
called Applications and do not actually make up part of the DDDS core
specification. Applications require databases in which to store
their Rules. These databases are called DDDS Databases and are
usually specified in separate documents. But again, these Database
specifications are not included in the DDDS core specification
itself.
4. DDDS Applications
No implementation can begin without an Application specification, as
this is what provides the concrete instantiation details for the DDDS
Algorithm. Without them the DDDS is nothing more than a general
algorithm. Application documents define the following:
o the Application Unique String (the thing the delegation rules act
on).
o the First Well Known Rule (the Rule that says where the process
starts).
o the list of valid Databases (you can't just use any Database).
o the final expected output.
Some sample Applications are documented in:
o "E.164 number and DNS" (RFC 2916) [7]. This Application uses the
DDDS to map a telephone number to service endpoints such as SIP or
email.
o "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform
Resource Identifiers (URI) Resolution Application" (RFC 3404) [3].
This Application uses the DDDS to resolve any URI to a set of
endpoints or 'resolvers' that can give additional information
about the URI independent of its particular URI scheme.
5. Currently Standardized Databases
Any DDDS Application must use some type of DDDS Database. Database
documents define the following:
o the general spec for how the Database works.
o formats for Keys.
o formats for Rules.
o Key lookup process.
o rule insertion procedures.
o collision avoidance measures.
A Database cannot be used on its own; there must be at least one
Application that uses it. Multiple Databases and Applications are
defined, and some Databases will support multiple Applications.
However, not every Application uses each Database, and vice versa.
Thus, compliance is defined by the combination of a Database and
Application specification.
One sample Database specification is documented in:
o "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain
Name System (DNS) Database" (RFC 3402) [1]. (This document is the
official specification for the NAPTR DNS Resource Record.)
6. Security Considerations
Any known security issues that arise from the use of algorithms and
databases must be specified in the respective specifications. They
must be completely and fully described. It is not required that the
database and algorithms be secure or that it be free from risks, but
that the known risks be identified. Publication of a new database
type or algorithm does require a security review, and the security
considerations section should be subject to continuing evaluation.
Additional security considerations should be addressed by publishing
revised versions of the database and algorithm specifications.
7. IANA Considerations
While this document itself does not create any new requirements for
the IANA, the documents in this series create many varied
requirements. The IANA Considerations sections in those documents
should be reviewed by the IANA to determine the complete set of new
registries and requirements. Any new algorithms, databases or
applications should take great care in what they require the IANA to
do in the future.
References
[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Two: The Algorithm", RFC 3402, October 2002.
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Doman Name System (DNS) Database", RFC 3403, October
2002.
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The Uniform Resource Identifiers (URI) Resolution
Application", RFC 3404, October 2002.
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.
[5] Sollins, K., "Architectural Principles of Uniform Resource Name
Resolution", RFC 2276, January 1998.
[6] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR)
DNS Resource Record", RFC 2915, August 2000.
[7] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[8] Daniel, R. and M. Mealling, "Resolution of Uniform Resource
Identifiers using the Domain Name System", RFC 2168, June 1997.
Author's Address
Michael Mealling
VeriSign
21345 Ridgetop Circle
Sterling, VA 20166
US
EMail: michael@neonym.net
URI: http://www.verisignlabs.com
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
AI ELI5
On this page
§2What DDDS Is and Who Should Read This
The Dynamic Delegation Discovery System (DDDS) implements lazy binding of strings to data, in order to support dynamically configured delegation systems. It maps a unique string to data stored in a DDDS Database by repeatedly applying string transformation rules until a terminal condition is reached.
RFC 3401 is an Informational memo that defines the entire DDDS by listing the documents that make up the specification. It is meant for anyone implementing or trying to understand the generic DDDS algorithm, URI resolution, ENUM telephone number to URI resolution, and the NAPTR DNS resource record. The reader is warned that reading one document of the series without the others will probably lead to misunderstandings and interoperability problems.
Imagine a treasure hunt where each clue tells you how to find the next clue until you reach the prize. DDDS is the rulebook for that kind of hunt, and this document tells you which booklets belong together.
§3The Algorithm and Its Parts
The algorithm itself is defined by RFC 3402. That document defines the basic DDDS vocabulary, the algorithm, the requirements on applications using the algorithm, and the requirements on databases that store DDDS rules.
The algorithm alone is useless without a document that says how and why it is used. Those documents are called Applications, and they are not part of the DDDS core specification. Applications need places to keep their rules, called DDDS Databases, which are usually specified in separate documents that are also outside the core specification.
The algorithm is like the rules of a board game. You still need a particular game to play and a box to keep the pieces in, and those come from other documents.
- ApplicationDefines the unique string, the first well known rule, valid Databases and the output
- DDDS algorithmCore specification: vocabulary, algorithm, requirements (RFC 3402)
- DatabaseStores the rules: Key and Rule formats, lookup, insertion
§4Applications
No implementation can begin without an Application specification, because it supplies the concrete details for the algorithm. Without one, DDDS is nothing more than a general algorithm. An Application document defines four things:
- the Application Unique String, the thing the delegation rules act on;
- the First Well Known Rule, the rule that says where the process starts;
- the list of valid Databases, since you cannot use just any Database;
- the final expected output.
Two sample Applications are named. RFC 2916, "E.164 number and DNS", uses DDDS to map a telephone number to service endpoints such as SIP or email. RFC 3404 uses DDDS to resolve any URI to a set of endpoints or resolvers that can give more information about the URI, independent of its scheme.
An Application says what you are looking for, where to begin, which boxes you may look in, and what the answer should look like. One example turns a phone number into a way to reach someone.
§5Databases
Every DDDS Application must use some type of DDDS Database. A Database document defines how the Database works in general, the formats for Keys and for Rules, the Key lookup process, rule insertion procedures, and measures to avoid collisions.
A Database cannot be used on its own, and there must be at least one Application that uses it. Several Databases and Applications exist, and some Databases support more than one Application, but not every Application uses every Database. For that reason, compliance is defined by the combination of a Database specification and an Application specification.
The sample Database named is the DNS Database, which is also the official specification for the NAPTR DNS Resource Record. The memo's reference list identifies this as Part Three, RFC 3403.
A Database is the filing cabinet where the rules are kept. It is only useful when some Application knows how to ask it questions.
§6Security and IANA Considerations
Known security issues that arise from using the algorithms and databases must be specified, completely and fully, in the respective specifications. The databases and algorithms are not required to be secure or risk free, but the known risks must be identified. Publishing a new database type or algorithm requires a security review, and the security considerations should keep being evaluated.
RFC 3401 creates no new requirements for the IANA itself, but the other documents in the series create many. The IANA is asked to review their IANA Considerations sections to find the full set of new registries and requirements.
Anyone who adds a new piece must write down the dangers they know about, so users are not surprised later.