RFC 3958
Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)
Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS) 🎀
okay bestie, this is RFC 3958 and it's giving serious spec energy ✨ It came out of the Network Working Group in January 2005 as a Standards Track document, written by L. Daigle and A. Newton of VeriSign, Inc. 💅 The header doesn't list anything it obsoletes or updates, so no drama there 🙈
Status of This Memo 📜
okay so this doc specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 If you want to know where this protocol stands, check the current edition of the "Internet Official Protocol Standards" (STD 1) for its standardization state and status. Distribution of this memo is unlimited, so share it with everyone 💜
Copyright Notice ©️
Copyright (C) The Internet Society (2005). Legally boring, but it's there 🙈
Abstract 🌸
this memo is about a generalized way to name application services so you can find them without leaning on rigid domain naming conventions (aka so-called name hacks 💀). The proposal defines a Dynamic Delegation Discovery System (DDDS) Application that dynamically maps a domain name, an application service name, and an application protocol to a target server and port. It's giving main character energy for service discovery 👑
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Straightforward-NAPTR (S-NAPTR) Specification . . . . . . . . 3
2.1. Key Terms. . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. S-NAPTR DDDS Application Usage . . . . . . . . . . . . . 4
2.2.1. Ordering and Preference. . . . . . . . . . . . . 4
2.2.2. Matching and Non-matching NAPTR Records. . . . . 4
2.2.3. Terminal and Non-terminal NAPTR Records. . . . . 5
2.2.4. S-NAPTR and Successive Resolution. . . . . . . . 5
2.2.5. Clients Supporting Multiple Protocols. . . . . . 6
3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Guidelines for Application Protocol Developers . . . . . 6
3.1.1. Registration of Application Service and
Protocol Tags. . . . . . . . . . . . . . . . . . 7
3.1.2. Definition of Conditions for Retry/Failure . . . 7
3.1.3. Server Identification and Handshake . . . . . . 8
3.2. Guidelines for Domain Administrators . . . . . . . . . . 8
3.3. Guidelines for Client Software Writers . . . . . . . . . 8
4. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Service Discovery within a Domain . . . . . . . . . . . 9
4.3. Multiple Protocols . . . . . . . . . . . . . . . . . . . 10
4.4. Remote Hosting . . . . . . . . . . . . . . . . . . . . . 11
4.5. Sets of NAPTR RRs . . . . . . . . . . . . . . . . . . . 12
4.6. Sample Sequence Diagram . . . . . . . . . . . . . . . . 13
5. Motivation and Discussion . . . . . . . . . . . . . . . . . . 14
5.1. So Why Not Just SRV Records? . . . . . . . . . . . . . . 15
5.2. So Why Not Just NAPTR Records? . . . . . . . . . . . . . 15
6. Formal Definition of <Application Service Location>
Application of DDDS . . . . . . . . . . . . . . . . . . . . . 16
6.1. Application-Unique String . . . . . . . . . . . . . . . 16
6.2. First Well-Known Rule . . . . . . . . . . . . . . . . . 16
6.3. Expected Output . . . . . . . . . . . . . . . . . . . . 16
6.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.5. Service Parameters . . . . . . . . . . . . . . . . . . . 17
6.5.1. Application Services . . . . . . . . . . . . . . 17
6.5.2. Application Protocols . . . . . . . . . . . . . 17
6.6. Valid Rules . . . . . . . . . . . . . . . . . . . . . . 17
6.7. Valid Databases . . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. Application Service Tag IANA Registry . . . . . . . . . 18
7.2. Application Protocol Tag IANA Registry . . . . . . . . . 18
7.3. Registration Process . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
A. Pseudo-pseudocode for S-NAPTR. . . . . . . . . . . . . . . 22
A.1. Finding the First (Best) Target. . . . . . . . . . . 22
A.2. Finding Subsequent Targets . . . . . . . . . . . . . 23
B. Availability of Sample Code. . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 251. Introduction ✨
okay so this memo is the same big idea as the abstract: a generalized mechanism for application service naming that lets you locate a service without relying on rigid domain naming conventions (name hacks, we're not doing those 🙅♀️). It defines a Dynamic Delegation Discovery System (DDDS -- see [4]) Application that dynamically maps a domain name, an application service name, and an application protocol to a target server and port 🦋
As we'll get into in section 5, the existing ways of using DNS records to dynamically figure out the current host for a given application service are kinda limited in the use cases they support 😭 To fix some of that, this doc defines a DDDS Application that maps service+protocol+domain to specific server addresses using both NAPTR [5] and SRV ([3]) DNS resource records. You can think of it as a more general version of using SRV and/or a very restricted use of NAPTR resource records 💖
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 BCP 14, RFC 2119 [1].
2. Straightforward-NAPTR (S-NAPTR) Specification 🎀
the exact details of this DDDS application live in Section 6 🧚 This section is where we cover how the DDDS application is actually used.
2.1. Key Terms 🔑
"Application service" is a generic term for some type of application, no matter which protocol is used to offer it 💅 Each application service gets associated with an IANA-registered tag. Think about retrieving mail: it's an application service that can be built on different application-layer protocols (like POP3 or IMAP4). A tag like "RetMail" could be registered for it. (Note that this hasn't been done, and there are no plans to do so at the time of this writing 🙈)
An "application protocol" is what actually implements the application service, and these also get IANA-registered tags. Going with the mail example, "POP3" and "IMAP4" could be registered as application protocol tags. If the application has multiple transports available, separate tags should be defined for each transport 🌈
The whole point is that a combo of application service and protocol tags should be specific enough that a client can find a known pair and know it's the right server to talk to. Like, "RetMail:POP3" would be enough for a client to identify a server it can actually communicate with ✨
Some protocols support multiple application services. LDAP is an application protocol, and it can show up supporting different services (for example, "whitepages" and "directory enabled networking") 🦋
2.2. S-NAPTR DDDS Application Usage 💜
As section 6 defines, NAPTR records store application service+protocol information for a given domain. Following the DDDS standard, these records get looked up, and the rewrite rules inside the NAPTR records decide which successive DNS lookups happen until a desirable target turns up 🔥
For the rest of this section, we're going to use the set of NAPTR resource records for example.com below as our example. "WP" is the imagined application service tag for "white pages," and "EM" is the application service tag for an imagined "Extensible Messaging" application service 🍓
example.com.
;; order pref flags
IN NAPTR 100 10 "" "WP:whois++" ( ; service
"" ; regexp
bunyip.example. ; replacement
)
IN NAPTR 100 20 "s" "WP:ldap" ( ; service
"" ; regexp
_ldap._tcp.myldap.example.com. ; replacement
)
IN NAPTR 200 10 "" "EM:protA" ( ; service
"" ; regexp
someisp.example. ; replacement
)
IN NAPTR 200 30 "a" "EM:protB" ; service
"" ; regexp
myprotB.example.com.; replacement
)2.2.1. Ordering and Preference 📊
First up, the client grabs all the NAPTR records tied to the target domain name (example.com, in our case). These get sorted by increasing ORDER, and then by increasing PREF within each ORDER 💅
2.2.2. Matching and Non-matching NAPTR Records 🧐
Starting with the first sorted NAPTR record, the client checks the SERVICE field for a match. For the S-NAPTR DDDS application, that means a SERVICE field that includes the tags for the desired application service and a supported application protocol 🫶
If more than one NAPTR record matches, they get processed in increasing sort order 🌸
2.2.3. Terminal and Non-terminal NAPTR Records 🛑
A NAPTR record with an empty FLAG field is "non-terminal," which means more NAPTR RR lookups still need to happen 🔄 So to process a NAPTR record with an empty FLAG field in S-NAPTR, the REPLACEMENT field becomes the target of the next DNS lookup, and that lookup is for NAPTR RRs.
In S-NAPTR, the only terminal flags are "S" and "A" 💀 They're called "terminal" lookups because they mark the end of the DDDS/NAPTR processing rules. With an "S" flag, the REPLACEMENT field becomes the target of a DNS query for SRV RRs, and normal SRV processing kicks in. With an "A" flag, the client looks for an address record for the REPLACEMENT field target, and the default protocol port is assumed 🦋
2.2.4. S-NAPTR and Successive Resolution ✨
okay bestie, remember how one service+protocol pair can have multiple possible targets? 🎀 The client tries them in order until it successfully reaches a server, or until every matching NAPTR record has been chased through terminal lookup and server contact. So if something goes wrong, the client has to backtrack and try another path. that's the whole vibe 💅
A "Failure" is declared, and backtracking must be used, when:
- the designated remote server (host and port) fails to provide appropriate security credentials for the originating domain;
- connection to the designated remote server otherwise fails -- the specifics terms of which are defined when an application protocol is registered; or
- the S-NAPTR-designated DNS lookup fails to yield expected results -- e.g., no A RR for an "A" target, no SRV record for an "S" target, or no NAPTR record with appropriate application service and protocol for a NAPTR lookup.
Here's the tea 🫖 except in the very first NAPTR lookup, that last one is a configuration error. If example.com has a NAPTR record pointing to "bunyip.example" for the "WP:Whois++" service and protocol, it means the example.com admin believes that service exists. So if bunyip.example has no "WP:Whois++" NAPTR record, the application client MUST backtrack and try the next available "WP:Whois++" option from example.com. If there isn't one, the whole resolution fails 😭
An application client always starts by querying for the NAPTR RRs for the domain of a named application service. The first DNS query is for the NAPTR RRs in the original target domain (example.com, above).
2.2.5. Clients Supporting Multiple Protocols 🦋
if an application client supports more than one protocol for a given application service, it MUST pursue S-NAPTR resolution completely for one protocol. That means exploring all potential terminal lookups in PREF and ORDER ranking, until the app connects successfully or there are no more possibilities for that protocol.
So the client MUST NOT start looking for one protocol, notice that a successive NAPTR RR set supports another one of its preferred protocols, and then keep resolving based on that second protocol. For example, even if someisp.example offers the "EM" service with protocol "ProtB", there's no reason to believe it does so on behalf of example.com. There's no such pointer in example.com's NAPTR RR set, so it's not giving legit 🙅♀️
The client MAY choose which protocol to try first, based on its own preference or on the PREF ranking in the first set of NAPTR records (the ones for the target named domain). However, the chosen protocol MUST be listed in that first NAPTR RR set.
The client MAY also choose to run simultaneous DDDS resolutions for more than one protocol. If it does, the requirements above apply to each protocol independently. Just don't switch protocols mid-resolution, bestie 🙈
3. Guidelines 🧚
3.1. Guidelines for Application Protocol Developers 🍓
3.1.1. Registration of Application Service and Protocol Tags 🏷️
Application protocol developers who want to use S-NAPTR must make provisions for registering any relevant application service and application protocol tags, as described in section 7.
3.1.2. Definition of Conditions for Retry/Failure 🔁
Another important thing to define is how the client should behave when it interacts with servers reached via S-NAPTR. Specifically, under what circumstances should the client retry a target that was found via S-NAPTR? And what should count as a failure that sends it back to the S-NAPTR process to find the next serviceable target? That next target will, by definition, have a lower preference ranking.
For example, if the client gets a "connection refused" message from a server, should it retry for some (protocol-dependent) period of time? Or should it just try the next-preferred target in the S-NAPTR chain? Should it only move on if it gets a protocol-specific permanent error message?
The most important thing is to pick one expected behaviour and document it as part of the use of S-NAPTR 💖
As noted earlier, failing to provide appropriate credentials to show the server is authoritative for the original target domain is always considered a failure condition 🚨
3.1.3. Server Identification and Handshake 🤝
As noted in section 8, using the DNS for server location makes it more important to use protocol-specific handshakes to determine and confirm the identity of the server that's eventually reached.
So application protocol developers using S-NAPTR should identify the mechanics of the expected identification handshake when the client connects to a server found through S-NAPTR 🫶
3.2. Guidelines for Domain Administrators 👑
Even though S-NAPTR aims to be a "straightforward" application of DDDS and NAPTR records, it's still possible to create very complex chains and dependencies with NAPTR and SRV records. Yikes 💀
So domain administrators are called upon to use S-NAPTR with as much restraint as possible, while still achieving their service design goals.
Think of all the NAPTR, SRV, and A RRs "reachable" through the S-NAPTR process for a particular application service as a "tree". Each NAPTR RR that gets retrieved points to more NAPTR or SRV records, and each SRV record points to several A record lookups. A client can "prune" the tree so it only uses records for application protocols it supports, but the tree can still get pretty deep. Retracing it to retry other targets gets expensive if there are lots of branches 🌳
Therefore:
- fewer branches is better: For both NAPTR and SRV records, provide different targets with varying preferences where appropriate (e.g., to provide backup services), but don't look for reasons to provide more; and
- shallower is better: Avoid using NAPTR records to "rename" services within a zone. Use NAPTR records to identify services hosted elsewhere (i.e., where you cannot reasonably provide the SRV records in your own zone).
3.3. Guidelines for Client Software Writers 💜
To understand DDDS/NAPTR properly, an implementor must read [4]. But the most important thing to keep in mind is this: if the application can't connect to one target, it's expected to keep going through the S-NAPTR tree to try the (less preferred) alternatives 🔥
4. Illustrations 🌈
4.1. Use Cases 📦
The basic intended use cases for S-NAPTR are:
- Service discovery within a domain. For example, this can be used to find the "authoritative" server for some type of service within a domain (see the specific example in section 4.2).
- Multiple protocols. This is already common today as new application services get defined, and it's increasingly a problem. It includes the case of extensible messaging (a hypothetical service), which can be offered with multiple protocols (see section 4.3).
- Remote hosting. Each of the above use cases applies within the administration of a single domain. However, one domain operator may choose to engage another organization to provide an application service. See section 4.4 for an example that can't be served by SRV records alone 🛰️
4.2. Service Discovery within a Domain 🔍
Sometimes it's really useful to determine the "authoritative" server for a given application service within a domain. This is "discovery", because there's no a priori knowledge of whether or where the service is offered. So it's important to figure out the location and characteristics of the offered service ✨
For example, there's growing discussion about having a generic mechanism for locating the keys or certificates associated with particular application (servers) operated in (or for) a particular domain. The following is a hypothetical case for storing application key or certificate data for a given domain. The premise is that a credentials registry (CredReg) service has been defined as a leaf node service holding the keys/certs for the servers operated by (or for) the domain. It's assumed that more than one protocol is available to provide the service for a particular domain. This DDDS-based approach is used to find the CredReg server that holds the information 🔐
So the set of NAPTR records for thinkingcat.example might look like this:
thinkingcat.example.
;; order pref flags
IN NAPTR 100 10 "" "CREDREG:ldap:iris.beep" ( ; service
"" ; regexp
theserver.thinkingcat.example. ; replacementNote that the application service might be offered in another domain using a different set of application protocols:
anotherdomain.example.
;; order pref flags
IN NAPTR 100 10 "" "CREDREG:iris.lwz:iris.beep" ( ; service
"" ; regexp
foo.anotherdomain.example. ; replacement
)4.3. Multiple Protocols ✨
okay so bestie, meet extensible messaging 💖, a totally hypothetical application service we're using for examples. (If you want a real application service with multiple protocols, check out [9] and [10] 🦋.) Assuming "EM" got registered as an application service, this DDDS app could figure out which services are available for delivering to a target 🎀
Two features of this hypothetical extensible messaging are giving main character energy, so note them ✨:
- Gatewaying is expected to bridge communications across protocols.
- Extensible messaging servers are likely to be operated out of a different domain than that of the extensible messaging address, and servers of different protocols may be offered by independent organizations.
For example, "thinkingcat.example" may run its own servers for the "ProtA" extensible messaging protocol but rely on outsourcing from "example.com" for "ProtC" and "ProtB" servers 🫶
With this DDDS-based approach, thinkingcat.example can set a preference ranking for the different types of servers for the extensible messaging service, and the out-sourcer can independently rank and order its own servers 💅. This independence is literally not achievable with SRV records alone 😭
So to find the EM services for thinkingcat.example, we grab the NAPTR records for thinkingcat.example 🌸:
thinkingcat.example.
;; order pref flags
IN NAPTR 100 10 "s" "EM:ProtA" ( ; service
"" ; regexp
_ProtA._tcp.thinkingcat.example. ; replacement
)
IN NAPTR 100 20 "s" "EM:ProtB" ( ; service
"" ; regexp
_ProtB._tcp.example.com. ; replacement
)
IN NAPTR 100 30 "s" "EM:ProtC" ( ; service
"" ; regexp
_ProtC._tcp.example.com. ; replacement
)Then the admins at example.com can manage the preference rankings of the servers they use to support the ProtB service 🍓:
_ProtB._tcp.example.com.
;; Pref Weight Port Target
IN SRV 10 0 10001 bigiron.example.com.
IN SRV 20 0 10001 backup.em.example.com.
IN SRV 30 0 10001 nuclearfallout.australia-isp.example.4.4. Remote Hosting 🧚
In the Instant Message hosting example in Section 4.3, the service owner (thinkingcat.example) had to host pointers to the hosting service's SRV records in the thinkingcat.example domain 😩.
A better approach is to have one NAPTR RR in the thinkingcat.example domain point to all the hosted services 👑. The hosting domain has NAPTR records for each service to map them to whatever local hosts it chooses (this may change from time to time) 🌈.
thinkingcat.example.
;; order pref flags
IN NAPTR 100 10 "s" "EM:ProtA" ( ; service
"" ; regexp
_ProtA._tcp.thinkingcat.example. ; replacement
)
IN NAPTR 100 20 "" "EM:ProtB:ProtC" ( ; service
"" ; regexp
thinkingcat.example.com. ; replacement
)Then the administrators at example.com can break out the individual application protocols and manage the preference rankings of the servers they use to support the ProtB service (as before) 💅:
thinkingcat.example.com.
;; order pref flags
IN NAPTR 100 10 "s" "EM:ProtC" ( ; service
"" ; regexp
_ProtC._tcp.example.com. ; replacement
)
IN NAPTR 100 20 "s" "EM:ProtB" ( ; service
"" ; regexp
_ProtB._tcp.example.com. ; replacement
)
_ProtC._tcp.example.com.
;; Pref Weight Port Target
IN SRV 10 0 10001 bigiron.example.com.
IN SRV 20 0 10001 backup.em.example.com.
IN SRV 30 0 10001 nuclearfallout.australia-isp.example.4.5. Sets of NAPTR RRs 🎀
Note that the sections above assume there was one service available (via S-NAPTR) per domain. Often, that won't be the case 🙈. Let's say thinkingcat.example had the CredReg service set up as described in Section 4.2 and had the extensible messaging service set up as described in Section 4.4. Then a client querying for the NAPTR RR set from thinkingcat.com would get this answer:
thinkingcat.example.
;; order pref flags
IN NAPTR 100 10 "s" "EM:ProtA" ( ; service
"" ; regexp
_ProtA._tcp.thinkingcat.example. ; replacement
)
IN NAPTR 100 20 "" "EM:ProtB:ProtC" ( ; service
"" ; regexp
thinkingcat.example.com. ; replacement
)
IN NAPTR 200 10 "" "CREDREG:ldap:iris-beep" ( ; service
"" ; regexp
bouncer.thinkingcat.example. ; replacement
)Sorting them by increasing "ORDER", the client would look through the SERVICE strings to see whether there's a NAPTR RR that matches the application service it's looking for, with an application protocol it can use 🔥. The client would use the first (lowest PREF) record that matched to continue 💖.
4.6. Sample sequence diagram 🦋
Let's look at the example in section 4.3 👀. Visually, the sequence of steps the client takes to reach the final server for a "ProtB" service for EM for the thinkingcat.example domain looks like this:
Client NS for NS for
thinkingcat.example example.com backup.em.example.com
| | |
1 -------->| | |
2 <--------| | |
3 ------------------------------>| |
4 <------------------------------| |
5 ------------------------------>| |
6 <------------------------------| |
7 ------------------------------>| |
8 <------------------------------| |
9 ------------------------------------------------->|
10 <-------------------------------------------------|
11 ------------------------------------------------->|
12 <-------------------------------------------------|
(...)- The name server (NS) for thinkingcat.example is reached with a request for all NAPTR records.
- The server responds with the NAPTR records shown in section 4.3.
- The second NAPTR record matches the desired criteria. It has an "s" flag and a replacement field of "_ProtB._tcp.example.com". So the client looks up SRV records for that target, ultimately making the request of the NS for example.com 🫶.
- The response includes the SRV records listed in Section 4.3.
- The client attempts to reach the server with the lowest PREF in the SRV list, looking up the A record for the SRV record's target (bigiron.example.com).
- The example.com NS responds with an error message: no such machine! 💀
- The client attempts to reach the second server in the SRV list and looks up the A record for backup.em.example.com.
- The client gets the A record with the IP address for backup.em.example.com from example.com's NS.
- The client connects to that IP address, on port 10001 (from the SRV record), by using ProtB over tcp 🔌.
- The server responds with an "OK" message ✨.
- The client uses ProtB to challenge that this server has credentials to operate the service for the original domain (thinkingcat.example) 🔐.
- The server responds, and the rest is EM 🎉.
5. Motivation and Discussion 💜
Application protocol standards are increasingly using domain names to identify server targets, and they stipulate that clients should look up SRV resource records to determine the host and port providing the server. This makes it possible to tell apart naming an application service target and actually hosting the server. It also adds flexibility in hosting the target service, like so 🌸:
- The server may be operated by a completely different organization without having to list the details of that organization's DNS setup (SRVs).
- Multiple instances can be set up (e.g., for load balancing or secondaries).
- It can be moved from time to time without disrupting clients' access, etc.
This approach is quite useful, but section 5.1 outlines some of its inherent limitations 🙃.
Here's the deal: although SRV records can map from a specific service name and protocol for a specific domain to a specific server, SRV records are limited to one layer of indirection and are focused on server administration rather than on application naming 😤. Furthermore, although the DDDS specification and use of NAPTR allow multiple levels of redirection before the target server machine with an SRV record is located, this proposal requires only a subset of NAPTR strictly bound to domain names, without making use of the REGEXP field of NAPTR. These restrictions make the client's resolution process much more predictable and efficient than it would be with some potential uses of NAPTR records 🧠. This is dubbed "S-NAPTR" — a "S"traightforward use of NAPTR records ✨.
5.1. So Why Not Just SRV Records? 🤔
An expected question at this point is: this is so similar in structure to SRV records, so why are we doing this with DDDS/NAPTR? 👀
Limitations of SRV include the following:
- SRV provides a single layer of indirection; the outcome of an SRV lookup is a new domain name for which the A RR is to be found.
- The purpose of SRV is to address individual server administration issues, not to provide application naming: As stated in [3], "The SRV RR allows administrators to use several servers for a single domain, to move services from host to host with little fuss, and to designate some hosts as primary servers for a service and others as backups".
- Target servers by "service" (e.g., "ldap") and "protocol" (e.g., "tcp") in a given domain. The definition of these terms implies specific things (e.g., that protocol should be one of UDP or TCP) without being precise. Restriction to UDP and TCP is insufficient for the uses described here 🙄.
The basic answer is that SRV records provide mappings from protocol names to host and port. The use cases described here need an additional layer, from some service label to servers that may in be hosted within different administrative domains. We could tweak SRV to say that the next lookup could be something other than an address record, but that's more complex than most applications of SRV need 💅.
5.2. So Why Not Just NAPTR Records? 🤔
Okay, this is a trick question 🙃 NAPTR records cannot show up in the wild, see [4]. They must be part of a DDDS application, bestie.
The whole point here is to create one shared mechanism, the DDDS application, for when you just want simple DNS-based location of services and want to use NAPTR for it. Applications should find it easy to use: a few simple IANA registrations and you're done ✨
NAPTR also has super powerful tools for writing "rewrite" rules, but that power is basically the same thing as complexity 💀 Some protocol designers and service admins get nervous about it. The worry is that these rewrites can turn into unintelligible, noodle-like rule sets that are hard to test and hard to administer 🍝
So the proposed DDDS application only uses a subset of NAPTR's abilities. Only "replacement" expressions are allowed, and "regular expressions" are not 💅
6. Formal Definition of <Application Service Location> Application of DDDS 🎀
This section formally defines the DDDS application, the one described in [4]. Let's get into it 🦋
6.1. Application-Unique String
The Application Unique String is a domain label. It's the label that an authoritative server for a particular service is being looked up for 🔍
6.2. First Well-Known Rule
The "First Well-Known Rule" is identity. The output of the rule is the Application-Unique String, which is the domain label whose authoritative server for a particular service is being sought 🪞
6.3. Expected Output
The expected output of this Application is the info a client needs to connect to the authoritative server(s) for a particular application service within a given domain. That means the host, the port, and the protocol 🧚
6.4. Flags
This DDDS Application only uses 2 of the Flags defined for the URI/URN Resolution Application ([6]): "S" and "A". No other Flags are valid, so don't try 🙅♀️
Both of these are for terminal lookups. That means the Rule is the last one, and the flag decides what the next stage is. The "S" flag means the output of this Rule is a domain label that has one or more SRV [3] records. "A" means the output of the Rule is a domain name, and it should be used to look up address records for that domain 🌸
Following the DDDS algorithm, if the Flag string is empty, the next lookup is for another NAPTR record, the one for the replacement target 🔁
6.5. Service Parameters
Service Parameters for this Application take the form of a string of characters that follows this ABNF ([2]):
service-parms = [ [app-service] *(":" app-protocol)]
app-service = experimental-service / iana-registered-service
app-protocol = experimental-protocol / iana-registered-protocol
experimental-service = "x-" 1*30ALPHANUMSYM
experimental-protocol = "x-" 1*30ALPHANUMSYM
iana-registered-service = ALPHA *31ALPHANUMSYM
iana-registered-protocol = ALPHA *31ALPHANUM
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
SYM = %x2B / %x2D / %x2E ; "+" / "-" / "."
ALPHANUMSYM = ALPHA / DIGIT / SYM
; The app-service and app-protocol tags are limited to 32
; characters and must start with an alphabetic character.
; The service-parms are considered case-insensitive.So the Service Parameters can be an empty string, an app-service, or an app-service with one or more app-protocol specs separated by the ":" symbol. Cute and tidy 💖
This is similar to, but not the same as, the syntax used in the URI DDDS application ([6]). The DDDS DNS database needs every DDDS application to define the syntax of its allowed service strings. The syntax here is expanded so it can use the characters that are valid in any URI scheme name (see [8]). Since "+" is the separator used in the RFC3404 service parameter string and it's an allowed character for URI scheme names, ":" was picked as the separator here 🎀
6.5.1. Application Services
The "app-service" must be an IANA-registered service. For instructions on registering new application service tags, see Section 7 🪪
6.5.2. Application Protocols
The protocol identifiers that are valid for the "app-protocol" production are standard, registered protocols. For instructions on registering new application protocol tags, see section 7 📋
6.6. Valid Rules
Only substitution Rules are permitted for this application. That means no regular expressions are allowed 🚫
6.7. Valid Databases
Right now, only one DDDS Database is specified for this Application. [5] says that a DDDS Database using the NAPTR DNS resource record holds the rewrite rules. The Keys for this database are encoded as domain-names 🗂️
The First Well-Known Rule produces a domain name, and that's the Key used for the first lookup. The NAPTR records for that domain are requested 📨
DNS servers MAY interpret Flag values and use that info to include appropriate NAPTR, SRV, or A records in the Additional Information portion of the DNS packet. Clients are encouraged to check for additional information, but they're not required to. For more on NAPTR records and the Additional Information section of a DNS response packet, see the Additional Information Processing section of [5] 🌈
7. IANA Considerations 🗂️
This document calls for two IANA registries: one for application service tags, and one for application protocol tags 💜
7.1. Application Service Tag IANA Registry
IANA has set up a registry for S-NAPTR Application Service Tags and will keep it going. Each tag gets at least the following info:
- Application Service Tag: A string that conforms with the IANA-registered-service defined in section 6.5.
- Defining publication: The RFC used to define the Application Service Tag, as defined in the registration process below.
The initial Application Service Tag registration is in [9] 🌷
7.2. Application Protocol Tag IANA Registry
IANA has set up a registry for S-NAPTR Application Protocol Tags and will keep it going. Each tag gets at least the following info:
- Application Protocol Tag: A string that conforms with the iana-registered-protocol defined in section 6.5.
- Defining publication: The RFC used to define the Application Protocol Tag, as defined in the registration process below.
The initial Application Protocol Tag registration is defined in [10] 🍓
7.3. Registration Process
Any application service or protocol tag that starts with "x-" is considered experimental. No provision is made to stop duplicate use of the same string, so implementors use them at their own risk 🧪
All other application service and protocol tags are registered using the "specification required" option defined in [7], with the extra condition that the "specification" is an RFC (of any category) 📜
No further restrictions are placed on the tags, except that they must conform with the syntax defined below (Section 6.5) ✅
The defining RFC must clearly identify and describe, for each tag being registered:
- application protocol or service tag,
- intended usage,
- interoperability considerations,
- security considerations (see section 8 of this document for further discussion of the types of considerations that are applicable), and
- any relevant related publications.
8. Security Considerations 🔐
Okay, this part is serious, so listen up 👀 The security of this approach to application service location is only as good as the security of the DNS queries along the way. If any one of them gets compromised, bogus NAPTR and SRV records could be inserted to redirect clients to unintended destinations 😱 This problem is hardly unique to S-NAPTR (or to NAPTR in general). A full discussion of the security threats for DNS can be found in [11] 📚
To protect against DNS-vectored attacks, secured DNS (DNSSEC) [12] can be used to make sure the DNS records received are valid 🛡️
Whether or not DNSSEC is used, applications should define some form of end-to-end authentication to make sure the correct destination has been reached. Lots of application protocols, such as HTTPS, BEEP, and IMAP, already define the handshake mechanisms needed to do this. Newly defined application protocols should think about this and include appropriate mechanisms 🫶
The basic mechanism works like this:
- During some part of the protocol handshake, the client sends the server the original name of the desired destination. That means no transformations from NAPTR replacements, SRV targets, or CNAME changes. In cases where the application protocol doesn't have such a feature but TLS may be used, it's possible to use the "server_name" TLS extension.
- The server sends the client a credential with the appropriate name. For X.509 certificates, the name would be in either the subjectDN or the subjectAltName field. For Kerberos, the name would be a service principle name.
- Using the matching semantics defined by the application protocol, the client compares the name in the credential with the name it sent to the server.
- If the names match and the credentials have integrity, there's reasonable assurance that the correct end point has been reached.
- The client and server set up an integrity-protected channel 🔒
Note that this document does not define the handshake mechanism, the specific credential naming fields, or the name-matching semantics. Definitions of S-NAPTR for particular application protocols MUST define these 🙏
9. Acknowledgements 💖
Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd, and Ted Hardie for the discussion and input that (hopefully!) provoked the clarifying revisions in this document 🥹✨
10. References 📚
10.1. Normative References
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
- [3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
- [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
- [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
- [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
- [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
10.2. Informative References
- [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
- [9] Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS)", RFC 3982, January 2005.
- [10] Newton, A. and M. Sanz, "Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)", RFC 3983, January 2005.
- [11] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name System", Work in Progress, April 2004.
- [12] Arends, R., Larson, M., Austein, R., and D. Massey, "Protocol Modifications for the DNS Security Extensions", Work in Progress, May 2004.
Appendix A. Pseudo-Pseudocode for S-NAPTR ✨
A.1. Finding the First (Best) Target 🎯
Okay so, assuming the client supports 1 protocol for a particular application service, this pseudocode walks through how the client finds its first (best) target using S-NAPTR. It's giving step-by-step main character energy 💅
target = [initial domain]
naptr-done = false
while (not naptr-done)
{
NAPTR-RRset = [DNSlookup of NAPTR RRs for target]
[sort NAPTR-RRset by ORDER, and PREF within each ORDER]
rr-done = false
cur-rr = [first NAPTR RR]
while (not rr-done)
if ([SERVICE field of cur-rr contains desired application
service and application protocol])
rr-done = true
target= [REPLACEMENT target of NAPTR RR]
else
cur-rr = [next rr in list]
if (not empty [FLAG in cur-rr])
naptr-done = true
}
port = -1
if ([FLAG in cur-rr is "S"])
{
SRV-RRset = [DNSlookup of SRV RRs for target]
[sort SRV-RRset based on PREF]
target = [target of first RR of SRV-RRset]
port = [port in first RR of SRV-RRset]
}
; now, whether it was an "S" or an "A" in the NAPTR, we
; have the target for an A record lookup
host = [DNSlookup of target]
return (host, port)A.2. Finding Subsequent Targets 🔁
Okay, so the pseudocode in Appendix A is built to find the first, most preferred host-port pair for a particular application service and protocol. But if that pair doesn't work for any reason (connection refused, application-level error), the client is expected to just try the next host-port in the S-NAPTR tree 🫶
Here's the tea 🍵: the pseudocode above doesn't allow retries. Once it's done, it sheds all context of where it finished in the S-NAPTR tree. So client software writers could:
- entwine the application-specific protocol with the DNS lookup and RRset processing from the pseudocode, and keep the S-NAPTR processing going if the application code fails to connect to a located host-port pair;
- use callbacks for the S-NAPTR processing; or
- use an S-NAPTR resolution routine that finds all valid servers for the required application service and protocol from the originating domain, and hands them over in a sorted order for the application to try 🌈
Appendix B. Availability of Sample Code 💜
Sample Python code for S-NAPTR resolution is available at http://www.verisignlabs.com/pysnaptr-0.1.tgz ✨
Authors' Addresses 🎀
Meet the authors, bestie 🦋
Leslie Daigle
VeriSign, Inc.
21355 Ridgetop Circle
Dulles, VA 20166
US
EMail: leslie@verisignlabs.com; leslie@thinkingcat.comAndrew Newton
VeriSign, Inc.
21355 Ridgetop Circle
Dulles, VA 20166
US
EMail: anewton@verisignlabs.comFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2005).
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. It also doesn't claim to have made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, 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 send that information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🙏
Funding for the RFC Editor function is currently provided by the Internet Society. 🌸
📦 where this page comes from
- ietf: rfc3958 2005-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms