Re: [DNSOP] Public Suffix List

[Ted Lemon <[e-mail]>]

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 normalFrom [e-mail]  Thu Jun 12 06:56:25 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 4F0E03A6AE7;
	Thu, 12 Jun 2008 06:56:25 -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 190A93A6AE7
	for <[e-mail]>; Thu, 12 Jun 2008 06:56:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.475
X-Spam-Level: 
X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, 
	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 IiiPDZ6iA-AJ for <[e-mail]>;
	Thu, 12 Jun 2008 06:56:23 -0700 (PDT)
Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214])
	by core3.amsl.com (Postfix) with ESMTP id 4E3A13A6AAA
	for <[e-mail]>; Thu, 12 Jun 2008 06:55:50 -0700 (PDT)
Received: from source ([64.89.228.228]) (using TLSv1) by
	exprod7ob114.postini.com ([64.18.6.12]) with SMTP; 
	Thu, 12 Jun 2008 06:56:17 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 3CDE056860;
	Thu, 12 Jun 2008 06:56:17 -0700 (PDT)
	(envelope-from [e-mail])
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;
	Thu, 12 Jun 2008 06:56:16 -0700
Message-ID: <[e-mail]>
From: Ted Lemon <[e-mail]>
To: Gervase Markham <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0 (Apple Message framework v924)
Date: Thu, 12 Jun 2008 08:56:13 -0500
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]>
X-Mailer: Apple Mail (2.924)
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [DNSOP] Public Suffix List
X-BeenThere: [e-mail]
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:[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 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.

Also if you use DNS you get to take advantage of peoples' DNS caches  
to reduce the load on your server.   If you use HTTPS, your server is  
going to see every query from every client.

> An assemble-and-cache-the-data-from-DNS scheme would be an
> order of magnitude more complex.

That really wasn't what I had in mind.   What I had in mind was more  
of a lazy evaluation scheme, where you look the data up when you need  
it, and if the lookup fails you fail safe (that is, treat the domains  
as if they are not equivalent).   I don't think either scheme is  
really all that complex, but I admit that I probably don't know what  
the issues are.   I guess you're trying to avoid the possibility of  
the lookup failing, which makes sense, but if you have good anycast  
coverage I don't think that's a real issue - if the DNS isn't working,  
the page fetch would have failed.

Please let me know if there's anything I can do to help.

_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop


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

Also if you use DNS you get to take advantage of peoples' DNS caches  
to reduce the load on your server.   If you use HTTPS, your server is  
going to see every query from every client.

> An assemble-and-cache-the-data-from-DNS scheme would be an
> order of magnitude more complex.

That really wasn't what I had in mind.   What I had in mind was more  
of a lazy evaluation scheme, where you look the data up when you need  
it, and if the lookup fails you fail safe (that is, treat the domains  
as if they are not equivalent).   I don't think either scheme is  
really all that complex, but I admit that I probably don't know what  
the issues are.   I guess you're trying to avoid the possibility of  
the lookup failing, which makes sense, but if you have good anycast  
coverage I don't think that's a real issue - if the DNS isn't working,  
the page fetch would have failed.

Please let me know if there's anything I can do to help.

_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop