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

"Marc Lampo" <marc.lampo@eurid.eu> Wed, 30 March 2011 13:16 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 1AA1128C12F for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 06:16:11 -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 CTpwwolIvFvB for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 06:16:10 -0700 (PDT)
Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by core3.amsl.com (Postfix) with ESMTP id 5F0D128C108 for <dnsext@ietf.org>; Wed, 30 Mar 2011 06:16:09 -0700 (PDT)
X-ASG-Debug-ID: 1301491065-5cfc5dd60001-uIE7UK
Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id KSqcwyt6hqOd7sbH; Wed, 30 Mar 2011 15:17:45 +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 D245DE408C; Wed, 30 Mar 2011 15:12:16 +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 RqSbE69pYX8Z; Wed, 30 Mar 2011 15:12:16 +0200 (CEST)
Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id BF5DBE407F; Wed, 30 Mar 2011 15:12:16 +0200 (CEST)
From: "Marc Lampo" <marc.lampo@eurid.eu>
To: "'Tony Finch'" <dot@dotat.at>, "'Mark Andrews'" <marka@isc.org>
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>
In-Reply-To: <alpine.LSU.2.00.1103301218140.5244@hermes-1.csi.cam.ac.uk>
Date: Wed, 30 Mar 2011 15:12:16 +0200 (CEST)
X-ASG-Orig-Subj: RE: [dnsext] caches, validating resolvers, CD and DO
Message-ID: <005301cbeedc$e9653150$bc2f93f0$@lampo@eurid.eu>
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: AcvuzE83ld9tw24tRnuDBEGu1E+sfwAEENiw
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: 1301491065
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 13:16:11 -0000

Mark Andrews <marka@isc.org> wrote:
>
> A validating resolver with direct access to the athoritative servers
> can work around a number of operational errors by being able to
> retry the query with different servers.

>From the security point of view, letting "resolvers" (on end-user PC's)
have access to authoritative servers is not a good idea.
End-users should forward there queries to (internal ?) forwarding or
caching name servers (only).
Only then one can implement security on DNS traffic flows.
Otherwise the firewall rule is : "any(internal)" to "any(external)" for
port 53 : allow
Which I'd disrecommend ... sorry.

Marc Lampo