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

Francis Dupont <> Thu, 06 March 2014 14:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6D1E01A0429 for <>; Thu, 6 Mar 2014 06:40:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JSbyovfsOyWe for <>; Thu, 6 Mar 2014 06:40:06 -0800 (PST)
Received: from ( [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by (Postfix) with ESMTP id B18B91A0434 for <>; Thu, 6 Mar 2014 06:39:59 -0800 (PST)
Received: from (localhost []) by (8.14.3/8.14.3) with ESMTP id s26EdtPV073218 for <>; Thu, 6 Mar 2014 15:39:55 +0100 (CET) (envelope-from
Message-Id: <>
From: Francis Dupont <>
Date: Thu, 06 Mar 2014 15:39:55 +0100
Subject: Re: [DNSOP] my dnse vision (3 cases)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 :-).