Re: [DNSOP] Public Suffix List

["Yngve Nysaeter Pettersen" <[e-mail]>]

On Thu, 12 Jun 2008 14:54:32 +0200, Niall O'Reilly <[e-mail]>  
wrote:

>
> On 12 Jun 2008, at 12:25, Gervase Markham wrote:
>
>> The second question is one of resources and client complexity. I am
>> meeting resistance to the idea of having the existing list regularly
>> dynamically downloaded, which would be the simplest method of
>> providing
>> more frequent updates than the six-to-eight week Firefox security
>> releases. An assemble-and-cache-the-data-from-DNS scheme would be an
>> order of magnitude more complex.
>
> 	I'm not sure why you would need to assemble anything.
> 	Couldn't you seize the data you need, on demand, from
> 	the DNS (and cache at will).

DNS, or full DNS, is not always available.

There are at least two scenarios where this is the case:

  - Behind (very) closed firewalls, where all access go through a HTTP-only  
proxy. No DNS for external addresses is available. For that matter, when  
going through a proxy you have no way of knowing if the DNS available to  
you know anything about the address space you are accessing through the  
proxy.

  From [e-mail]  Thu Jun 12 06:25:55 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B50713A6939;
	Thu, 12 Jun 2008 06:25:55 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 12A843A6939
	for <[e-mail]>; Thu, 12 Jun 2008 06:25:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.524
X-Spam-Level: 
X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 
	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 ib8e6KG44K3y for <[e-mail]>;
	Thu, 12 Jun 2008 06:25:54 -0700 (PDT)
Received: from mail.opera.com (mail.opera.com [213.236.208.66])
	by core3.amsl.com (Postfix) with ESMTP id B28CD3A6915
	for <[e-mail]>; Thu, 12 Jun 2008 06:25:53 -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
	m5CDQFJ9030205; Thu, 12 Jun 2008 13:26:15 GMT
Date: Thu, 12 Jun 2008 15:26:16 +0200
To: "Niall O'Reilly" <[e-mail]>, "IETF DNSOP WG" <[e-mail]>
From: "Yngve Nysaeter Pettersen" <[e-mail]>
Organization: Opera Software
MIME-Version: 1.0
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]> <[e-mail]>
	<[e-mail]> <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Opera Mail/9.27 (Win32)
Subject: Re: [DNSOP] Public Suffix List
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

On Thu, 12 Jun 2008 14:54:32 +0200, Niall O'Reilly <[e-mail]>  
wrote:

>
> On 12 Jun 2008, at 12:25, Gervase Markham wrote:
>
>> The second question is one of resources and client complexity. I am
>> meeting resistance to the idea of having the existing list regularly
>> dynamically downloaded, which would be the simplest method of
>> providing
>> more frequent updates than the six-to-eight week Firefox security
>> releases. An assemble-and-cache-the-data-from-DNS scheme would be an
>> order of magnitude more complex.
>
> 	I'm not sure why you would need to assemble anything.
> 	Couldn't you seize the data you need, on demand, from
> 	the DNS (and cache at will).

DNS, or full DNS, is not always available.

There are at least two scenarios where this is the case:

  - Behind (very) closed firewalls, where all access go through a HTTP-only  
proxy. No DNS for external addresses is available. For that matter, when  
going through a proxy you have no way of knowing if the DNS available to  
you know anything about the address space you are accessing through the  
proxy.

  - - On a number of systems, in particular phone devices, the application  
does not even have access to DNS to do a name lookup, it must specify the  
hostname, and try to connect.

Additionally, a DNS-only solution would mean implementing a DNS client  
inside the application, since AFAICT the platform socket APIs usually do  
not provide the necessary functionality needed to access non-IPaddress  
data.

While I am not opposed to the data being available in DNS, there must be a  
simple way to collect and provide it to clients efficiently and for any  
use case, while reducing privacy issues (which a batch of data for a given  
TLD will solve neatly), and with respect to HTTP clients, HTTP is the only  
method we can rely on, and it will also be available to many specialized  
applications that use HTTP, perhaps through some library.


-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		                 Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop


On a number of systems, in particular phone devices, the application  
does not even have access to DNS to do a name lookup, it must specify the  
hostname, and try to connect.

Additionally, a DNS-only solution would mean implementing a DNS client  
inside the application, since AFAICT the platform socket APIs usually do  
not provide the necessary functionality needed to access non-IPaddress  
data.

While I am not opposed to the data being available in DNS, there must be a  
simple way to collect and provide it to clients efficiently and for any  
use case, while reducing privacy issues (which a batch of data for a given  
TLD will solve neatly), and with respect to HTTP clients, HTTP is the only  
method we can rely on, and it will also be available to many specialized  
applications that use HTTP, perhaps through some library.


-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		                 Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop