Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)
updated by
- rfc-8553 — DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names
Extracted elements (24)
S-NAPTR restricts NAPTR usage to replacement-only rules (no regular expressions) and binds it strictly to domain names, making client resolution more predictable and efficient than full NAPTR. The 'straightforward' restriction also avoids the unintelligible rule-set complexity that makes protocol designers and administrators nervous about general NAPTR.
S-NAPTR was defined instead of relying solely on SRV records because SRV provides only a single layer of indirection and is designed for server administration rather than application naming. S-NAPTR adds a layer from a service label to servers that may be hosted in different administrative domains — a use case SRV cannot serve without modification.
The service parameter separator is ':' rather than '+' (used in RFC 3404 URI DDDS) because S-NAPTR expands the syntax to allow all characters valid in URI scheme names, and '+' is itself a valid URI scheme character and therefore unsuitable as a separator.
Although S-NAPTR uses only a subset of NAPTR record features, this does not imply DNS resolvers should fail to implement all aspects of the NAPTR RR standard. S-NAPTR is a client-use convention (a DDDS application), not a restriction on the DNS infrastructure.
Domain administrators are advised to keep S-NAPTR trees shallow and narrow: fewer branches (fewer NAPTR/SRV records per level) and shallower depth (avoid using NAPTR to rename services within a zone) to limit the cost of tree retrace on failure.
A client MAY choose which protocol to try first based on its own preference or on the PREF ranking in the first NAPTR record set. It MAY run simultaneous DDDS resolutions for more than one protocol, but must not switch protocols mid-resolution for any single resolution chain.
A client MUST backtrack and attempt other resolution paths when failure occurs, including when the remote server fails to provide appropriate security credentials for the originating domain, connection otherwise fails, or the S-NAPTR-designated DNS lookup fails to yield expected results.
A client MUST NOT start S-NAPTR resolution for one protocol, observe that a successive NAPTR RR set supports another preferred protocol, and switch to continuing resolution based on that protocol. The chosen protocol MUST be listed in the first NAPTR RR set for the target domain.
A client supporting multiple protocols MUST pursue S-NAPTR resolution completely for one protocol, exploring all potential terminal lookups in PREF and ORDER ranking, until the application connects successfully or there are no more possibilities for that protocol before trying another protocol.
Application protocol developers using S-NAPTR MUST define the mechanics of the expected server identification handshake when the client connects to a server found through S-NAPTR, to confirm the server's authority for the original target domain.
Application protocol developers using S-NAPTR MUST register relevant application service and application protocol tags with IANA as described in section 7, and MUST document the conditions under which a client should retry a target or declare failure and move to the next target.
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.
NAPTR records retrieved for a target domain MUST be sorted in terms of increasing ORDER and increasing PREF within each ORDER before processing.
Only substitution rules are permitted for S-NAPTR — no regular expressions are allowed in NAPTR records used with this application.
The defining RFC for each registered S-NAPTR tag MUST clearly identify: the application protocol or service tag, intended usage, interoperability considerations, security considerations, and any relevant related publications.
A NAPTR record with an empty FLAG field is non-terminal: the REPLACEMENT field is used as the target of the next DNS lookup for NAPTR RRs. In S-NAPTR, the only valid terminal flags are 'S' (triggers SRV lookup on the REPLACEMENT field) and 'A' (triggers address record lookup on the REPLACEMENT field).
An 'application service' is a generic term for some type of application independent of protocol, associated with an IANA-registered tag. An 'application protocol' implements the application service and is also IANA-registered. The combination of service and protocol tags (e.g., 'RetMail:POP3') is sufficient for a client to identify a compatible server.
S-NAPTR DDDS uses only two flags: 'S' (terminal, REPLACEMENT is target for SRV lookup) and 'A' (terminal, REPLACEMENT is target for address record lookup). Empty flag means non-terminal: look up NAPTR records for the REPLACEMENT target. No other flags are valid.
S-NAPTR (Straightforward NAPTR) is a DDDS Application that maps domain name, application service name, and application protocol to target server and port using NAPTR and SRV DNS resource records. It uses only a subset of NAPTR capabilities: only substitution rules (replacement expressions), not regular expressions.
The Application-Unique String for S-NAPTR is the domain label for which an authoritative server for a particular service is sought. The First Well-Known Rule is identity: the output equals the input domain label, which is used as the key for the first NAPTR DNS lookup.
IANA has established and maintains a registry for S-NAPTR Application Protocol Tags. Each entry records the application protocol tag string (conforming to iana-registered-protocol syntax) and the defining RFC. Tags starting with 'x-' are experimental and uncontrolled; all others require RFC-backed registration.
S-NAPTR-based application protocols MUST define a server identification handshake: the client sends the original (pre-NAPTR-transformation) destination name; the server returns a credential (e.g., X.509 certificate with subjectDN/subjectAltName, or Kerberos service principal); the client verifies the name matches and establishes an integrity-protected channel.
The security of S-NAPTR is only as good as the security of the DNS queries: compromised DNS could redirect clients via bogus NAPTR/SRV records. DNSSEC should be used to ensure validity of DNS records. Applications MUST define end-to-end authentication so clients can verify they reached the correct server regardless of DNS integrity.
Service parameters in S-NAPTR NAPTR records follow the ABNF: service-parms = [[app-service] *(':' app-protocol)], where app-service and app-protocol tags are 1-32 ALPHANUMSYM characters starting with ALPHA. IANA-registered protocols use ALPHA *31ALPHANUM. The separator is ':' (colon), not '+' as used in RFC 3404. Tags are case-insensitive.