Re: [dnsext] URI RRTYPE review - Comments period end Aug 15th

Phillip Hallam-Baker <hallam@gmail.com> Wed, 13 October 2010 15:14 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 010C23A6956; Wed, 13 Oct 2010 08:14:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
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 IZpVacUoKqlb; Wed, 13 Oct 2010 08:14:48 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0AEA43A69CA; Wed, 13 Oct 2010 08:14:47 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1P62zc-000Lgn-0M for namedroppers-data0@psg.com; Wed, 13 Oct 2010 15:11:48 +0000
Received: from stora.ogud.com ([66.92.146.20]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from <namedroppers@stora.ogud.com>) id 1P62zW-000LgB-By for namedroppers@ops.ietf.org; Wed, 13 Oct 2010 15:11:43 +0000
Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o9DFBbVg000343 for <namedroppers@ops.ietf.org>; Wed, 13 Oct 2010 11:11:37 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com)
Received: (from namedroppers@localhost) by stora.ogud.com (8.14.4/8.14.4/Submit) id o9DFBbIB000342 for namedroppers@ops.ietf.org; Wed, 13 Oct 2010 11:11:37 -0400 (EDT) (envelope-from namedroppers)
Received: from mail-fx0-f52.google.com ([209.85.161.52]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <hallam@gmail.com>) id 1P5kYc-000ENz-R5 for namedroppers@ops.ietf.org; Tue, 12 Oct 2010 19:30:43 +0000
Received: by fxm16 with SMTP id 16so2070163fxm.11 for <namedroppers@ops.ietf.org>; Tue, 12 Oct 2010 12:30:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=VMxe+k5j+aWIjcJUx2pL6wUFX1OIJCPKMWXdifVQkkk=; b=PLh+puUGa+egSUpk2A2EtP6SK8gc5mY0lNuUlgZP5WPSpiW7sBONu/lkTTgVqdgVCc U+As7M17G0KvSXL56Wui+/AEoUYkZRi1gzwCc5xoKZ/lqgvg8C5pEokd7kVuw3vpA0/I QMOBZ9JPvqGvnqnCmalIK/Zc5mHiNMTbx+p8I=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WDsASDcdfdbV0UsSYlZwpELHo8MjpWkIc5lKz2c4wLm7Vy9S8pnw22TfI7tRfzEyab 7KBswFx1XlEJrn3jNKFWgxlVYiFSlk8fE6lWtAUVn0dy/qn2mCnxPJizH3SO4GzOGGEf Tr4MXj6JSb6aAF649tdGFePwOSUqA7zrtJcNs=
MIME-Version: 1.0
Received: by 10.239.140.2 with SMTP id v2mr560823hbv.98.1286911841541; Tue, 12 Oct 2010 12:30:41 -0700 (PDT)
Received: by 10.239.156.141 with HTTP; Tue, 12 Oct 2010 12:30:41 -0700 (PDT)
In-Reply-To: <C9DE16B6-3740-4670-955A-60448A14A7E8@cisco.com>
References: <20100725184119.GA42253@registro.br> <AANLkTikLbJwMLjzgyhFZ+fcc63-6wo0ccBb_CRgL2hw2@mail.gmail.com> <8E0002DF-09C9-46CD-AB1B-6DE946E3D0DC@cisco.com> <AANLkTinuNGYU_eoh5-Y=XJwmeo6psU_vPYt1vFAjq+Kk@mail.gmail.com> <C9DE16B6-3740-4670-955A-60448A14A7E8@cisco.com>
Date: Tue, 12 Oct 2010 15:30:41 -0400
Message-ID: <AANLkTi=W_6vP2wOfE0eiBNWviRXqHnKFuqNnOtt2Vwen@mail.gmail.com>
Subject: Re: [dnsext] URI RRTYPE review - Comments period end Aug 15th
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Patrik Fältström <paf@cisco.com>
Cc: Ted Hardie <ted.ietf@gmail.com>, Frederico A C Neves <fneves@registro.br>, namedroppers@ops.ietf.org
Content-Type: multipart/alternative; boundary="0016364d31b72c1d8d0492708342"
X-Scanned-By: MIMEDefang 2.68 on 66.92.146.20
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

Originally I was somewhat skeptical of URI. After all, if NAPTR, SRV and
such have failed, why would this succeed? And just as NAPTR makes the
discovery problem worse rather than better since it means that there are two
discovery mechanisms to choose from, URI looked like it would make things
worse.

Once I started to look at security policy publication, I realized that the
discovery signaling problem is solved almost for free.


So the starting point is the need to express policy of the form 'always use
TLS' in the DNS. Which is what I propose with ESRV:


_imap._tcp.example.com   ESRV "tls=required"
_http._tcp.example.com   ESRV "tls=required"


[From this starting point we could easily elaborate the scheme to require
specific trust roots for use of TLS or IPSEC or whatever. But that is
actually a somewhat subtle and involved problem I would like to defer for
now.]

Now due to the problem with CNAME, it is highly desirable that the
resolution process for ERSV (or any other policy record) is incremental and
starts at the unprefixed zone. So the first lookup would be for an ESRV
record for unprefixed example.com:

example.com  ESRV "tls=required match=_http._tcp, _imap._tcp"
www.example.com CNAME example.com

Which should deliver the relevant policy records in a single lookup for
either example.com or www. example.com.


What does become rather clear is that the original attempt to avoid the need
for an SRV registry by re-using the protocol names registry in a horrible
kludged fashion was a big mistake. I think we should seriously consider
starting the use of prefixes from scratch and abandon the tcp/udp layer.


Now once you have a lookup that is allowing security policy to be
distributed, it can be used to publish other information. For example it
could tell the client that it can use SRV or NAPTR or URI for enhanced
discovery.

example.com  ESRV "prefix=_http._tcp,_imap._tcp"
_http._tcp.example.com ESRV "tls=required disc=srv"
_http._tcp.example.com SRV 1 1 80 site1.example.com
_http._tcp.example.com SRV 1 1 80 site2.example.com

I have an initial draft out, but I am still working on the details. The
practical significance of this is that it is not necessary for the use of
the URI scheme to be hardwired into the application protocol as Patrik
states.

I think that it is in fact practical to use a mechanism such as ESRV to
retrofit a new discovery mechanism to existing protocols.


One real concrete benefit of this is that we establish a space in which we
can develop rather more interesting discovery mechanisms that make use of
geographic location or account data to optimize discovery.

At the moment when I connect to gmail via POP3, I guess my client must be
connecting me to a tier 1 server whose only reason for existence is the need
to route my request to the place where the data is actually stored. Wouldn't
it be nice if we could possibly eliminate that tier at a future date? Think
of the carbon emissions we could save.


Sure there are performance issues to clear. But I think those can be
managed. The important thing here is to get the architecture right so that
applications have the right information to work with and get the most
efficient transport layer possible. We can work out how to save DNS round
trips as a lower priority.


2010/10/11 Patrik Fältström <paf@cisco.com>

> On 27 jul 2010, at 20.48, Ted Hardie wrote:
>
> > At the moment, the draft
>
> > describes a mechanism that
> > relies on two associated things:  a composed service name and an RR with
> format:
> >
> > Ownername TTL Class URI Priority Weight Target
> >
> > One composed service name example you give is
> >
> > $ORIGIN example.com.
> >   _http._web    IN URI 10 1 "http://www.example.com/"
> >
> > That is, someone looks up _http._web.example.com and discovers
> > this URI there.  The first issue is the one draft notes, that you
> > must know in advance to check for this in order to populate
> > the fields correctly.
>
> Correct.
>
> > For your "two domains, one homepage"
> > example, the querier must know in advance, in other words,
> > to check for the _http._web.example.net in order to
> > discover that there is another domain.  That's not going
> > to happen as an adjunct for standard web queries without
> > a lot of other work, so it really relies on some application
> > that wants that bit of data (as opposed to just wanting
> > the home page).
>
> That is correct. The use of the URI RR Type will only happen in new
> protocols, or new use. I do not think it will be used for existing
> protocols, like HTTP, or other protocols where you have inbound "redirect"
> functionality.
>
> > It's okay that it is only useful to applications that
> > already know they want it, but, unfortunately,
> > it's also not really enough.  _http._web is a very general
> > service name, and there is no way with that level of
> > granularity to know whether the URI you're getting
> > is meant to be an equivalent, an alternate, or to
> > stand in some other relationship (e.g. hold meta data).
>
> Correct, and that is why the actual service type registrations must be more
> precise. What I have in the draft (draft-faltstrom-uri-05) is the following:
>
> >    Valid service
> >    parameters used are those used for SRV resource records, or
> >    registered by IANA for Enumservice Registrations.
>
> What you say, which I agree with, is that "just" use of some prefixes
> without having them defined is dangerous. And this is why I am leaning
> towards either the Enumservice Registrations (where you have this issue) or
> the SRV resource records that according to the SRV spec is requiring further
> specification in its applicability statement:
>
> >    In general, it is expected that SRV records will be used by clients
> >    for applications where the relevant protocol specification indicates
> >    that clients should use the SRV record. Such specification MUST
> >    define the symbolic name to be used in the Service field of the SRV
> >    record as described below. It also MUST include security
> >    considerations. Service SRV records SHOULD NOT be used in the absence
> >    of such specification.
>
> Now, I do not see as much of a problem as you do, as whoever that is using
> the URI know already what it is after. It can either (as today) use a URI
> directly for the communication, or start by using a hostname, look up a URI
> RR and get back the URI to use.
>
> What I think you are after is in the case we have the following scenario:
>
> 1. The owner of a domain is publishing a URI RR for a specific service
> named foo, so the URI RR _foo._tcp.example. is provisioned.
> 2. The service name is overloaded, for not only what the owner of the name
> was thinking of, but also bar.
> 3. Someone that want to use the service bar, for the domain name example is
> also looking up _foo._tcp.example, get back the URI that was to be used for
> the foo service, and the application is at best "surprised".
>
> Here "foo" can be for example "web surfing" while "bar" can be for example
> calendaring that also uses the HTTP protocol.
>
> In this case, the service "bar" should use a specific scheme, for example
> _bar._tcp.example.
>
> And we once again hit a problem I do not think is "my" fault, but rather
> that we do not have a proper registry for service types. As you can see
> already there in the SRV spec.
>
> Yes, I was Area Director for apps area then, and did rise exactly this
> issue ;-)
>
> > Each pairing of composed service name and URI
> > has to have some semantic that tells you what the
> > URI has to do with the related service name.
>
> Agree, and my view is that that should be made in the service name (i.e. in
> the owner of the RR) and not anywhere in the resulting URI.
>
> Note that the service in the owner is not an encoding of the uri scheme. It
> is really a service definition/name. Many different such names can result in
> a URI using the HTTP scheme.
>
> > If I create a URI record at  _dns._udp.example.net
> > with a target of dns:example.org.?clAsS=IN;tYpE=CNAME
> > am I reporting the CNAMES which point to example.net?
> > Or am I telling you that example.net is authoritative for
> > the domain name that is the result of that query?
> > The service name and URI pointer aren't really enough
> > to know.
>
> I do not know what the spec of the dns service type says. Does one exist? I
> know there is a dns URI scheme.
>
> As you can see in RFC 4501 (from which I see you have grabbed this example
> ;-) ), the URI is for a resource record with the absolute name example.org,
> class IN and type CNAME. So a spec of the dns service must tell how to
> handle this case. I think your example is one where there must be subtypes.
> For example:
>
> _cname._in._dns._udp.example.net. IN URI 10 10
> "dns:example.org.?clAsS=IN;tYpE=CNAME"
>
> > You touch on this in the draft by noting that the service
> > name usage may be subtly different for each RR that uses,
> > but I think the situation is far more complicated than that.
> > URIs are inherently sub-typable (by scheme, query, etc.),
> > and that means that the semantics here seem to me to
> > need a much richer description capability than the draft
> > assumes.
>
> Hmm...I think a lot of work is needed for each service type.
>
> > I'm not sure that this explanation is all that much better,
> > so feel free to batter away at the results.
>
> I think you talk about more how the registration and spec of each service
> type is done, and not this spec. But maybe you want more stuff in this
> document? I have added some text about it.
>
>   Patrik
>
>
>


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