Re: [DNSOP] An approach to DNS privacy

Florian Weimer <fw@deneb.enyo.de> Sun, 09 March 2014 10:28 UTC

Return-Path: <fw@deneb.enyo.de>
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 A44B31A0334 for <dnsop@ietfa.amsl.com>; Sun, 9 Mar 2014 03:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] 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 QEkNG1aEdmI3 for <dnsop@ietfa.amsl.com>; Sun, 9 Mar 2014 03:28:25 -0700 (PDT)
Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8137B1A0240 for <dnsop@ietf.org>; Sun, 9 Mar 2014 03:28:25 -0700 (PDT)
Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1WMaxu-0003fI-NT; Sun, 09 Mar 2014 11:28:18 +0100
Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from <fw@deneb.enyo.de>) id 1WMaxu-0002J5-J6; Sun, 09 Mar 2014 11:28:18 +0100
From: Florian Weimer <fw@deneb.enyo.de>
To: Phillip Hallam-Baker <hallam@gmail.com>
References: <CAMm+LwgZOPvGX_mzqmpt1zDj3cZdF0y2du=Di5q8Vfo4aYjNYw@mail.gmail.com>
Date: Sun, 09 Mar 2014 11:28:18 +0100
In-Reply-To: <CAMm+LwgZOPvGX_mzqmpt1zDj3cZdF0y2du=Di5q8Vfo4aYjNYw@mail.gmail.com> (Phillip Hallam-Baker's message of "Sat, 8 Mar 2014 15:57:24 -0500")
Message-ID: <87lhwj8y4d.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/o13v8V-Le0DcP9J6_O0WKLNdEkA
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] An approach to DNS privacy
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: Sun, 09 Mar 2014 10:28:28 -0000

* Phillip Hallam-Baker:

> For a heavily trafficked resolver, the resolver-authoritative
> interaction can be addressed with caching and by pre-fetching the
> bulk of the requests.  But this approach does not work so well for
> the lightly trafficked resolver and especially not a local resolver
> deployed in a home network.

Does encryption really make a difference there?  In most
jurisdictions, home networks use recursive resolvers whose operators
are required by law to provide cleartext copies to local authorities.
Encryption won't change that.

If it is about securing broadcast media, just run IPsec between the
CPE and the first ISP router with trusted ARP and routing tables.