Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)

The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols. This allows the "lookup" of particular services available for given domains, for example. Although this is defining a new and separate DDDS application, dubbed U-NAPTR, it is built from the same principles as the Straightforward NAPTR (S-NAPTR) application, specified in . This specification is not an update of S-NAPTR, but the reader is encouraged to review that document for extensive coverage of motivation and implementation considerations. S-NAPTR provides for application service location that does not rely on rigid domain naming conventions. It is deemed "straightforward" in part because it rules out the use of regular expressions in NAPTR records (for the S-NAPTR DDDS Application). However, that also rules out the possibility of providing a URI as the target of DDDS resolution. A number of applications, specified (e.g., ) and proposed, find the restriction too limiting, making S-NAPTR a near miss to suit their needs. This U-NAPTR is effectively a modest extension to S-NAPTR, to accommodate the use of URIs as targets, without allowing the full range of possible regular expressions in NAPTR records.

This document assumes the reader is familiar with the S-NAPTR specification . The intention of U-NAPTR is to provide everything that S-NAPTR does, except that it allows the use of the "U" flag in the NAPTR record, and a specific form of REGEXP.

U-NAPTR permits the same flags as S-NAPTR ("S", "A", or empty), plus the "U" Flag. For the U-NAPTR DDDS Application, the presence of the "U" Flag in the NAPTR record indicates the REGEXP field must be populated (and, consequently, the REPLACEMENT field is empty). The regular expression in the REGEXP field must be of the limited form described below, and the result of the regular expression evaluation will be a URI that is the result of the DDDS resolution.

U-NAPTR permits regular expressions of a form that does a complete replacement of the matched string with a URI, expressed as a constant string. This is essentially a dodge around the fact that the REPLACEMENT field in NAPTR is required to produce only a fully qualified domain name (and, therefore, cannot be used for a URI). The specific allowed syntax for U-NAPTR regular expressions is:

u-naptr-regexp = "!.*!"<URI>"!" where <URI> is as defined in STD 66 , the URI syntax specification. With this limited form of regular expression, applications using U-NAPTR need not implement full regular expression parsers.

In the sample NAPTR RRs for example.com shown below, "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.com. ; replacement ) IN NAPTR 100 20 "s" "WP:ldap" ( ; service "" ; regexp _ldap._tcp.myldap.example.com. ; replacement ) IN NAPTR 200 10 "u" "EM:protA" ( ; service "!.*!prota://someisp.example.com!" ; regexp "" ; replacement ) IN NAPTR 200 30 "a" "EM:protB" ; service "" ; regexp myprotB.example.com.; replacement )

This section formally defines the DDDS application, as described in .

The Application Unique String is a fully qualified domain name (FQDN) for which an authoritative server for a particular service is sought.

The "First Well Known Rule" is identity -- that is, the output of the rule is the Application Unique String, the FQDN for which the authoritative server for a particular service is sought.

The expected output of this Application is the information necessary to connect to authoritative server(s) (host, port, protocol, or URI) for an application service within a given domain.

This DDDS Application uses only 3 of the Flags defined for the URI/URN Resolution Application : "S", "A", and "U". No other Flags are valid. If a client obtains a NAPTR RR for a U-NAPTR-using application that contains any other flag, that NAPTR RR should be ignored and processing continues with the next record (if any). These flags are for terminal lookups. This means that the Rule is the last one and that the flag determines what the next stage should be. The "S" flag means that the output of this Rule is a FQDN for which one or more SRV records exist. "A" means that the output of the Rule is a domain name and should be used to lookup address records for that domain. "U" means that the output of the Rule is a URI that should be resolved in order to obtain access to the described service. Consistent with the DDDS algorithm, if the Flag string is empty the next lookup is for another NAPTR record (for the replacement target).

Service Parameters for this Application take the form of a string of characters that follow this ABNF :

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 *31ALPHANUMSYM 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. Thus, the Service Parameters may consist of an empty string, just an app-service, or an app-service with one or more app-protocol specifications separated by the ":" symbol. Note that this is similar to, but not the same as the syntax used in the URI DDDS application . The DDDS DNS database requires each DDDS application to define the syntax of allowable service strings. The syntax here is expanded to allow the characters that are valid in any URI scheme name (see ). Since "+" (the separator used in the RFC3404 service parameter string) is an allowed character for URI scheme names, ":" is chosen as the separator here.

The "app-service" must be an IANA-registered service; see for instructions on registering new application service tags.

The protocol identifiers that are valid for the "app-protocol" production are standard, registered protocols; see for instructions on registering new application protocol tags.

Permitted rules are substitution rules and regular expressions of the following syntax (i.e., a regular expression to replace the domain name with a URI):

u-naptr-regexp = "!.*!"<URI>"!" where <URI> is as defined in STD 66 , the URI syntax specification.

At present, only one DDDS Database is specified for this Application. specifies a DDDS Database that uses the NAPTR DNS resource record to contain the rewrite rules. The Keys for this database are encoded as domain names. The First Well Known Rule produces a domain name, and this is the Key that is used for the first lookup -- the NAPTR records for that domain are requested. DNS servers MAY interpret Flag values and use that information 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 are not required to do so. See the Additional Information Processing section of for more information on NAPTR records and the Additional Information section of a DNS response packet.

This document does not itself place any requirements on IANA, but provides the basis upon which U-NAPTR-using services can make use of the existing IANA registries for application service tags and application protocol tags (defined in RFC 3958 ). As is the case for S-NAPTR, all application service and protocol tags that start with "x-" are considered experimental, and no provision is made to prevent duplicate use of the same string. Use them at your own risk. All other application service and protocol tags are registered based on the "specification required" option defined in , with the further stipulation that the "specification" is an RFC (of any category). There are no further restrictions placed on the tags other than that they must conform with the syntax defined above (). 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 of this document for further discussion of the types of considerations that are applicable) Any relevant related publications The defining RFC may also include further application-specific restrictions, such as limitations on the types of URIs that may be returned for the application service.

U-NAPTR has the same considerations for security as S-NAPTR; see Section 8 of . U-NAPTR has the additional consideration that resolving URIs (from the result of the DDDS resolution) has its own set of security implications, covered in the URI specification (in particular, Section 7 of ). In essence, using DNSSEC, client software can be confident that the URI obtained using U-NAPTR is indeed the one specified by the administrator of the domain from which it was retrieved; but the validity of the service reached by resolving that URI is a matter of URI resolution security practices.

Thanks to Martin Thomson, John Klensin, Bernard Aboba, Alfred Hoenes, Dan Romascanu, Suresh Krishnan, and Lars Eggert for reviewing earlier versions and catching errors!