Re: [DNSOP] Public Suffix List

Brian Dickson <briand@ca.afilias.info> Mon, 09 June 2008 16:56 UTC

Return-Path: <dnsop-bounces@ietf.org>
X-Original-To: dnsop-archive@lists.ietf.org
Delivered-To: ietfarch-dnsop-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ED183A6C63; Mon, 9 Jun 2008 09:56:52 -0700 (PDT)
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C91E3A6C52 for <dnsop@core3.amsl.com>; Mon, 9 Jun 2008 09:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level:
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 bMSep4SC6PN7 for <dnsop@core3.amsl.com>; Mon, 9 Jun 2008 09:56:50 -0700 (PDT)
Received: from mx4.ca.afilias.info (vgateway.libertyrms.info [207.219.45.62]) by core3.amsl.com (Postfix) with ESMTP id 6CFE13A6C46 for <dnsop@ietf.org>; Mon, 9 Jun 2008 09:56:50 -0700 (PDT)
Received: from briand-vpn.int.libertyrms.com ([10.1.7.90]) by mx4.ca.afilias.info with esmtp (Exim 4.22) id 1K5kg6-0007zf-H5; Mon, 09 Jun 2008 12:57:06 -0400
Message-ID: <484D60DC.1090400@ca.afilias.info>
Date: Mon, 09 Jun 2008 12:57:00 -0400
From: Brian Dickson <briand@ca.afilias.info>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Gervase Markham <gerv@mozilla.org>
References: <484CFF47.1050106@mozilla.org> <484D1533.4060300@spaghetti.zurich.ibm.com> <484D1883.4060002@mozilla.org> <666CCACE-71F0-485D-9C9F-0C3E0C965ADA@virtualized.org> <484D52EC.1090608@mozilla.org> <C5894EBB-D4AA-40AD-8A38-2F4CD8A07D66@virtualized.org> <484D5B88.3090902@mozilla.org>
In-Reply-To: <484D5B88.3090902@mozilla.org>
X-SA-Exim-Mail-From: briand@ca.afilias.info
X-SA-Exim-Scanned: No; SAEximRunCond expanded to false
Cc: dnsop@ietf.org, David Conrad <drc@virtualized.org>, ietf-http-wg@w3.org
Subject: Re: [DNSOP] Public Suffix List
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsop-bounces@ietf.org
Errors-To: dnsop-bounces@ietf.org

Gervase Markham wrote:
> We've had this basic problem in the domain of cookies for years. I don't
> expect another solution to pop out of the woodwork now. But I'm open to
> being surprised :-)
>   

Surprise!

If you want grouping, there is a simple-to-code, reliable, and 
authoritative way to do so.

Zone cuts (in DNS).

(Note well - a zone is not semantically identical to a domain, although 
they can at times seem that way.
In particular, if a child domain is served by the same server(s) as the 
parent, there will not be a zone cut.
This, I believe, will generally do a good job of permitting grouping 
automagically.)

Where there is a delegation of authority, via a zone cut, that is 
*exactly* where you want to group.

And in the absence of a zone cut, you do not want separation by grouping.

That (among other things) is what distinguishes "foo.co.uk" from 
"myprivatesubdomain.foo.com".

Perhaps examining other aspects of DNS responses may further inform the 
device needing to determine grouping.
Things like presence/absence of glue (at particular places, e.g. 
root/TLD), commonality of NS instances between parent/child, etc.

Whether this gets done by the end-user's client, or by some 
more-centralized box, is an implementation issue (but one that should be 
given lots of thought!!).

ButFrom dnsop-bounces@ietf.org  Mon Jun  9 09:56:52 2008
Return-Path: <dnsop-bounces@ietf.org>
X-Original-To: dnsop-archive@optimus.ietf.org
Delivered-To: ietfarch-dnsop-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 9ED183A6C63;
	Mon,  9 Jun 2008 09:56:52 -0700 (PDT)
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 6C91E3A6C52
	for <dnsop@core3.amsl.com>; Mon,  9 Jun 2008 09:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level: 
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 bMSep4SC6PN7 for <dnsop@core3.amsl.com>;
	Mon,  9 Jun 2008 09:56:50 -0700 (PDT)
Received: from mx4.ca.afilias.info (vgateway.libertyrms.info [207.219.45.62])
	by core3.amsl.com (Postfix) with ESMTP id 6CFE13A6C46
	for <dnsop@ietf.org>; Mon,  9 Jun 2008 09:56:50 -0700 (PDT)
Received: from briand-vpn.int.libertyrms.com ([10.1.7.90])
	by mx4.ca.afilias.info with esmtp (Exim 4.22)
	id 1K5kg6-0007zf-H5; Mon, 09 Jun 2008 12:57:06 -0400
Message-ID: <484D60DC.1090400@ca.afilias.info>
Date: Mon, 09 Jun 2008 12:57:00 -0400
From: Brian Dickson <briand@ca.afilias.info>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Gervase Markham <gerv@mozilla.org>
References: <484CFF47.1050106@mozilla.org>	<484D1533.4060300@spaghetti.zurich.ibm.com>	<484D1883.4060002@mozilla.org>	<666CCACE-71F0-485D-9C9F-0C3E0C965ADA@virtualized.org>	<484D52EC.1090608@mozilla.org>	<C5894EBB-D4AA-40AD-8A38-2F4CD8A07D66@virtualized.org>
	<484D5B88.3090902@mozilla.org>
In-Reply-To: <484D5B88.3090902@mozilla.org>
X-SA-Exim-Mail-From: briand@ca.afilias.info
X-SA-Exim-Scanned: No; SAEximRunCond expanded to false
Cc: dnsop@ietf.org, David Conrad <drc@virtualized.org>, ietf-http-wg@w3.org
Subject: Re: [DNSOP] Public Suffix List
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:dnsop-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsop-bounces@ietf.org
Errors-To: dnsop-bounces@ietf.org

Gervase Markham wrote:
> We've had this basic problem in the domain of cookies for years. I don't
> expect another solution to pop out of the woodwork now. But I'm open to
> being surprised :-)
>   

Surprise!

If you want grouping, there is a simple-to-code, reliable, and 
authoritative way to do so.

Zone cuts (in DNS).

(Note well - a zone is not semantically identical to a domain, although 
they can at times seem that way.
In particular, if a child domain is served by the same server(s) as the 
parent, there will not be a zone cut.
This, I believe, will generally do a good job of permitting grouping 
automagically.)

Where there is a delegation of authority, via a zone cut, that is 
*exactly* where you want to group.

And in the absence of a zone cut, you do not want separation by grouping.

That (among other things) is what distinguishes "foo.co.uk" from 
"myprivatesubdomain.foo.com".

Perhaps examining other aspects of DNS responses may further inform the 
device needing to determine grouping.
Things like presence/absence of glue (at particular places, e.g. 
root/TLD), commonality of NS instances between parent/child, etc.

Whether this gets done by the end-user's client, or by some 
more-centralized box, is an implementation issue (but one that should be 
given lots of thought!!).

But, it is better to trust information already published, which is 
required for proper operation of DNS, than to look for additional 
information that may become stale or inconsistent.

Brian Dickson


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


, it is better to trust information already published, which is 
required for proper operation of DNS, than to look for additional 
information that may become stale or inconsistent.

Brian Dickson


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop