Internet-Draft J. Snell draft-snell-dnsepd-01.txt A. Donoho Expires: May 23, 2005 IBM November 2004 DNS Endpoint Discovery (DNS-EPD) Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 23, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo introduces two new DNS Resource Record types for the DNS-based discovery of Web service endpoints. Snell & Donoho Expires: May 23, 2005 [Page 1] Internet-Draft DNS-EPD November 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Bootstrapping Web service infrastructure . . . . . . . . . 3 1.2 Mapping Web service artifacts into the domain name space . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. DNS-EPD Resource records . . . . . . . . . . . . . . . . . . . 5 2.1 Establishment of DNS names for Web services . . . . . . . 6 2.2 Endpoint Reference (EPR) Resource record . . . . . . . . . 6 2.2.1 EPR RDATA format . . . . . . . . . . . . . . . . . . . 7 2.2.2 EPR Presentation format . . . . . . . . . . . . . . . 10 2.3 Endpoint Extension (EPX) Resource record . . . . . . . . . 11 2.3.1 EPX RDATA format . . . . . . . . . . . . . . . . . . . 11 2.3.2 EPX Presentation format . . . . . . . . . . . . . . . 13 2.3.3 EPX RR semantics . . . . . . . . . . . . . . . . . . . 14 2.4 Enumerating EPR records . . . . . . . . . . . . . . . . . 15 3. Performance considerations . . . . . . . . . . . . . . . . . . 15 4. Security considerations . . . . . . . . . . . . . . . . . . . 15 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1 Endpoint reference with A TARGET and EPX records . . . . . 17 6.2 Endpoint reference with SRV TARGET and EPX XML Encoded record . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.3 Endpoint reference with A TARGET and EPX Redirect Encoded Record . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 18 7.2 Informational References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 20 Snell & Donoho Expires: May 23, 2005 [Page 2] Internet-Draft DNS-EPD November 2004 1. Introduction This document introduces mechanisms for DNS-based discovery of Web service endpoints. Introduced are two new DNS resource record types and the conventions for their use. A fundamental understanding of the DNS protocol and the core DNS resource record types as described in RFCs 1034 [2], 1035 [3] and 2782 [7] is assumed. 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 RFC 2119 [4]. 1.1 Bootstrapping Web service infrastructure The Web services architecture defines an abstract model for the publication and discovery of Web services. Upon deploying a Web service instance, the service provider advertises the services existence in a registry capable of allowing potential consumers to locate the information necessary to bind to and consume the service. The minimal amount of information necessary to allow a client to consume the service is the network location at which the service has been deployed and the identity of the so-called "PortType" implemented by the service. The "PortType" is a description of all the input and output messages supported by the Web service as described in a WSDL document. This PortType is identified by an XML namespace plus simple name pair known as a Qualified Name or QName. Knowing the PortType implemented by a Web services allows one to know exactly which types of messages to send to a service endpoint and which types of messages to expect that service to return. PortTypes and their QNames are defined within Web Service Description Language (WSDL) documents [8]. In a Service Oriented Architecture, there are several classifications of services available for an application to consume. Some are business-level services whose Port Types are specific to given applications. Others are infrastructure-level services whose Port Types are well known and consistent across multiple types of applications. An example of a business-level service would include a service a company may deploy to accept purchase orders from customers. An example of a well-known common infrastructure-level service is the Universal Description, Discovery and Integration (UDDI) service as defined by [9]. An application's choice to use specific business-level services may be based on a variety of complex criteria including service level agreements, geographic location, contractual obligations, etc and therefore potentially requires complex discovery mechanisms beyond Snell & Donoho Expires: May 23, 2005 [Page 3] Internet-Draft DNS-EPD November 2004 simple resolution of endpoint location and Port Type QName. Infrastructure level services, however ‚Çô particularly those deployed within a protected or private domain such as an intranet ‚Çô are generally selected based simply on their availability within a given domain. For example, if one wishes to use UDDI services to locate business services within an intranet, one would simply look for any and all UDDI services available within that intranet domain. In such cases, it is sufficient to resolve nothing more than the location and PortType QName of the service in question. DNS-EPD introduces a process for resolving the location of common services that is similar in nature to using the telephone white pages directory. As opposed to the telephone yellow pages, which organize numbers into a complex taxonomy organized by service category, the white pages provide nothing more than a simple name-to-number mapping. That is, if I wanted to find a phone number for any French restaurant in New York City, I would use the yellow pages to browse all available French restaurants and select one that suits my needs. If, however, I wanted to find the phone number for a specific French restaurant in New York City, I would use the white pages to look up the name of that specific restaurant and find its phone number. With DNS-EPD, if a client wishes to locate a specific instance of a Web service, it would go to DNS and resolve the current location of that service by name. A second key issue is that once a Web service's location has been resolved, how can one automatically detect changes that may occur in the configuration and deployment of those services? While administrators can hard code references to Web services into every deployed Web services component, doing so makes the infrastructure inherently brittle and difficult to manage. In a world of dynamically, and intelligently managed infrastructure, administrators need systems capable of automatically responding to changes in their networked environment. DNS-EPD's approach is to assign names to services and to allow components a means of using those names to dynamically resolve ‚Çô at run-time ‚Çô the metadata necessary to access those resources, allowing applications to intelligently respond to changes and promoting loose coupling between applications and the supporting infrastructure. 1.2 Mapping Web service artifacts into the domain name space Outside of DNS, the primary means of referencing Web service endpoints is the Web Service Addressing [10] Endpoint Reference (EPR). An EPR is a relatively simple XML structure that, at a minimum, specifies the network location of the service endpoint and the QName of the PortType implemented by the service. Additional pieces of information may be included, such as a digital signature Snell & Donoho Expires: May 23, 2005 [Page 4] Internet-Draft DNS-EPD November 2004 verifying the authenticity of the endpoint reference and a policy detailing various constraints and requirements that must be met in order to consume the service. An example WS-Addressing Endpoint Reference is below.
http://example.com/services/mystocks
abc:MyStockQuotes A key design goal of DNS-EPD is to not introduce yet another set of artifacts usable to reference and identify Web service endpoints; rather, the DNS-EPD conventions define a means of mapping WS-Addressing Endpoint References into the Domain Name Space. The Endpoint Reference Resource Record described in section four is the semantic equivalent to the basic WS-Addressing Endpoint Reference illustrated above. mystocks._ws.example.com EPR 10 0 0 example.com ( /services/mystocks urn:MyStockQuotes MyStockQuotes ) For the DNS-EPD mechanisms to be successful, however, there must be a means of incorporating the more extensive descriptions supported by WS-Addressing Endpoint References with the information contained in DNS. DNS-EPD does so by introducing an Endpoint Extension or EPX record that may be optionally used to provide additional information either by reference or direct containment. This information may include artifacts such as the complete WS-Addressing Endpoint Reference for a service, or a Web Service Policy document associated with the service, or even a WSDL document that describes the PortType implemented by the service. The combination of the EPR and EPX resource records allows one to fully and naturally map existing Web service artifacts into the domain name space. 2. DNS-EPD Resource records This section introduces the Endpoint Reference (EPR) and Endpoint Extension (EPX) resource record types and a means of browsing the domain name space for EPR resource records. Snell & Donoho Expires: May 23, 2005 [Page 5] Internet-Draft DNS-EPD November 2004 2.1 Establishment of DNS names for Web services DNS names associated with DNS-EPD resource records MUST follow the {name}._ws.{domain} pattern, where {name} is an arbitrary set of one or more DNS labels relevant to the type of service being advertised, _ws is a special DNS label indicating that the DNS name refers to a Web service, and {domain} is the DNS domain within which the Web service has been deployed. Examples of such names follow: inquire.uddi._ws.example.com mystocks._ws.example.com wsnbroker._ws.example.com The {name} portion in these examples ("inquire.uddi", "mystocks", and "wsnbroker" respectively) are assigned by DNS administrators or industry specific standards bodies and SHOULD be selected in a manner that would allow a human reading the name to be able to identify the type of Web service being described. It is expected that best practice naming conventions will evolve through the consistent application of the DNS-EPD specifications much in the same way that the "www" naming convention has been adopted for the naming of Web servers. It is also foreseeable that names for various common Web service types will be codified within specifications that define the service type. The bottom line is that the method such conventions are defined is considered out of scope for this document. It must be pointed out, however, that to be effective and to avoid confusion, names identifying service types should be unique, even across domains. For example, the name prefix inquire.uddi._ws. should identify UDDI Inquire services regardless of the domain in which the services are being advertised. The only way to achieve global uniqueness of such names is to codify the name and meaning in a standards specification. To this end, the _ws label works more as a tool to avoid naming collisions between services of different types; that is, the name inquire.uddi._ws running within the example.com domain is different than the name inquire._ws running within the uddi.example.com domain, omiting the _ws label would make it difficult to differentiate between the two service references. 2.2 Endpoint Reference (EPR) Resource record Web Service Endpoint References are represented in DNS using the EPR resource record. The format of the EPR RR is given below. The DNS type code for the EPR RR is TBD. Snell & Donoho Expires: May 23, 2005 [Page 6] Internet-Draft DNS-EPD November 2004 2.2.1 EPR RDATA format The RDATA of the EPR record consists of seven required fields. 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |FLAGS| P| W| TARGET / +-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | LENGTH | PATH (Variable Length) / +-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | LENGTH | QNAME_URI (Variable Length) / +-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | LENGTH | QNAME_LP (Variable Length) / +-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2.2.1.1 Flags An 8-bit unsigned byte field specifying option flags for the EPR record. The bit field consists of three defined bits and five reserved bits. The first bit (least-significant, 0x01) is an "information bit" that indicates whether or not EPX records have been provided. By default this bit should be unset. Bits 2 and 3 are mutually exclusive "target bits" that indicate whether or not the EPR resource record's TARGET field references an A/AAAA record or an SRV record. Bit 2 (0x02), if set, indicates that the TARGET field references an A/AAAA resource record. This bit will be referred to as the A TARGET BIT. This is the default. Bit 3 (0x04), if set, indicates that the TARGET field references a SRV resource record. This bit will be referred to as the SRV TARGET BIT. By default this bit is unset. The A and SRV target bits are mutually exclusive. At most one of the bits MUST be set. If both are set, the most significant bit (the SRV TARGET BIT) set takes precedence. One of the bits MUST be set. The remaining five bits are reserved for future use and MUST remain unset. For example, the flags field for an EPR specifying no additional information and a reference to an A/AAAA record would equal 00000010. Snell & Donoho Expires: May 23, 2005 [Page 7] Internet-Draft DNS-EPD November 2004 An EPR specifying additional EPX records and a reference to an SRV record would be 00000101. SRV TARGET BIT | |A TARGET BIT || 00000101 |___| | | | | | | INFORMATION BIT Reserved bits 2.2.1.2 Priority An 8-bit unsigned byte field (range 0-255) specifying a numeric priority for this endpoint reference record relative to other endpoint reference records associated with the same name. A client MUST attempt to use the endpoint reference with the lowest-numbered priority it can reach. Endpoint references with the same priority SHOULD be tried in an order determined by the value of the WEIGHT field described below. 2.2.1.3 Weight An 8-bit unsigned byte field (range 0-255) specifying a relative weight for endpoint references with the same PRIORITY. Endpoint references specifying larger weight values SHOULD be given a proportionally higher probability of being selected for use. A Weight of 0 should be assigned when no endpoint reference selection should be performed (e.g. when there is only a single Endpoint Reference or when multiple endpoint references should be selected at random with an equal probability of selection). Ordering of Endpoint Reference records of the same PRIORITY should be performed according to the following algorithm, starting with the EPR's with the lowest PRIORITY value. o Order all EPRs in ascending order according to WEIGHT o Compute the sum of the WEIGHTs for each EPR, associating the running sum of the weights with each EPR in order. o Choose a uniform random number between 0 and the computed sum of weights. o Select the first EPR whose associated running sum value is equal to or greater than the random number selected. Snell & Donoho Expires: May 23, 2005 [Page 8] Internet-Draft DNS-EPD November 2004 o Remove the selected EPR from the collection and add it to a second list of ordered EPRs. o Repeat the process until each of the EPRs in the original list has been selected and added to the list of ordered EPRs. o Repeat the process for each PRIORITY level. Once all EPRs have been ordered in this fashion, a client will select each EPR in the list, using the first that it is capable of using to bind to and invoke the service. 2.2.1.4 Target A DNS domain name that will be associated with either A/AAAA resource record(s) if the FLAGS field A TARGET BIT is set or SRV resource record(s) if the FLAGS field SRV TARGET BIT is set. The TARGET field is used to specify the network location where the Web service has been deployed and the network application protocol used to invoke the service. If referencing A/AAAA records, the network application protocol is assumed to be HTTP using the default TCP port 80. If referencing SRV records, the network application protocol will be specified by the referenced SRV record. Further, if the TARGET field references multiple SRV records, those SRV records are to be ordered and selected as specified in [7]. If the TARGET field references multiple A records, those A records are to be ordered and selected in any manner the requester deems appropriate. 2.2.1.5 Path A UTF-8 encoded specifying the additional URI path information for the Web service endpoint including appropriate query string parameters and fragment identifiers. For instance, if a Web service is deployed at the HTTP URL http://www.example.com/services/inquire, PATH will equal /services/ inquire. As the value of PATH is intended to be used in a URI, characters in the path MUST be properly escaped as defined in [6]. In the RDATA encoding, PATH MUST be preceded by a 2-byte unsigned integer in network byte order (big-endian) specifying the total length in octets of the field data. The value of the PATH field MAY be an empty string in which case the specified length in octets MUST be 0. 2.2.1.6 PortType QName Namespace URI A UTF-8 encoded specifying the Namespace URI of the WSDL defined PortType QName implemented by the Web service described by the EPR record. In the RDATA encoding, QNAME_URI MUST be preceded by a 2-byte unsigned integer in network byte order specifying the total length in octets of the field data. The value Snell & Donoho Expires: May 23, 2005 [Page 9] Internet-Draft DNS-EPD November 2004 of the URI MAY be an empty string. 2.2.1.7 PortType QName Namespace Local part A UTF-8 encoded specifying the Local part of the WSDL defined PortType QName implemented by the Web service described by the EPR record. In the RDATA encoding, QNAME_LP MUST be preceded by a 2-byte unsigned integer in network byte order specifying the total length in octets of the field data. The value of the Local part MUST NOT be an empty string. 2.2.2 EPR Presentation format The presentation format for EPR records is as illustrated below. FLAGS PRIORITY WEIGHT TARGET PATH QNAME_URI QNAME_LP MyStockQuotes._stockquotes._ws.example.com EPR ( 10 0 0 services.example.com /services/stockquotes urn:mystocks MyStockQuotes ) In this format, the FLAGS field is represented as a two digit numeric value with the first digit (from the left) representing the target bits and the second digit representing the information bit. A target bit (first digit) value of 1 indicates that the A TARGET BIT is set. A target bit value of 2 indicates that the SRV TARGET BIT is set. An information bit value of 1 indicates that the INFORMATION BIT is set and EPX records are available. An information bit value of 0 indicates that the INFORMATION BIT is not set and EPX records are not available. For example, an EPR referencing an A/AAAA target and no additional information would specify 10 for the flags field in the presentation format. An EPR referencing an SRV target and EPX records would specify 21 for the flags field in the presentation format. All of the available permutations are illustrated below. 10 - A/AAAA Target, no EPX records available 11 - A/AAAA Target, EPX records available 20 - SRV Target, no EPX records available 21 - SRV Target, EPX records available The PRIORITY and WEIGHT fields are each represented as unsigned integer values in the range 0-255. The PATH, QNAME_URI and QNAME_LP fields MUST be present. PATH and QNAME_URI MAY be empty strings. Snell & Donoho Expires: May 23, 2005 [Page 10] Internet-Draft DNS-EPD November 2004 2.3 Endpoint Extension (EPX) Resource record One of the key goals of this specification is to provide the means of querying DNS to locate and resolve complete information about a Web service endpoint. The collection of Web services related specifications/standards define a number of XML formats useful for describing various characteristics of Web service endpoints. This specification provides for two means of querying this information by allowing an EPR resource record to specify that such information may either be accessed directly from DNS or via a redirect to a given URL. The Endpoint Extension (EPX) resource record is a flexible record that is capable of either directly containing XML describing various aspects of the Web services endpoint or a URL redirection to a network location where such information can be retrieved. The format of the EPX record varies depending on how it is being used. The DNS type code for the EPX RR is TBD. 2.3.1 EPX RDATA format There are two possible RDATA formats for the EPX record, both variants are shown below. The first is called the EPX Redirect Encoding and is used when using the EPX record to specify a redirection to a URL. The second is called the EPX XML Encoding and is used to directly contain XML document fragments that describe the Web service endpoint. Redirect Encoding: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |TYPE |SIZE | URL (Variable Length) / +-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |SIZE | MEDIA_TYPE (Variable Length) / +-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--/ |SIZE | DIGEST (Variable Length) / +-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--/ |SIZE | DIGEST_ALG (Variable Length) / +-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--/ XML Encoding 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-----+----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |TYPE |ENC | XML / +-----+----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Snell & Donoho Expires: May 23, 2005 [Page 11] Internet-Draft DNS-EPD November 2004 In either option, the initial TYPE unsigned byte flag is used to identify the specific encoding used. A byte value of 0x00 indicates Redirect Encoding, a byte value of 0x01 indicates XML Encoding. 2.3.1.1 Redirect Encoding The Redirect Encoding consists of four variable length fields, each preceded by a two byte unsigned integeter value (in network byte order) specifying the length in octets of the field. 2.3.1.1.1 URL The URI field is a UTF-8 encoded specifying a fully qualified URL referencing an XML document that describes some aspect of the Web service endpoint. The URL MUST be resolvable into a single well-formed XML document. The URL field MUST NOT be an empty string. 2.3.1.1.2 MEDIA_TYPE The MEDIA_TYPE field is a UTF-8 encoded specifying the MIME Media Type of the document identified by the URL field. This field MAY be an empty string. 2.3.1.1.3 DIGEST The DIGEST field is a series of bytes representing a digest of the XML document referenced by the URL field. This field is optional and may be zero length. 2.3.1.1.4 DIGEST_ALG The DIGEST_ALG (digest algorithm) field is a UTF-8 encoding containing a URI identifying the algorithm used to generate the value of the DIGEST field. If DIGEST is not zero length, a digest algorithm MUST be specified, otherwise DIGEST_ALG MUST be an empty string. 2.3.1.2 XML Encoding In the XML Encoding, the EPX record consists of two fields, the first of which is a byte flag indicating the specific encoding used for the XML data contained in the second field. The encoding byte flag specifies an unsigned integer value (range 0-255) that indicates how the XML contained in the RDATA has been encoded. The default value of 0x00 indicates that the remaining RDATA is a UTF-8 encoded character-string containing XML 1.0. Snell & Donoho Expires: May 23, 2005 [Page 12] Internet-Draft DNS-EPD November 2004 Additional values for the encoding byte flag MUST be defined by a specification and registered with IANA. If the encoding specified is not understood by the party requesting the EPX record, the record MUST be ignored. It has to be pointed out that there is no way for DNS to enforce that the actual encoding of the XML data matches that specified by the encoding byte flag. Therefore, clients MUST be prepared to properly handle potential mismatches. EPX records in which the encoding of the data does not match the value of the encoding byte flag SHOULD be ignored. The XML contained in the EPX record MUST NOT contain a prolog, a document type declaration, processing instructions, or unnecessary whitespace such as that typically used for formatting and indenting XML documents. See the next section for a discussion of the use of formatting whitespace in the presentation format. The XML contained in the XML Information record SHOULD NOT use relative URI's. If relative URI's are used within the document, The xml:base attribute MUST be used to specify a base for those URIs. 2.3.2 EPX Presentation format As with the RDATA encoding, the presentation format for the EPX record differs depending on whether the Redirect or XML encoding is used. For Redirect Encoding, the RDATA consists of a single unsigned integer representing the TYPE field followed by four s representing each of the four redirect encoding fields. The value of the DIGEST field is represented as zero or more words of hexidecimal data encoding the value of the digest. Empty strings are represented using a single period (.) character. The value of the TYPE field must equal 0 to identify that Redirect encoding is being used. The example below shows a redirect to a WSDL document using a fictional application/wsdl+xml Mime media type with no digest or digest algorithm specified. mystocks._ws.example.com EPX 0 ( http://example.com/services/mystocks.wsdl application/wsdl+xml . . ) For XML encoding the RDATA for the presentation format consists of a single unsigned integer for the TYPE field followed by a single Snell & Donoho Expires: May 23, 2005 [Page 13] Internet-Draft DNS-EPD November 2004 unsigned integer (range 0-255) specifying the encoding byte flag and zero or more words of hexidecimal data encoding the XML document. The value of the type field MUST equal 1 to identify that XML Encoding is being used. mystocks._ws.example.com EPX 1 0 ( 3c456e64706f696e745265666572656e636520786d6c 6e733d222e2e2e2220786d6c3a626173653d22687474 703a2f2f6578616d706c652e636f6d223e3c41646472 6573733e2f73657276696365732f73746f636b733c2f 416464726573733e3c2f456e64706f696e7452656665 72656e63653e ) 2.3.3 EPX RR semantics EPX records are used solely as a means of allowing DNS administrators to publish "additional information" about a Web service endpoint being advertised in DNS. It is up to the client to interpret the meaning of the XML contained within the record and determine whether or not the additional information is useful and relevant. Upon querying for EPR resource records, a client would determine whether or not additional information is provided by checking the information bit in the flags portion of the EPR RDATA. If information bit is set, the client MAY choose to submit a query for any EPX records associated with the same DNS name as the EPR resource record. If such a query is submitted, the DNS server would respond with all associated EPX records. The client would receive these records, parse their RDATA and then determine the utility of the information returned. A DNS client MUST NOT submit any queries for EPX resource records unless the EPR resource record's information bit is set. EPX records MUST NOT be used for any other purpose than in association with an EPR record. It should be noted that much existing deployed DNS infrastructure places strict practical limits on the size of DNS request and reply messages. To work best within these constraints, limits should be placed on the size and complexity of the XML stored within DNS using the XML encoding of EPX records. In general, the size of the XML fragments contained in DNS should be small enough to fit within a single UDP datagram that is short enough not to require IP fragmentation. If the XML is not small enough to fit within this size constraint, then the Redirect encoding should be used and the XML stored in a location external to the DNS system. Snell & Donoho Expires: May 23, 2005 [Page 14] Internet-Draft DNS-EPD November 2004 2.4 Enumerating EPR records DNS Administrators may allow clients to enumerate all services advertised within a given DNS domain by associating PTR resource records with the special _services._ws.{domain} name, where {domain} is the DNS domain within which Web services have been advertised. The RDATA of the PTR records associated MUST specify the names of EPR resource records advertised within the domain. For example: > nslookup ‚Çôq=PTR _services._ws.example.com _services._ws.example.com PTR mystocks._ws.example.com PTR inquire.uddi._ws.example.com PTR publish.uddi._ws.example.com 3. Performance considerations The DNS-EPD resource records have been designed to maximize the efficiency of queries, allowing clients to request only the bits of information they absolutely require. EPR and EPX records are cacheable but the TTL values will be variable based on the types of Web services they are referring to. Infrastructure level services (e.g. UDDI services) should have fairly stable endpoint references that do not change frequently and thus can have long TTL values. XML fragments stored in DNS are of significant concern given their arbitrary nature and potential size. Great care must be taken in their use and appropriate consideration needs to be given to their cacheability and the decision to store them in DNS at all (as opposed to using the Redirect encoding option and storing the XML outside of DNS). 4. Security considerations DNS-EPD resource records are subject to the same security concerns as other existing DNS resource record types. These concerns include spoofing, cache poisoning, and other known types of attacks. Addressing how to secure DNS-EPD records from such attacks is considered out of scope for this document. DNS administrators should defer to other specifications or methodologies for securing their DNS environments to ensure that such attacks are dealt with appropriately. Specifically, in the absence of DNS-native security measures, Snell & Donoho Expires: May 23, 2005 [Page 15] Internet-Draft DNS-EPD November 2004 information requested from DNS would need to be authenticated and cryptographically verified for integrity and/or confidentiality using mechanisms external to the DNS protocol. For DNS-WSD, this could include the use of specifications such as OASIS WSS to authenticate the endpoints advertised in the DNS registry following discovery but prior to service invocation, or integrity and/or confidently protecting the DNS-WSD artifacts stored in the DNS. DNS-EPD introduces no new security concerns to either DNS or the Web services architecture as the existing Web services architecture is already dependent on the existing security (or lack thereof) of DNS architecture. Further, DNS Administrators should segregate mission critical statically managed DNS services from DNS services that allow dynamic, and possibly arbitrary, zone updates and properly delegate the administration of zones containing Web service advertisements. Other existing DNS administration best practices should continue to be followed. 5. IANA considerations This specification would require IANA to allocate RR type codes for the EPR and XML resource records. The registration of new encoding byte flag values for the EPX resource record would need to be allocated by IANA and described by a specification document. Submission documents detailing new encoding byte flag values MUST specify, at a minimum, whether or not the value identifies a character or binary encoding and MUST specify the version of XML used. 6. Examples Snell & Donoho Expires: May 23, 2005 [Page 16] Internet-Draft DNS-EPD November 2004 6.1 Endpoint reference with A TARGET and EPX records mystocks._ws.example.com EPR 10 0 0 ( services.example.com /services/stockquotes urn:mystocks MyStockQuotes ) Equivalent WS-Addressing EndpointReference
http://services.example.com:80/services/stockquotes
ns:MyStockQuotes 6.2 Endpoint reference with SRV TARGET and EPX XML Encoded record mystocks._ws.example.com EPR 21 0 0 ( _http._tcp.example.com /services/stockquotes urn:mystocks MyStockQuotes ) mystocks._ws.example.com XML 1 0 ( 3c456e64706f696e745265666572656e63653e3c 416464726573733e687474703a2f2f2e2e2e3c2f 416464726573733e3c5265666572656e63655072 6f706572746965733e3c6120786d6c6e733de280 9975726e3a666f6fe280993e6162633c2f613e3c 2f5265666572656e636550726f70657274696573 3e3c2f456e64706f696e745265666572656e6365 3e ) _http._tcp.example.com SRV 0 0 80 services.example.com Snell & Donoho Expires: May 23, 2005 [Page 17] Internet-Draft DNS-EPD November 2004 6.3 Endpoint reference with A TARGET and EPX Redirect Encoded Record mystocks._ws.example.com EPR 11 0 0 ( services.example.com /services/stockquotes urn:mystocks MyStockQuotes ) mystocks._ws.example.com EPX 0 ( http://example.com/services.wsdl application/wsdl+xml . . ) 7. References 7.1 Normative References [1] Lottor, M., "Domain administrators operations guide", RFC 1033, November 1987. [2] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [3] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [7] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [8] Christensen, E., Curbera, F., Meredith, G. and S. Weerawarana, "Web Services Description Language (WSDL) 1.1", W3C NOTE NOTE-wsdl-20010315, March 2001. 7.2 Informational References [9] Bryan, D., Vadim, V., Ehnebuske, D., Glover, T., Hately, A., Snell & Donoho Expires: May 23, 2005 [Page 18] Internet-Draft DNS-EPD November 2004 Husband, YL., Karp, A., Kibakura, K., Kury, C., Lancelle, J., Lee, S., MacRoibeaird, S., Thomas Manes, A., McKee, B., Munter, J., Nordan, T., Reeves, C., Rogers, D., Tomlinson, C., Tosun, C., von Riegen, C. and P. Yendluri, "Universal Description, Discovery and Integration". [10] Box, D., Christensen, E., Curbera, F., Ferguson, D., Frey, J., Hadley, M., Kaler, C., Langworthy, D., Leymann, F., Lovering, B., Lucco, S., Millet, S., Mukhi, N., Nottingham, M., Orchard, D., Shewchuk, J., Sindambiwe, E., Storey, T., Weerawarana, S. and S. Winkler, "Web Services Addressing (WS-Addressing)", 08 2004. Authors' Addresses James M Snell IBM 3039 Cornwallis Rd., P.O. Box 12195 Research Triangle Park, NC 27709 US Phone: +1 877 511 5082 EMail: jasnell@us.ibm.com URI: http://www.ibm.com Andrew W Donoho IBM 11501 Burnet Road Austin, TX 78758 US Phone: +1 877 220 0659 EMail: awd@us.ibm.com URI: http://www.ibm.com Appendix A. Acknowledgements The authors gratefully acknowledge the contributions of: Anthony Nadalin, Arnaud Le Hors, Brian Carpenter, Heather Kreger, Jim Colson, Stewart Cheshire, Thomas Narten, and Tony Storey Snell & Donoho Expires: May 23, 2005 [Page 19] Internet-Draft DNS-EPD November 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Snell & Donoho Expires: May 23, 2005 [Page 20]