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.
<EndpointReference
xmlns="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns:abc="urn:MyStockQuotes">
<Address>http://example.com/services/mystocks</Address>
<PortType>abc:MyStockQuotes</PortType>
</EndpointReference>
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 <character-string> 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 <character-string> 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 <character-string> 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 <character-string> 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 <EndpointReference xmlns="..."
xml:base="http://example.com">
<Address>/services/stocks</Address>
</EndpointReference>
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 <EndpointReference xmlns="...">
<Address>...</Address>
<ReferenceProperties>
...
</ReferenceProperties>
</EndpointReference>
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
<EndpointReference>
<Address>
http://services.example.com:80/services/stockquotes
</Address>
<PortType xmlns:ns="urn:mystocks">ns:MyStockQuotes</PortType>
</EndpointReference>
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 <EndpointReference>
<Address>http://...</Address>
<ReferenceProperties>
<a xmlns=‚ÇÖurn:foo‚ÇÖ>abc</a>
</ReferenceProperties>
</EndpointReference>
> 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]