RE: Context specific semantics was Re: uncooperative DNSBLs, was several messages

Ted Hardie <hardie@qualcomm.com> Fri, 14 November 2008 17:50 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 505DC3A6906; Fri, 14 Nov 2008 09:50:01 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EEB73A6906 for <ietf@core3.amsl.com>; Fri, 14 Nov 2008 09:50:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.932
X-Spam-Level:
X-Spam-Status: No, score=-105.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 aF13JfI9IGIz for <ietf@core3.amsl.com>; Fri, 14 Nov 2008 09:49:59 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id AD01A3A67D8 for <ietf@ietf.org>; Fri, 14 Nov 2008 09:49:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1226685000; x=1258221000; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20<p06240602c54368e60f6b @[10.227.68.106]>|In-Reply-To:=20<alpine.LSU.2.00.0811141 555520.14367@hermes-1.csi.cam.ac.uk>|References:=20<Pine. LNX.4.33.0811121942450.12067-100000@egate.xpasc.com>=0D =0A=20<20081113112302.38928.qmail@simone.iecc.com>=0D=0A =20<e0c581530811130740g1db5cbfehbcdad361660bf48b@mail.gma il.com>=0D=0A=20<491C5339.8090801@dcrocker.net>=20<200811 13163833.GN76118@shinkuro.com>=0D=0A=20<491C699B.4000702@ nortel.com>=20<20081113180841.GO76118@shinkuro.com>=0D=0A =20<491C711C.3030605@leisi.net>=20<20081113183919.GR76118 @shinkuro.com>=0D=0A=20<p06240603c542266a5094@[10.227.68. 106]>=0D=0A=20<alpine.LSU.2.00.0811131922190.14367@hermes -1.csi.cam.ac.uk>=0D=0A=20<p06240605c54237e869f2@[10.227. 68.106]>,<alpine.LSU.2.00.0811141209490.143=0D=0A=2067@he rmes-1.csi.cam.ac.uk>=0D=0A=20<3C93394994880A4597E4710855 851C031EFCBA47@NASANEXMB12.na.qualcomm.com>=0D=0A=20<alpi ne.LSU.2.00.0811141555520.14367@hermes-1.csi.cam.ac.uk> |Date:=20Fri,=2014=20Nov=202008=2009:49:46=20-0800|To:=20 Tony=20Finch=20<dot@dotat.at>|From:=20Ted=20Hardie=20<har die@qualcomm.com>|Subject:=20RE:=20Context=20specific=20s emantics=20was=20Re:=20uncooperative=20DNSBLs,=20was=20 =0D=0A=20several=20messages|CC:=20Andrew=20Sullivan=20<aj s@shinkuro.com>,=20"ietf@ietf.org"=20<ietf@ietf.org> |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5433"=3B=20 a=3D"12959396"; bh=CwnqUGUr9xg26hVwXa4K8foYIHjMd0rRaDCC06E+0is=; b=MrkFB9eWNHISUYJMSM5XUvGycQG+rsOKCuiQ0/2L26Qo64Uxk7P645Co 1Qpr2c0DryJpxvyyTXAQt8uS2R06piOBbsjSm3dxDpMur0uOEpS4CLyLL wwcosYSPiNy9SuiKpOamVIDDKDqzDlGx9CishtWJXSni0/8kbBY29m5Kf g=;
X-IronPort-AV: E=McAfee;i="5300,2777,5433"; a="12959396"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Nov 2008 09:50:00 -0800
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAEHnxJW029619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Nov 2008 09:49:59 -0800
Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAEHnoCY013038 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 14 Nov 2008 09:49:57 -0800 (PST)
Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.311.2; Fri, 14 Nov 2008 09:49:50 -0800
Received: from [10.227.68.106] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 14 Nov 2008 09:49:49 -0800
MIME-Version: 1.0
Message-ID: <p06240602c54368e60f6b@[10.227.68.106]>
In-Reply-To: <alpine.LSU.2.00.0811141555520.14367@hermes-1.csi.cam.ac.uk>
References: <Pine.LNX.4.33.0811121942450.12067-100000@egate.xpasc.com> <20081113112302.38928.qmail@simone.iecc.com> <e0c581530811130740g1db5cbfehbcdad361660bf48b@mail.gmail.com> <491C5339.8090801@dcrocker.net> <20081113163833.GN76118@shinkuro.com> <491C699B.4000702@nortel.com> <20081113180841.GO76118@shinkuro.com> <491C711C.3030605@leisi.net> <20081113183919.GR76118@shinkuro.com> <p06240603c542266a5094@[10.227.68.106]> <alpine.LSU.2.00.0811131922190.14367@hermes-1.csi.cam.ac.uk> <p06240605c54237e869f2@[10.227.68.106]>, <alpine.LSU.2.00.0811141209490.143 67@hermes-1.csi.cam.ac.uk> <3C93394994880A4597E4710855851C031EFCBA47@NASANEXMB12.na.qualcomm.com> <alpine.LSU.2.00.0811141555520.14367@hermes-1.csi.cam.ac.uk>
Date: Fri, 14 Nov 2008 09:49:46 -0800
To: Tony Finch <dot@dotat.at>
From: Ted Hardie <hardie@qualcomm.com>
Subject: RE: Context specific semantics was Re: uncooperative DNSBLs, was several messages
Cc: "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 8:17 AM -0800 11/14/08, Tony Finch wrote:
>
>Note that I'm not arguing against a new RR type, I'm just trying to
>understand the arguments against the de facto standard.
>
>One significant advantage which I have not seen clearly articulated is
>that a new RR type could combine the functions that are currently
>performed by A records (bit vector) and TXT records (explanatory URL)
>which could greatly reduce the number DNS lookups.
>

I don't think is really the right list to go into this in detail, but I
agree that there are potential benefits to shifting to a new RR beyond
those related to the coherence of the DNS model.  Depending on
the syntax, it could well give you ways to distinguish among cases
which I believe some DNSBLs conflate now. For example, giving you
ways of distinguishing among the following cases:

1) We have no data, positive or negative, about the record queried.

2) We have data about the record queried and it has a positive reputation

3) We have data about the record queried and it is mixed; we see spam
and we see  non-spam email as well.

4) We have data about the record queried and we believe to be all spam

1 & 2 are easily conflated, as are 3 and 4.  Giving you richer ways
of handling that would enable you to let the customer make more
individualized decisions.  Data on the freshness of the information is also
not easily carried in the A-record style response (without then re-using
another aspect of the DNS, the TTL, in a subtly different way).  Many users
may not want to interpret this data, obviously, as they want the simplest check
possible so that run-time processing is possible.  But it is trivially easy
to re-conflate.

			regards,
				Ted Hardie



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