RFC 3403
Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database
RFC 3403: Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database 🎀
Network Working Group, published October 2002, by M. Mealling of VeriSign 💖. It's a Standards Track document, and it obsoletes RFC 2915 and RFC 2168 🧚. Its header doesn't list anything it updates.
Status of This Memo ✨
Okay so this doc is an Internet standards track protocol for the Internet community, and it's basically asking everyone to talk about it and suggest improvements 💬. For the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📋. And the good news: distribution of this memo is unlimited 🌈.
Copyright Notice 💅
Copyright (C) The Internet Society (2002). All Rights Reserved. 🔒
Abstract 🦋
So this doc describes a Dynamic Delegation Discovery System (DDDS) Database that uses the Domain Name System (DNS) as a distributed database of Rules 🌸. The Keys are domain-names, and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR) 🔑.
Since this document obsoletes RFC 2915, it's the official specification for the NAPTR DNS Resource Record 👑. It's also part of a series that's completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401) 🧠. It is very important to note that it is impossible to read and understand any document in this series without reading the others. 🙈
Table of Contents 📋
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DDDS Database Specification . . . . . . . . . . . . . . . . 3
4. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Packet Format . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Additional Information Processing . . . . . . . . . . . . . 7
4.2.1 Additional Section processing by DNS servers . . . . . . . . 7
4.2.2 Additional Section processing by resolver/applications . . . 7
4.3 Master File Format . . . . . . . . . . . . . . . . . . . . . 7
5. Application Specifications . . . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1 URN Example . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2 E164 Example . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Advice for DNS Administrators . . . . . . . . . . . . . . . 10
8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . 11
References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
Full Copyright Statement . . . . . . . . . . . . . . . . . . 141. Introduction 🌷
The Dynamic Delegation Discovery System (DDDS) is used to implement lazy binding of strings to data, so it can support dynamically configured delegation systems 🫶. Here's how it works: the DDDS maps some unique string to data stored within a DDDS Database by iteratively applying string transformation rules until a terminal condition is reached 🔁.
This document describes how the Domain Name System (DNS) is used as a data store for the Rules that let a DDDS Application function 💜. It doesn't specify any particular application or usage scenario ✨. The entire series of documents is specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401) [1]. Again, it's very important to note that it's impossible to read and understand any document in that series without reading the related documents 🙈.
The Naming Authority Pointer (NAPTR) DNS Resource Record (RR) specified here was originally produced by the URN Working Group 🧚♀️. It was a way to encode rule-sets in DNS, so that the delegated sections of a Uniform Resource Identifiers (URI) could be decomposed in a way that let them be changed and re-delegated over time 🦋. The result was a Resource Record that included a regular expression, which a client program would use to rewrite a string into a domain name 💅.
Regular expressions were chosen for their compactness-to-expressivity ratio, which allows a great deal of information to be encoded in a rather small DNS packet 🍓.
Over time this process was generalized for other Applications and Rule Databases 🌈. This document defines a Rules Database without any particular Application, because there may be several Applications all taking advantage of this same Rules Database 👑.
2. Terminology 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [6] 🔑.
All other terminology, especially capitalized terms, is taken from [3] 💅.
3. DDDS Database Specification 💖
General Description:
This database uses the Domain Name System (DNS) as specified in [8] and [7] 🌸.
The character set used to specify the various values of the NAPTR records is UTF-8 [17] 🌍. Care must be taken here: where either the input or the output to the substitution expression contains code points outside of the ASCII/Unicode equivalence in UTF-8, any UTF-8 must be interpreted as a series of code-points instead of as a series of bytes 🧩. That's to make sure the internationalized features of the POSIX Extended Regular Expressions can match their intended code-points ✨. Substitution expressions MUST NOT be written where they depend on a specific POSIX locale, since that would cause substitution expressions to lose their ability to be universally applicable. 🚫
All DNS resource records have a Time To Live (TTL) associated with them ⏰. Once the number of seconds has passed since the record was retrieved, the record is no longer valid, and a new query must be used to get the new records 🔄. So, as mentioned in the DDDS Algorithm, a given Rule can expire 😭. If an application tries to fall back to previously retrieved sets of Rules (because of a bad delegation path or some network or server failure), the application MUST ensure that none of the records it is relying on have expired. If even a single record has expired, the application is required to start over at the beginning of the algorithm 🔁.
Key Format:
A Key is a validly constructed DNS domain-name 🔑.
Lookup Request:
To request a set of rules for a given Key, the client issues a request, following standard DNS rules, for NAPTR Resource Records for the given domain-name 🔍.
Lookup Response:
The response to a request for a given Key (domain-name) is a series of NAPTR records 📬. You can find the format of a NAPTR Resource Record in Section 4 📄.
Rule Insertion Procedure:
Rules are inserted by adding new records to the appropriate DNS zone 🌱. If a Rule produces a Key that exists in a particular zone, then only the entity with administrative control of that zone can specify the Rule associated with that Key 👑.
Collision Avoidance:
Okay, so, collisions are a real thing here. Two Applications may use this Database (which is actually the case with the ENUM and URI Resolution Applications, Section 6.2), so there's a chance of collision between rules when two NAPTR records appear in the same domain but apply to more than one Application 😬. There are three ways to avoid collisions 🛡️:
- Create a new zone within the domain in common that contains only NAPTR records appropriate for the application. For example, all URI Resolution records would live under
urires.example.com, and all ENUM records would be underenum.example.com🗂️. If that's not possible because you don't control the upstream delegation, use the second method instead 🙃. - Write the regular expression so it contains enough of the Application Unique string to tell it apart from any other. For example, the URI Resolution Application can use the scheme name on the left-hand side to anchor the regular expression match to that scheme 🔗. An ENUM-specific record in that same zone can anchor the left-hand side of the match with the
"+"character, which ENUM defines as being at the beginning of every Application Unique String ☎️. That way, a given Application Unique String can only match one record or the other, not both 💯. - If two Applications use different Flags or Services values, then a record from the other Application is ignored, since it doesn't apply to the Services/Flags in question 🙅♀️.
4.1. Packet Format 📦
okay so the packet format of the NAPTR RR is below, and the DNS type code for NAPTR is 35 🎀 (remember that number, it's the main character of this whole section)
The packet format for the NAPTR record is as follows
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ORDER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ FLAGS /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ SERVICES /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ REGEXP /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ REPLACEMENT /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+<character-string> and <domain-name> here are defined in RFC 1035 [7] 💅
ORDER 🔢
ORDER is a 16-bit unsigned integer that tells you the order the NAPTR records MUST be processed in so the ordered list of Rules comes out right ✨ It goes from lowest to highest. If two records have the same order value, they count as the same rule, and you should pick between them based on the Preference values and the Services offered.
PREFERENCE 👑
ngl this one is giving identity crisis 😭 It's called "preference" to be nice to DNS people, but it's actually the Priority value in the DDDS Algorithm. It's a 16-bit unsigned integer that sets the order NAPTR records with equal Order values SHOULD be processed in, with low numbers going before high numbers. It's basically like the preference field in an MX record, and domain admins use it to steer clients toward more capable hosts or lighter weight protocols 🦋 A client MAY look at records with higher preference values if it has a good reason, like not supporting some protocol or service very well.
Here's the big difference between Order and Preference 🫶 Once a match is found, the client MUST NOT consider records with a different Order, but it MAY process records with the same Order and different Preferences. The only exception is the second important Note in the DDDS algorithm spec, which talks about allowing clients to use more complex Service determination between steps 3 and 4 of the algorithm. Preference is how you give a higher quality of service to rules that are equal from an authority standpoint but not from a simple load balancing standpoint 💖
Also, DNS has several load balancing mechanisms, so if you need load balancing among otherwise equal services, use methods like SRV records or multiple A records 🌈
FLAGS 🚩
A <character-string> with flags that control aspects of how the fields in the record get rewritten and interpreted. Flags are single characters from the set A-Z and 0-9, and the case of the letters doesn't matter. The field can be empty, which is very chill 🧚
The Application that says how it uses this Database is in charge of defining the Flags in this field. It must define which ones are terminal and which ones are not.
SERVICES 🎀
A <character-string> that specifies the Service Parameters for this delegation path. It's up to the Application Specification to decide the values in this field 🍓
REGEXP 🔍
A <character-string> holding a substitution expression. It gets applied to the original string the client is holding to build the next domain name to look up. Check the DDDS Algorithm spec for the syntax of this field 🌸
As the DDDS algorithm says, the regular expressions MUST NOT be used in a cumulative fashion. That means they should only ever be applied to the original string the client is holding, never to a domain name produced by a previous NAPTR rewrite. I know it's tempting in some applications, but experience has shown that it's extremely fault sensitive, very error prone, and extremely difficult to debug 💀
REPLACEMENT 🦋
A <domain-name> that's the next domain-name to query for, depending on the values in the flags field. This field gets used when the regular expression is a simple replacement operation. Any value in this field MUST be a fully qualified domain-name, and name compression is not to be used for this field 🙈
This field and the REGEXP field together make up the Substitution Expression in the DDDS Algorithm. This field only exists as a historical optimization for DNS compression. The two fields are also mutually exclusive. If a record comes back with values for both fields, it's considered to be in error and SHOULD be either ignored or have an error returned ⭐
4.2. Additional Information Processing 🧚
Additional section processing needs upgraded DNS servers, so it's going to take many years before applications can expect to see relevant records in the additional information section 😭
4.2.1. Additional Section Processing by DNS Servers 🌈
DNS servers MAY add RRsets to the additional information section that are relevant to the answer and have the same authenticity as the data in the answer section. Usually this is made up of A and SRV records, but the exact records depend on the application 💜
4.2.2. Additional Section Processing by Resolver/Applications 💅
Applications MAY inspect the Additional Information section for relevant records, but Applications MUST NOT require that records of any type be in the Additional Information section of any DNS response in order for clients to function. All Applications must be capable of handling responses from nameservers that never fill in the Additional Information part of a response. no cap, that's a whole vibe check 🫶
4.3. Master File Format 📝
The master file format follows the standard rules in RFC-1035. Order and preference, being 16-bit unsigned integers, shall be an integer between 0 and 65535 🔢 The Flags, Services, and Regexp fields are all quoted <character-string>s. Since the Regexp field can contain numerous backslashes, it should be treated with care. See Section 7 for how to correctly enter and escape the regular expression ✨
5. Application Specifications 🎀
This DDDS Database is usable by any application that makes use of the DDDS algorithm. On top of the items required to specify a DDDS Application, an application that wants to use this Database must also define the following values:
- What domain the Key produced by the First Well Known Rule belongs to. Any application must make sure its rules don't collide with rules used by another application making use of this Database. For example, the 'foo' application might have all of its First Well Known Keys in the 'foo.net' zone 🌸
- What the allowed values for the Services and Protocols fields are 🦋
- What the expected output is of the terminal rewrite rule, plus how the Flags are actually encoded and utilized 👑
6. Examples 💖
6.1. URN Example 🧚
The NAPTR record was originally created for use with the Uniform Resource Name (URN) Resolver Discovery Service (RDS) [15]. This example shows how a particular URN would use the NAPTR record to find a resolver service that can answer questions about the URN. For the definitive specification of this Application, see [2] 🔥
Let's say there's a URN namespace based on MIME Content-Ids (this is very hypothetical, so do not rely on this 🙈). The URN might look like this:
urn:cid:199606121851.1@bar.example.comThis Application's First Well Known Rule is to extract the characters between the first and second colon. For this URN, that's 'cid'. The Application also says that, to build a Database-valid Key, the string 'urn.arpa' should be appended to the result of the First Well Known Rule. So the result is 'cid.urn.arpa' ✨ Next, the client queries DNS for NAPTR records for the domain-name 'cid.urn.arpa'. The result is a single record:
cid.urn.arpa.
;; order pref flags service regexp replacement
IN NAPTR 100 10 "" "" "!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i" .Since there's only one record, ordering the responses isn't a problem 🌷 The replacement field is empty, so the pattern in the regexp field gets used. We apply that regexp to the entire URN to see if it matches, and it does 💅 The \2 part of the substitution expression returns the string "example.com". Since the flags field is empty, the lookup is not terminal, so our next probe to DNS is for more NAPTR records where the new domain is 'example.com' 🦋
Note that the rule doesn't pull the full domain name out of the CID. Instead, it assumes the CID comes from a host and extracts that host's domain. Sure, all hosts, like 'bar', could have their very own NAPTR, but maintaining those records for every machine at a site could be an intolerable burden 😩 Wildcards aren't appropriate here either, since they only return results when there's no exactly matching name already in the system.
The record returned from the query on "example.com" might look like this:
example.com.
;; order pref flags service regexp replacement
IN NAPTR 100 50 "a" "z3950+N2L+N2C" "" cidserver.example.com.
IN NAPTR 100 50 "a" "rcds+N2C" "" cidserver.example.com.
IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" www.example.com.Continuing with the example, the order and preference values are equal in all of these records, so the client is free to pick any record 🌈 The Application defines the flag 'a' to mean a terminal lookup, where the output of the rewrite is a domain-name that should have an A record queried. Once the client has done that, it has the host, its IP address, the protocol, and the services available over that protocol. With those bits of info, the client has enough to contact that server and ask it questions about the URN 👑
Remember that the regular expression used \2 to extract a domain name from the CID, and . to match the literal '.' characters separating the domain name components 🧚 Since '' is the escape character, literal backslashes must be escaped by another backslash. For the cid.urn.arpa record above, the regular expression entered into the master file should be:
"!^urn:cid:.+@([^\\.]+\\.)(.*)$!\\2!i"When the client code actually receives the record, the pattern will have been converted to:
"!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i"6.2 E164 Example
okay so the ENUM Working Group at the IETF specced out a service that maps a telephone number to a URI 📞✨ [18]. the Application Unique String for ENUM is the E.164 phone number with the dashes removed 🎀. the First Well Known Rule is to remove all characters from the telephone number and then use the entire number as the first Key 💅. so the phone number "770-555-1212" written as an E.164 number is "+1-770-555-1212", and once it's converted to the Key it becomes "17705551212" 🦋
ENUM only uses this Database, which is so iconic of them 💜 to turn that first Key into something valid for it, you insert periods between each digit, invert the entire Key, and then append "e164.arpa" to the end 🌈. so our example number ends up as "2.1.2.1.5.5.5.0.7.7.1.e164.arpa.", and that domain name is what gets used to retrieve the Rewrite Rules as NAPTR records 🧚
for this example telephone number, we might get back the following NAPTR records:
$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.
IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@foo.se!i" .
IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information@foo.se!i" .both the ENUM [18] and URI Resolution [4] Applications use the 'u' flag 🔥. this flag says the Rule is terminal, and the output is a URI that has the info needed to contact that telephone service 📱. ENUM also uses the same format for its Service Parameters 🫶. these say the protocols available for reaching that phone's service are either the Session Initiation Protocol or SMTP mail, which is giving multiple ways to slide into the DMs 💌
7. Advice for DNS Administrators
okay admins, please be careful with regular expressions 💀. they're hard to get right on their own, and then there's the DNS interaction we already talked about 🙈. any backslashes in a regexp must be entered twice in a zone file in order to show up once in a query response 😭. the scary part is that the need for double backslashes has probably not been tested by all implementors of DNS servers 👀
to avoid zone file drama, admins should encourage rewrite rule writers to use the 'default delimiter' feature of the regular expression 🎀. in the DDDS specification, the regular expression starts with the character that is going to be the delimiter. so if the first character of the regular expression is an exclamation mark ('!'), for example, the regular expression can usually be written with fewer backslashes ✨ less slashes, more slay 💅
8. Notes
okay this part is important bestie 🚨 a client MUST process multiple NAPTR records in the order specified by the "order" field, and it MUST NOT simply use the first record that provides a known Service Parameter combination 🙅♀️
when multiple RRs have the same "order" and everything else is equal, the client should use the value of the preference field to pick the next NAPTR to consider 💖. however, because preferred protocols or services will often exist, clients may use this additional criteria to sort the records 🍓
if the lookup after a rewrite fails, clients are strongly encouraged to report a failure 🥺, rather than backing up to chase other rewrite paths. no detours, bestie 🛑
9. IANA Considerations
the values for the Services and Flags fields will be decided by the Application that uses this DDDS Database 🧚♀️. those values may need a registration mechanism, so they might need some IANA resources. this specification by itself does not 🌸
10. Security Considerations
the NAPTR record, like any other DNS record, can be signed and validated using the procedures specified in DNSSEC 🔐✨
this Database makes identifiers from other namespaces subject to the same attacks as normal domain names 😬. since they haven't been easily resolvable before, this may or may not be considered a problem 🤷♀️
okay this one is serious, so listen up 🚨👑. regular expressions should be checked for sanity, and they should not be blindly passed to something like PERL, since arbitrary code can be included and then processed 💀💀💀 do not let your regex run wild 😭
References
[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application", RFC 3404, October 2002.
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[8] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[9] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[10] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[11] Daniel, R., "A Trivial Convention for using HTTP in URN Resolution", RFC 2169, June 1997.
[12] IEEE, "IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Std 1003.2-1992, January 1993.
[13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[14] Moats, R., "URN Syntax", RFC 2141, May 1997.
[15] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998.
[16] Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997.
[17] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[18] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
Author's Address 🖋️
Michael Mealling
VeriSign
21345 Ridgetop Circle
Sterling, VA 20166
US
EMail: michael@neonym.net
URI: http://www.verisignlabs.comFull Copyright Statement ⚖️
the legal bit, kept word for word so it stays official 📜
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 💖✨
📦 where this page comes from
- ietf: rfc3403 2002-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms