Subject: [dnsext] Revised version of ESRV

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 9 Mar 2011 12:17:48 -0500

All,

Brian and I have produced an updated version of ESRV. We believe it may be
of interest to people looking at the problem of how to manage Web Services
and Internet Services using the DNS.

http://www.ietf.org/id/draft-hallambaker-esrv-01.txt

The main purpose of the draft is to support features that are relevant to
application space, but it is highly DNS-centric and so relevant to many
discussions here. In particular the capabilities described are likely to be
useful for attempts to address the tree aliasing problem.

This version of the draft is considerably simplified from the -00 edition
but still provides the same set of capabilities.

The basic idea here is that when writing code to establish a connection to
an Internet Service or a Web Service it is best if the platform and the
infrastructure do as much work as possible and require the programmer to do
as little as possible.

The end goal being that the programmer specify only the domain name (
example.com) and the protocol (_http._tcp) they wish to connect to and the
application program then provide the 'best' connection according to criteria
that would be established at the most appropriate level which is only
sometimes going to be in the application code.

So the API call can look something like

connection = Network.Connect ("example.com", "_http._tcp)

When the programmer specifies read and write methods on the connection they
are going to be wrapped in TLS or IPSEC accredited to appropriate keys.
Unless there is a specific need for the programmer to take control (e.g.
specify that TLS is required), everything can be handled automatically.

One major concrete benefit here is that it would enable scripting languages
to make use of TLS in mashups a lot easier. It also allows 'strict' security
to be achieved for any Internet protocol and not just for HTTP.

>From a design point of view, the main benefit it brings is to allow use of
SRV and URI mechanisms to be made compatible with wildcard records and with
aliases and to allow them to be retrofitted to existing Web Services.

For example, imagine we have an existing Web Service, the donut shop
geolocator protocol (DSGP). Currently we might have a few hundred thousand
clients with a Web Service Endpoint (WSE) embedded:

http://dsgp.donutinfo.info/webservices/dsgp/1.1/

Now imagine that we want to move to using SRV or URI. This is a choice that
in my view should be made by the network administrator of the site. But at
present the decision can only be made by the protocol designer and is going
to be a matter of personal preference. Or alternatively, what if someone
wants to propose an even better discovery mechanism that might make use of
network geolocation data to select the most appropriate service. I believe
that it is practical difficulties of this type that limit use of SRV.

In the GSRV/ESRV mechanism the web service would be identified as simply '
donutinfo.info' All the decoration and detail necessary to turn that into a
URI will be retrieved from the DNS.

# Domain level information, tell clients that there is service level data
available
donutinfo.info  GSRV 0 service "_dgsp._ws"
donutinfo.info  GSRV 0 uri "_dgsp._ws"

# Service level information, we have two hosts, both offer TLS on port 443
_dgsp._ws.donutinfo.info  ESRV 0 tls "optional=443"
_dgsp._ws.donutinfo.info  URI  1 1 80 "
http://host1.donutinfo.info/webservices/dsgp/1.1//"
_dgsp._ws.donutinfo.info  URI  1 1 80 "
http://host2.donutinfo.info/webservices/dsgp/1.1//"

The main objection to using prefixed records to date has been that they
interact badly with wildcards and aliases. The above scheme is fully
compatible with both. The key is that two records are used:

Queries for GSRV records NEVER take a prefix. A GSRV record may thus be used
with a wildcard or be the target of an alias without causing 'unexpected'
results.

ESRV records ALWAYS take a prefix and the prefix is ONLY applied to a
canonical name (i.e. the target of a CNAME or DNAME).

The combination of these rules means that it should never be the case that a
query results in a 'not found' situation because the resolution missed the
fact that there was a CNAME alias, nor should a query result in extraneous
records being returned as a wildcard matches undesired protocol prefixes.

-- 
Website: http://hallambaker.com/

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 10 Mar 2011 07:36:43 +0900

> infrastructure do as much work as possible and require the

Programmers? Then, let users do all the job to locate services.

Don't put the infrastructure information for service location
only to burden programmers write programs to investigate and
process the information.

						Masataka Ohta