[dnsext] Revised version of ESRV

Phillip Hallam-Baker <hallam@gmail.com> Wed, 09 March 2011 17:16 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 442463A6765 for <dnsext@core3.amsl.com>; Wed, 9 Mar 2011 09:16:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.565
X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id LkN9ZiIb+nnf for <dnsext@core3.amsl.com>; Wed, 9 Mar 2011 09:16:33 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com []) by core3.amsl.com (Postfix) with ESMTP id 3D0CA3A65A6 for <dnsext@ietf.org>; Wed, 9 Mar 2011 09:16:32 -0800 (PST)
Received: by bwz13 with SMTP id 13so973840bwz.31 for <dnsext@ietf.org>; Wed, 09 Mar 2011 09:17:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=q+yoDnwz3NE2k1Dn5wgsgWlRO6ko5qOPUJ0eeU1hZRI=; b=xTiRTWbqNxuQHWeu9OmuB3qRHPYmOZiFVFPY21dItEhLAjo6fmK/pnNJ9gAnhi4Pci mpwIghQl3so0a2V8Rl00nUCydRV4FEJCgreMig1yMQHX4kt6hQqEzCwZCPNyna3aE+tO x9Dzc30CjOqh6tMWmYUnqg5Ka7HrHYvLzZM8U=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=vQ3NJhdQ0pGGx+z1iUxHqzPd7F6MKZRgvIHm8tb4FRHlvqWG3xVdce60jldQ9OybAQ fasuuo0UKKaqvXVNLjvEObMQjOPokpFjLDAWXv/u3vFcXZzYaJHKZFhM2N707IGPpDBS 4Yll/FIf96OU4XOt76ydbpKrcSPaKRxEXuYzE=
MIME-Version: 1.0
Received: by with SMTP id u1mr5654678bkz.26.1299691068870; Wed, 09 Mar 2011 09:17:48 -0800 (PST)
Received: by with HTTP; Wed, 9 Mar 2011 09:17:48 -0800 (PST)
Date: Wed, 9 Mar 2011 12:17:48 -0500
Message-ID: <AANLkTi=Rxs=PwMJyjQk2cES2e3cng_j2DGcC_di269Pn@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: dnsext@ietf.org
Content-Type: multipart/alternative; boundary=bcaec52e601d7a516a049e0fe896
Subject: [dnsext] Revised version of ESRV
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Mar 2011 17:16:35 -0000


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.


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:


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
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 "
_dgsp._ws.donutinfo.info  URI  1 1 80 "

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'

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/