Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)
Extracted elements (18)
The limited regular expression form ('!.*!<URI>!') is a deliberate workaround because the NAPTR REPLACEMENT field is required to produce only a fully qualified domain name and cannot hold a URI. By encoding the URI in a fixed-string regex, U-NAPTR avoids that constraint without requiring full regex engine support.
The service parameter syntax uses ':' as separator rather than '+' (as in RFC 3404 URI DDDS) because '+' is a valid character in URI scheme names. Since U-NAPTR service tags may correspond to URI schemes, using '+' as a separator would create ambiguity.
U-NAPTR is defined as an extension of S-NAPTR specifically to allow URIs as DDDS resolution targets. S-NAPTR rules out regular expressions in NAPTR records, which also rules out providing a URI as the target — a restriction too limiting for several applications that need URI-based service location.
U-NAPTR is defined as a separate DDDS application from S-NAPTR and is not an update to S-NAPTR. Implementations supporting U-NAPTR must recognize the 'U' flag and the limited regex form; pure S-NAPTR implementations will not process 'U'-flagged NAPTR records correctly.
DNS servers MAY interpret flag values and 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.
The 'app-service' value in service parameters MUST be an IANA-registered service tag. Similarly, 'app-protocol' values must be standard, registered protocol identifiers.
The RFC registering a new application service or protocol tag MUST clearly identify and describe: the tag itself, intended usage, interoperability considerations, security considerations, and any relevant related publications.
U-NAPTR uses only three flags: 'S', 'A', and 'U'. If a client obtains a NAPTR RR containing any other flag, that record should be ignored and processing continues with the next record.
When the 'U' flag is present in a NAPTR record under U-NAPTR, the REGEXP field MUST be populated and the REPLACEMENT field must be empty. The regular expression must match the limited form defined in Section 2.2.
Flag semantics: 'S' means the output is an FQDN for which SRV records exist; 'A' means the output is a domain name for address lookup; 'U' means the output is a URI to be resolved for service access. An empty flag means the next lookup is for another NAPTR record.
The Application Unique String for U-NAPTR 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 — the output equals the input FQDN.
The expected output of U-NAPTR resolution is the information needed to connect to authoritative server(s) — host, port, protocol, or URI — for an application service within a given domain.
U-NAPTR permits the same flags as S-NAPTR ('S', 'A', or empty) plus the 'U' flag. The 'U' flag signals that the REGEXP field contains a URI-producing regular expression and that REPLACEMENT is empty.
U-NAPTR (Straightforward URI-Enabled NAPTR) is a DDDS application that maps domain names to URIs for particular application services and protocols. It extends S-NAPTR by permitting the 'U' flag and a specific limited form of REGEXP that produces a URI as the resolution result.
U-NAPTR uses the existing IANA registries for application service tags and application protocol tags defined in RFC 3958 (S-NAPTR). Tags starting with 'x-' are experimental with no duplicate-use prevention. All other tags require an RFC as the specification (any category), registered under the 'specification required' policy.
U-NAPTR inherits the security considerations of S-NAPTR (RFC 3958 Section 8). Additionally, resolving URIs obtained from DDDS resolution carries its own security implications per the URI specification (RFC 3986 Section 7). Using DNSSEC, clients can be confident the URI is as specified by the domain administrator, but validity of the service reached by resolving that URI depends on URI resolution security practices.
Service parameters follow the ABNF: service-parms = [ [app-service] *(':' app-protocol)]. Tags are limited to 32 characters, must start with an alphabetic character, and are case-insensitive. The separator ':' is used instead of '+' (used in RFC 3404) because '+' is a valid URI scheme character.
The U-NAPTR regular expression (u-naptr-regexp) is restricted to the form '!.*!<URI>!' where <URI> is a constant URI string as defined in STD 66. This complete-replacement form avoids the need for full regex parsers in U-NAPTR clients.