Re: [dnsext] caches, validating resolvers, CD and DO

"Marc Lampo" <marc.lampo@eurid.eu> Wed, 30 March 2011 15:27 UTC

Return-Path: <marc.lampo@eurid.eu>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBD2C3A69C0 for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 08:27:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level:
X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449]
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 tZda8TZgyb1J for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 08:27:10 -0700 (PDT)
Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by core3.amsl.com (Postfix) with ESMTP id DF1943A68B8 for <dnsext@ietf.org>; Wed, 30 Mar 2011 08:27:09 -0700 (PDT)
X-ASG-Debug-ID: 1301498928-5cfb5edf0001-uIE7UK
Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id hx1FM1t9m0GqkG79; Wed, 30 Mar 2011 17:28:48 +0200 (CEST)
X-Barracuda-Envelope-From: marc.lampo@eurid.eu
X-ASG-Whitelist: Client
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 3CA7BE4059; Wed, 30 Mar 2011 17:23:19 +0200 (CEST)
X-Virus-Scanned: amavisd-new at techmail.eurid.eu
Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vUQb9iE-Jsv; Wed, 30 Mar 2011 17:23:19 +0200 (CEST)
Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 273CEE4050; Wed, 30 Mar 2011 17:23:19 +0200 (CEST)
From: Marc Lampo <marc.lampo@eurid.eu>
To: 'Mark Andrews' <marka@isc.org>, 'Nicholas Weaver' <nweaver@icsi.berkeley.edu>
References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <0CAE569785C163CFE87B957E@nimrod.local><46410.1301468733@nsa.vix.com> <20110330081029.867FDDAD484@drugs.dv.isc.org> <alpine.LSU.2.00.1103301218140.5244@hermes-1.csi.cam.ac.uk> <005301cbeedc$e9653150$bc2f93f0$@lampo@eurid.eu> <B433F924-C6B8-497C-9D59-79CD5307C84D@icsi.berkeley.edu> <20110330152241.CAA97DB0215@drugs.dv.isc.org>
In-Reply-To: <20110330152241.CAA97DB0215@drugs.dv.isc.org>
Date: Wed, 30 Mar 2011 17:23:19 +0200
X-ASG-Orig-Subj: RE: [dnsext] caches, validating resolvers, CD and DO
Message-ID: <009d01cbeeef$37c394b0$a74abe10$@lampo>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraConnectorForOutlook/5.0.3064.18)
Thread-Index: Acvu7aouU3J9ZmlyTwy4QXye5P0OmQAAQeQg
Content-Language: en-za
X-Originating-IP: [172.20.5.39]
X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121]
X-Barracuda-Start-Time: 1301498928
X-Barracuda-URL: http://172.20.1.190:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at eurid.eu
Cc: dnsext@ietf.org
Subject: Re: [dnsext] caches, validating resolvers, CD and DO
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Mar 2011 15:27:10 -0000

-----Original Message-----
From: Mark Andrews [mailto:marka@isc.org] 
Sent: 30 March 2011 05:23 PM
To: Nicholas Weaver
Cc: Marc Lampo; 'Tony Finch'; dnsext@ietf.org
Subject: Re: [dnsext] caches, validating resolvers, CD and DO

...

> That's nice when you can do it, but there are lots of enviroments
> where you can't.  We need to make those deployment senarios work.
> Failures are not alway malicious.

Most (if not : all) (DNSSEC validation) failures I have seen myself, up
till now,
were indeed *not* malicious.
They were because of failing management on the authoritative NS side ...

This being said :
contacting them directly would simply yield the same validation error.

Marc