Re: [DNSOP] Public Suffix List

Ted Lemon <Ted.Lemon@nominum.com> Wed, 11 June 2008 16:15 UTC

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 8CB473A67B2; Wed, 11 Jun 2008 09:15:31 -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 D5F513A67E6 for <dnsop@core3.amsl.com>; Wed, 11 Jun 2008 09:15:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.979
X-Spam-Level:
X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24]
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 OvX9bCjDOXHK for <dnsop@core3.amsl.com>; Wed, 11 Jun 2008 09:15:28 -0700 (PDT)
Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id ED0653A67AD for <dnsop@ietf.org>; Wed, 11 Jun 2008 09:15:02 -0700 (PDT)
Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Wed, 11 Jun 2008 09:15:27 PDT
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id 0F08C56860; Wed, 11 Jun 2008 09:15:27 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.0.1.103] (67.9.133.211) by webmail.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 11 Jun 2008 09:15:26 -0700
Message-ID: <B9478927-1EBC-4363-914E-24839604481A@nominum.com>
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Gervase Markham <gerv@mozilla.org>
In-Reply-To: <484FB672.1080703@mozilla.org>
MIME-Version: 1.0 (Apple Message framework v924)
Date: Wed, 11 Jun 2008 11:15:24 -0500
References: <484CFF47.1050106@mozilla.org> <20080609142926.GC83012@commandprompt.com> <484D4191.104@mozilla.org> <20080609154002.GA93967@commandprompt.com> <484D5206.3000806@mozilla.org> <20080609214215.GF10260@commandprompt.com> <1B8CFAA1-E30A-4461-8B4E-BFF6E3A3A39C@nominum.com> <20080610080209.GA1365@nic.fr> <484E5318.7040502@mozilla.org> <sd8wxdz2it.fsf@wes.hardakers.net> <484FB672.1080703@mozilla.org>
X-Mailer: Apple Mail (2.924)
Cc: dnsop@ietf.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

On Jun 11, 2008, at 6:26 AM, Gervase Markham wrote:
> It's not true that we won't work on any other solution. This is what  
> we
> have now, and there have been no alternative proposals which (to my
> mind) look like producing anything workable in the short term.

Putting the list in the DNS instead of in the browser isn't  
workable?   Serious question.   I think several proposals have been  
advanced here that /could/ work.   Mine has the virtue of being  
completely under your control.   The other one, where subdomains are  
called out in the zones of the domains that contain them, is not under  
your control, and wouldn't be a good interim solution, but sounds like  
a good long-term solution because it puts correctness in the hands of  
the people who suffer or benefit from it.

So what I would personally like to see here is a staged transition.    
In the first stage, mozilla.org would set up a TLD list in its own DNS  
space, or in some new subdomain they register with good anycast  
replication so that no individual server has to bear the entire  
load.   This list would be maintained by mozilla.org, using  
information from registries and domain owners, and also using your  
current ad-hoc system.

But you'd also implement the system that was proposed here where the  
registries themselves can publish this information in their own  
domains.   And over time, the hope would be that the number of TLDs  
you'd have to maintain in your list would slowly dwindle, to the point  
where it would become more of a quirks list than a registry of its  
own.  This could work because the incentives are in the right  
direction - sites that have problems with your ad-hoc registry can  
either contact you or fix their own DNS, and fixing their own DNS may  
well be easier.

I haven't heard you responding that either of these solutions wouldn't  
work, so I'm assuming they would, but perhaps I'm wrong.   It also may  
be the case that for reasons of practicality you need to start with a  
list embedded in the browser; as long as you have a plan to make the  
transition to a list that's maintained more dynamically, and as long  
as you actually execute that plan, it seems to me that this is harmless.

BTW, thanks for your reasoned responses to all these questions and  
accusations being thrown at you.   You seem to have really elicited a  
lot of energetic response with your initial request, and I hope that  
something good will come of it.

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