Internet-Draft J. Snell draft-snell-dnsepd-00.txt A. Donoho Expires: April 15, 2005 IBM October 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 April 15, 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 April 15, 2005 [Page 1] Internet-Draft DNS-EPD October 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 . . . . . . . . . . . . . . . . . . . 6 2.2.2 EPR Presentation format . . . . . . . . . . . . . . . 10 2.3 XML Information (XML) Resource record . . . . . . . . . . 11 2.3.1 XML RDATA format . . . . . . . . . . . . . . . . . . . 11 2.3.2 XML Presentation format . . . . . . . . . . . . . . . 12 2.3.3 XML RR semantics . . . . . . . . . . . . . . . . . . . 13 2.4 Enumerating EPR records . . . . . . . . . . . . . . . . . 14 3. Performance considerations . . . . . . . . . . . . . . . . . . 14 4. Security considerations . . . . . . . . . . . . . . . . . . . 15 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1 Endpoint reference with A TARGET and no information bits set . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2 Endpoint reference with SRV TARGET and XML INFORMATION bits set . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.3 Endpoint reference with A TARGET and WSDL INFORMATION bits set . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 7.2 Informational References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Snell & Donoho Expires April 15, 2005 [Page 2] Internet-Draft DNS-EPD October 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 April 15, 2005 [Page 3] Internet-Draft DNS-EPD October 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 April 15, 2005 [Page 4] Internet-Draft DNS-EPD October 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 100 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 in two ways: 1) by allowing an EPR resource record to externally reference the additional information using an HTTP GET URL reference to that information and 2) using a new XML resource record capable of storing well-formed XML fragments directly within the DNS database. This referenced or contained 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 XML 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 XML Information (XML) resource record types and a means of browsing the domain name space for EPR resource records. Snell & Donoho Expires April 15, 2005 [Page 5] Internet-Draft DNS-EPD October 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. 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. 2.2.1 EPR RDATA format The RDATA of the EPR record consists of six required and one optional field. Snell & Donoho Expires April 15, 2005 [Page 6] Internet-Draft DNS-EPD October 2004 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 (Variable Length) / +-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | LENGTH | WSDL_URI (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 four defined bits and four reserved bits. The first two bits, starting from the least-significant bit, are "information bits" indicating whether or not additional information has been provided either in DNS or via an external HTTP URL reference to a WSDL [8] document describing the service. Bit 1 (0x01), if set, indicates that additional information in the form of XML resource records have been provided. This bit will be referred to as the XML INFO BIT. By default this bit is unset. Bit 2 (0x02), if set, indicates that additional information has been provided in the form of a WSDL document referenced via HTTP URL reference in the WSDL_URI field. This bit will be referred to as the WSDL INFO BIT. By default this bit is unset. Bits 3 and 4 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 3 (0x04), 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 4 (0x08), if set, indicates that the TARGET field reference a SRV resource record. This bit will be referred to as the SRV TARGET BIT. 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. Snell & Donoho Expires April 15, 2005 [Page 7] Internet-Draft DNS-EPD October 2004 The remaining 4 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 00000100. An EPR specifying additional information via an HTTP URL reference and a reference to an SRV record would be 00001010. SRV TARGET BIT | |A TARGET BIT || 00001010 |__| || | || | || | |XML INFORMATION BIT Reserved bits | WSDL INFORMATION BIT 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. Snell & Donoho Expires April 15, 2005 [Page 8] Internet-Draft DNS-EPD October 2004 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. 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 (QNAME) A UTF-8 encoded specifying the Namespace URI of Snell & Donoho Expires April 15, 2005 [Page 9] Internet-Draft DNS-EPD October 2004 the WSDL defined PortType QName implemented by the Web service described by the EPR record. The MUST use the format {namespace-uri}localpart as in the example {urn:mystocks}MyStocksPortType, where urn:mystocks is the Namespace URI portion of the QName and MyStocksPortType is the Localpart portion of the QName. In the RDATA encoding, QNAME 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 QNAME field MUST NOT be an empty string. For QNames that specify a null namespace, the encoding would be {}LocalPart. 2.2.1.7 WSDL URI Reference (WSDL_URI) A UTF-8 encoded specifying a URI where a WSDL document describing the service may be accessed. The WSDL_URI field MUST NOT be included in the EPR resource record unless the WSDL INFO BIT is set. In the RDATA encoding, WSDL_URI MUST be preceded by a 2-byte unsigned integer in network byte order specifying the total length in octets of the field data. If the WSDL INFO BIT is set, the WSDLURI field value 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 WSDL_URI MyStockQuotes._stockquotes._ws.example.com EPR 101 0 0 services.example.com /services/stockquotes {urn:mystocks}MyStockQuotes http://services.example.com/stocks.wsdl In this format, the FLAGS field is represented as a three digit numeric value with the first digit (starting from the left) representing the target bits and the second and third digits representing the XML and WSDL information bits, respectively. 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 XML information bit value of 1 indicates that the XML INFORMATION BIT is set. An XML information bit value of 0 indicates that the XML INFORMATION BIT is not set. A WSDL information bit value of 1 indicates that the WSDL INFORMATION BIT is set. A WSDL information bit value of 0 indicates that the WSDL INFORMATION BIT is not set. For example, an EPR referencing an A/AAAA target and no additional information would specify 100 for the flags field in the master file format. An EPR referencing an SRV target and a WSDL Snell & Donoho Expires April 15, 2005 [Page 10] Internet-Draft DNS-EPD October 2004 reference would specify 201 for the flags field in the master file format. All of the available permutations are illustrated below. 100 - A/AAAA Target, no additional information 110 - A/AAAA Target, additional information in XML records, no WSDL reference 101 - A/AAAA Target, additional information in WSDL document, no XML records 111 - A/AAAA Target, additional information in WSDL document and XML records 200 - SRV Target, no additional information 210 - SRV Target, additional information in XML records, no WSDL reference 201 - SRV Target, additional information in WSDL document, no XML records 211 - SRV Target, additional information in WSDL document and XML records The PRIORITY and WEIGHT fields are each represented as unsigned integer values in the range 0-255. The PATH and QNAME fields MUST be present. If the value of the PATH field is an empty string, a single backwards-slash \ character (ASCII character 92, hex 0x5C) MUST be specified in the PATH field. The value of the QNAME field MUST NOT be an empty string. The WSDL_URI field MUST only be present if the third digit in the FLAGS field is set to 1 (indicating that the WSDL INFORMATION BIT is to be set). If the WSDL INFORMATION BIT is set, the WSDL_URI field MUST be a fully qualified absolute URL. 2.3 XML Information (XML) 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 via an HTTP GET request or by submitting an additional query to DNS for all XML records associated with the same domain name as the EPR. The format of the XML RR is given below. The DNS type code for the XML RR is TBD. 2.3.1 XML RDATA format The RDATA of the XML record consists of a single encoding byte flag followed by a well-formed XML fragment encoded in the manner identified by the value of the encoding byte flag. Snell & Donoho Expires April 15, 2005 [Page 11] Internet-Draft DNS-EPD October 2004 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ENC | RDATA / +-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 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. Additional values for the encoding byte flag MUST be allocated by IANA following IETF consensus. DNS implementations MUST send the XML data using the encoding specified by the encoding byte flag. If the encoding specified is not understood by the DNS implementation, the XML RR MUST be ignored. The XML contained in the XML Information 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. mystocks._ws.example.com XML 0
/services/stocks
 2.3.2 XML Presentation format The presentation format for the XML Information record RDATA consist of a single unsigned integer (range 0-255) specifying the encoding byte flag and a character-string representation of the XML fragment, with or without formatting whitespace (including cariage returns). If formatting whitespace is included in the presentation format, DNS implementations are required to strip that whitespace from the XML prior to encoding the RDATA for transmission. The DNS implementation is required to encode the XML contained using the encoding specified in the encoding byte flag. As an alternative to including the XML data inline in DNS zone database files, an alternative syntax MAY be used to specify a URI reference to an external file where the XML RDATA may be recovered. The XML in the referenced location MUST be encoded in the manner Snell & Donoho Expires April 15, 2005 [Page 12] Internet-Draft DNS-EPD October 2004 specified by the encoding byte flag and MUST NOT include the prolog, document type declarations, processing instructions or unnecessary formatting whitespace. The URI reference MUST be encapsulated in square brackets [ ]. Relative URI's, if used, are to be resolved relative to the location of the zone database file. mystocks._ws.example.com XML 0 [service.wsdl] 2.3.3 XML RR semantics The goal of the XML record is to provide a simple efficient means of storing XML within the DNS. From the point of view of this specification, XML records are used solely for the purpose of allowing DNS administrators to publish arbitrary "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. The XML INFORMATION bit is set, then the client MAY choose to submit a query for any XML 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 XML records. The client would receive these records, parse their RDATA using any appropriate XML parser, and then determine the utility of the information returned. Returned XML records that specify an encoding byte flag value that the client does not understand MUST be ignored. > nslookup -q=EPR mystocks._ws.example.com mystocks._ws.example.com EPR 110 0 0 services.example.com stockquotes._ws.example.com /services/stockquotes {urn:mystocks}MyStockQuotes The XML Information bit is set, additional information in the form of XML records is available. > nslookup -q=XML mystocks._ws.example.com XML 0
...
... When using DNS-EPD to resolve information about Web services, a DNS client MUST NOT submit any queries for XML resource records unless the EPR resource record's XML INFORMATION BIT is set. The XML Snell & Donoho Expires April 15, 2005 [Page 13] Internet-Draft DNS-EPD October 2004 Resource Record MAY be used for other purposes outside the scope of DNS-EPD but documenting such uses are considered out of scope of this specification. 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 XML records. In short, 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 it SHOULD not be stored within DNS and the alternate HTTP GET based approach for referencing additional information should be used. 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 XML 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 Snell & Donoho Expires April 15, 2005 [Page 14] Internet-Draft DNS-EPD October 2004 to using the WSDL reference 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, 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 XML resource record would need to be allocated by IANA following IETF consensus. 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. Snell & Donoho Expires April 15, 2005 [Page 15] Internet-Draft DNS-EPD October 2004 6. Examples 6.1 Endpoint reference with A TARGET and no information bits set > nslookup -q=EPR mystocks._ws.example.com mystocks._ws.example.com EPR 100 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 XML INFORMATION bits set > nslookup -q=EPR mystocks._ws.example.com mystocks._ws.example.com EPR 210 0 0 _http._tcp.example.com /services/stockquotes {urn:mystocks}MyStockQuotes > nslookup -q=XML mystocks._ws.example.com mystocks._ws.example.com XML 0
http://...
abc > nslookup -q=SRV _http._tcp.example.com _http._tcp.example.com SRV 0 0 80 services.example.com Client may either construct a simple EndpointReference from the information contained in the EPR resource record or use the one provided in the associated XML record. 6.3 Endpoint reference with A TARGET and WSDL INFORMATION bits set > nslookup -q=EPR mystocks._ws.example.com mystocks._ws.example.com EPR 101 0 0 services.example.com /services/stockquotes {urn:mystocks}MyStockQuotes http://example.com/services.wsdl Snell & Donoho Expires April 15, 2005 [Page 16] Internet-Draft DNS-EPD October 2004 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., 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. Snell & Donoho Expires April 15, 2005 [Page 17] Internet-Draft DNS-EPD October 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 April 15, 2005 [Page 18] Internet-Draft DNS-EPD October 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 April 15, 2005 [Page 19]