This section formally defines the DDDS application, as described in
[4].
6.1. Application-Unique String
The Application Unique String is domain label 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 domain label for which the
authoritative server for a particular service is sought.
6.3. Expected Output
The expected output of this Application is the information necessary
for a client to connect to authoritative server(s) (host, port,
protocol) for a particular application service within a given domain.
6.4. Flags
This DDDS Application uses only 2 of the Flags defined for the URI/
URN Resolution Application ([6]): "S" and "A". No other Flags are
valid.
Both 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 domain label for
which one or more SRV [3] 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.
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 ([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.
Thus, the Service Parameters may consist of an empty string, 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 ([6]). 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 [8]). As "+" (the separator used in the
RFC3404prop 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 Section 7
for instructions on registering new application service tags.
The protocol identifiers valid for the "app-protocol" production are
standard, registered protocols; see section 7 for instructions on
registering new application protocol tags.
Only substitution Rules are permitted for this application. That is,
no regular expressions are allowed.
At present only one DDDS Database is specified for this Application.
[5] specifies that a DDDS Database using the NAPTR DNS resource
record 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
used for the first look up. 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 [5] for more
information on NAPTR records and the Additional Information section
of a DNS response packet.
