[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [209.85.214.44]) 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 10.204.174.193 with SMTP id u1mr5654678bkz.26.1299691068870; Wed, 09 Mar 2011 09:17:48 -0800 (PST)
Received: by 10.204.59.7 with HTTP; Wed, 9 Mar 2011 09:17:48 -0800 (PST)
Date: Wed, 09 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
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/
- [dnsext] Revised version of ESRV Phillip Hallam-Baker
- Re: [dnsext] Revised version of ESRV Masataka Ohta