Re: [DNSOP] my dnse vision (3 cases)

Francis Dupont <Francis.Dupont@fdupont.fr> Thu, 06 March 2014 14:40 UTC

Return-Path: <Francis.Dupont@fdupont.fr>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1E01A0429 for <dnsop@ietfa.amsl.com>; Thu, 6 Mar 2014 06:40:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSbyovfsOyWe for <dnsop@ietfa.amsl.com>; Thu, 6 Mar 2014 06:40:06 -0800 (PST)
Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id B18B91A0434 for <dnsop@ietf.org>; Thu, 6 Mar 2014 06:39:59 -0800 (PST)
Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id s26EdtPV073218 for <dnsop@ietf.org>; Thu, 6 Mar 2014 15:39:55 +0100 (CET) (envelope-from dupont@givry.fdupont.fr)
Message-Id: <201403061439.s26EdtPV073218@givry.fdupont.fr>
From: Francis Dupont <Francis.Dupont@fdupont.fr>
To: dnsop@ietf.org
Date: Thu, 06 Mar 2014 15:39:55 +0100
Sender: Francis.Dupont@fdupont.fr
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/gxVa0ZUtW51t9sfdka4hSWRUGCQ
Subject: Re: [DNSOP] my dnse vision (3 cases)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Mar 2014 14:40:08 -0000

This is an update of my previous messages.

The generic DNS confidentiality problem can be divided into 3 cases:

 1- stubs <-> local resolver

 2- stubs <-> remote open resolver

 3- resolver <-> auth. servers

In the first case the local resolver is in the same security area
(I use "area" to avoid to overload "domain" or "zone") than clients/
stubs (and the infrastructure between them two). This covers the
case where the resolver is physically local and the one where a
mobile client is securely connected to the local network, so the
usual perimeter/VPN/etc including nomadic VPNs. As DNS is in the 1-
case only one of the services to protect I consider without a strong
argument for the opposite the security will be provided by a general
(vs. a DNS one) mechanism so doesn't need a DNSE solution.
BTW usually in the 1- case the resolver is dual headed so
authentication and authorization are already required/provided.

2- is about a very low number of remote open resolvers so
again without an explicit request I suggest we consider it is
a private issue between the open resolver service and its customers.
Note the environment is very different than 3- so even it has to
be addressed 2- should lead to a different solution too.

So we have to address 3-, and to begin by qname minimization
(which is also minimal on many aspects :-).

Regards

Francis.Dupont@fdupont.fr