1. Introduction

   This memo defines a generalized mechanism for application service
   naming that allows service location without relying on rigid domain
   naming conventions (so-called name hacks).  The proposal defines a
   Dynamic Delegation Discovery System (DDDS -- see [4]) Application to
   map domain name, application service name, and application protocol
   dynamically to target server and port.

   As discussed in section 5, existing approaches to using DNS records
   for dynamically determining the current host for a given application
   service are limited in terms of the use cases supported.  To address
   some of the limitations, this document defines a DDDS Application to
   map service+protocol+domain to specific server addresses by using
   both NAPTR [5] and SRV ([3]) DNS resource records.  This can be
   viewed as a more general version of the use of SRV and/or a very
   restricted application of the 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].