Re: [DNSOP] Public Suffix List

"Yngve Nysaeter Pettersen" <yngve@opera.com> Thu, 12 June 2008 14:07 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 753833A6ADC; Thu, 12 Jun 2008 07:07:00 -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 617EB3A6800 for <dnsop@core3.amsl.com>; Thu, 12 Jun 2008 07:06:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.539
X-Spam-Level:
X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 NZggMY+WmdWV for <dnsop@core3.amsl.com>; Thu, 12 Jun 2008 07:06:53 -0700 (PDT)
Received: from mail.opera.com (mail.opera.com [213.236.208.66]) by core3.amsl.com (Postfix) with ESMTP id 39C7F3A67F7 for <dnsop@ietf.org>; Thu, 12 Jun 2008 07:06:51 -0700 (PDT)
Received: from killashandra.oslo.opera.com (pat-tdc.opera.com [213.236.208.22]) by mail.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m5CE7IJu014084; Thu, 12 Jun 2008 14:07:18 GMT
Date: Thu, 12 Jun 2008 16:07:19 +0200
To: "Ted Lemon" <Ted.Lemon@nominum.com>, "Gervase Markham" <gerv@mozilla.org>
From: "Yngve Nysaeter Pettersen" <yngve@opera.com>
Organization: Opera Software
MIME-Version: 1.0
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> <B9478927-1EBC-4363-914E-24839604481A@nominum.com> <485107C0.3010106@mozilla.org> <840AA5F1-3B35-4547-ADBC-979ED77CE757@nominum.com>
Message-ID: <op.ucm2uhtdvqd7e2@killashandra.oslo.opera.com>
In-Reply-To: <840AA5F1-3B35-4547-ADBC-979ED77CE757@nominum.com>
User-Agent: Opera Mail/9.27 (Win32)
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] Public Suffix List
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: yngve@opera.com
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 Thu, 12 Jun 2008 15:56:13 +0200, Ted Lemon <Ted.Lemon@nominum.com>  
wrote:

> On Jun 12, 2008, at 6:25 AM, Gervase Markham wrote:
>> Is there a particular reason that DNS is a better mechanism than HTTP,
>> in your view? Or is that an implementation detail?
>
> The DNS occurred to me because it's already used for carrying domain  
> names, and also because I've been doing DNS for a long time, so it's a  
> comfortable tool for me.
>
> HTTP would work as long as the queries were for specific domain names.    
> However, you would miss taking advantage of all the work DNS server  
> implementors have done to make DNS lookups really fast.
>
> Also, I suspect the overhead of an HTTP request is substantially higher  
> than the overhead of a DNS request when you think about all the groovy  
> headers that normally get stuffed into HTTP, particularly if you want to  
> use SSL.   With DNSSEC, the DNSSEC server signs a zone once and then  
> just answers you with the signed data when you ask for it.  Whereas with  
> HTTPS the HTTP server has to re-sign the data for every query.

The way I envision a dynamically updated system for this (see my draft),  
the information would be grouped for each TLD in a single file that the  
client downloads every 30 days when needed. That means that the overhead  
is kept to a minimum.

Where the information in the file(s) comes from is a separate topic. It  
can be a database maintained somewhere, or it could be DNS (but in that  
case it would have to be traversable).


-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		                 Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop