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

Patrik Fältström <paf@cisco.com> Mon, 11 October 2010 14:18 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 3FBB93A6A94; Mon, 11 Oct 2010 07:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.839
X-Spam-Level:
X-Spam-Status: No, score=-7.839 tagged_above=-999 required=5 tests=[AWL=2.460, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
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 paXL1q2H-lZl; Mon, 11 Oct 2010 07:18:24 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA97B3A6A9D; Mon, 11 Oct 2010 07:18:23 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1P5J6a-0009oJ-Sl for namedroppers-data0@psg.com; Mon, 11 Oct 2010 14:11:56 +0000
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from <paf@cisco.com>) id 1P5J6X-0009nt-8A for namedroppers@ops.ietf.org; Mon, 11 Oct 2010 14:11:53 +0000
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmcEAJe3skyQ/khNgWdsb2JhbACiDRUBARYiIqN2nDCFSASKQQ
X-IronPort-AV: E=Sophos;i="4.57,314,1283731200"; d="scan'208";a="66361903"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 11 Oct 2010 14:11:51 +0000
Received: from ams3-vpn-dhcp5444.cisco.com (ams3-vpn-dhcp5444.cisco.com [10.61.85.67]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o9BEBXcS012952; Mon, 11 Oct 2010 14:11:50 GMT
Subject: Re: [dnsext] URI RRTYPE review - Comments period end Aug 15th
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Patrik Fältström <paf@cisco.com>
In-Reply-To: <AANLkTinuNGYU_eoh5-Y=XJwmeo6psU_vPYt1vFAjq+Kk@mail.gmail.com>
Date: Mon, 11 Oct 2010 15:41:02 +0200
Cc: Frederico A C Neves <fneves@registro.br>, namedroppers@ops.ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: Ted Hardie <ted.ietf@gmail.com>
X-Mailer: Apple Mail (2.1081)
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/>

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