Re: [Add] [EXTERNAL] Re: Browser Administrative Authority

Neil Cook <neil.cook@open-xchange.com> Tue, 28 May 2019 07:56 UTC

Return-Path: <neil.cook@open-xchange.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994BA120119 for <add@ietfa.amsl.com>; Tue, 28 May 2019 00:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com
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 5rS0F_UM-8tO for <add@ietfa.amsl.com>; Tue, 28 May 2019 00:56:51 -0700 (PDT)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1FC12004A for <add@ietf.org>; Tue, 28 May 2019 00:56:50 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 16BFB6A28B; Tue, 28 May 2019 09:56:47 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1559030207; bh=N54Yw6Wjbui2g8mXzehsf0CScc6kvJRKJgy9LC5yP1E=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=aYabRpesT+87OM2uTZhTGr1OUuy/WJ508rPRq3oCPpDnmVKI9obA1EeARtIftNmi+ GU4t8BkZAW650A0JeSzZxbM7++50ZOGpH0ebOHVtvYDEMumyuiLi/Wwntfxs/z5VS2 gTXLLajwJBIV6quZYcCvtuTezVWk1jFJdqNTwx/icXkiZjjLgsqODKLwqNhvDIde4G b1TtrZtzEJZzdS5ixlIa8J8AJqT9QPWjEpZBLdVkMcOtaPF+J4y+nCdslIax8SLLHc INSr38gUFTRCxV1qFj0eyukXaMhOOBe3DZKqgPJvXk+0OFZT9gb33aN/k26AROkAVu AX42+mxKg09PQ==
Received: from [10.242.2.5] (unknown [10.242.2.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id C60703C0116; Tue, 28 May 2019 09:56:46 +0200 (CEST)
From: Neil Cook <neil.cook@open-xchange.com>
Message-Id: <2DD6080A-686C-4B00-9171-630DCFBF3270@open-xchange.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_68948824-E31E-4419-8CB1-F1D115ADF755"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Tue, 28 May 2019 08:57:56 +0100
In-Reply-To: <alpine.LRH.2.21.1905272242570.15000@bofh.nohats.ca>
Cc: add@ietf.org
To: Paul Wouters <paul@nohats.ca>
References: <182C9119-59F9-43FA-B116-4D45649B74B5@nbcuni.com> <410f4e4d-aee0-d679-b454-6576de90b21a@nomountain.net> <76EF5603-618C-4A73-A4F9-7489B73B0757@nbcuni.com> <9ad7aa89-d751-e4c6-dede-e9c22faf6d20@nomountain.net> <alpine.LRH.2.21.1905262020010.25783@bofh.nohats.ca> <3f2b3225-ad2e-75c8-0cd7-32679e20ebf7@huitema.net> <alpine.LRH.2.21.1905272242570.15000@bofh.nohats.ca>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/wll338y2XeMxbsKmVywDvL9JdP0>
Subject: Re: [Add] [EXTERNAL] Re: Browser Administrative Authority
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 May 2019 07:56:54 -0000

> On 28 May 2019, at 03:49, Paul Wouters <paul@nohats.ca> wrote:
> 
> Anyway, my point was that the ISP (carrier of hotspot) only uses their
> view of my DNS to my detriment. Sending them encrypted to the ISP gains
> me nothing. (exception for RBL enhanced DNS servers, but as long as they
> are breaking DNSSEC, they cannot be distinguished from a malicious
> attack)
> 

I don’t know the case of your particular ISP, but IMO saying things like "the ISP (carrier of hotspot) only uses their view of my DNS to my detriment” is not very helpful.

All the ISPs I know and work with spend a great deal of time trying to ensure that DNS works well for their customers, including things minimising latency, and spending a lot of money and time on hosting CDN nodes in their network that are close to their customers (since DNS is often/usually used to send customers to their closest content node).

Maybe that’s not true everywhere, but equally so is the “ISPs are evil and do nothing for me” point of view.

Neil Cook
neil.cook@open-xchange.com

-------------------------------------------------------------------------------------
Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein, Stephan Martin 
Chairman of the Board: Richard Seibt

European Office: 
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718 
Managing Director: Frank Hoberg

US Office: 
Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA 
-------------------------------------------------------------------------------------