Re: [DNSOP] Public Suffix List

Brian Dickson <> Thu, 12 June 2008 14:08 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 3B2DD3A6AD0; Thu, 12 Jun 2008 07:08:37 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63C843A69D8 for <>; Thu, 12 Jun 2008 07:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.17
X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1L5sPD5Nych9 for <>; Thu, 12 Jun 2008 07:08:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5091E3A6AD0 for <>; Thu, 12 Jun 2008 07:08:35 -0700 (PDT)
Received: from ([]) by with esmtp (Exim 4.22) id 1K6nU6-0004QH-M4; Thu, 12 Jun 2008 10:09:02 -0400
Message-ID: <>
Date: Thu, 12 Jun 2008 10:08:50 -0400
From: Brian Dickson <>
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-SA-Exim-Scanned: No; SAEximRunCond expanded to false
Cc: IETF DNSOP WG <>, Niall O'Reilly <>
Subject: Re: [DNSOP] Public Suffix List
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Yngve Nysaeter Pettersen wrote:
> On Thu, 12 Jun 2008 14:54:32 +0200, Niall O'Reilly <>  
> 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.

A DNS-based solution does not *need* to be a DNS-*only* solution.

As I understand it, your list associates suffixes with "true/false" 
state, i.e. whether they are public or not.

Imagine a tree of subdomains, all of which exist only to provide 
true/false information, rooted at, say, If a given subdomain exists, "true", otherwise 
"false". And for http-only scenarios,
have each of these subdomains be a CNAME pointing a static web page, say 
which contains just the word "True".

Both the content of the pages, and the DNS entries, could be cached in 
their respective systems
(web browser cache, or DNS resolver cache). Timeliness of updates would 
be maintained by appropriate
mechanisms to tell the querying agent to check again (HTTP tag or DNS TTL).

The HTTP side of things does not require a separate DNS client. But, the 
updates to the list can
be made trivially by manipulation of DNS data alone, and use of DNS 
involves much less processing
on the client side if DNS client querying is possible (one UDP packet, 


> 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.

DNSOP mailing list