IETF Logo Mail Archive

Re: [DNSOP] Obsoleting DLV

Tony Finch <dot@dotat.at> Thu, 25 July 2019 11:10 UTC

Return-Path: <dot@dotat.at>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362DB120158 for <dnsop@ietfa.amsl.com>; Thu, 25 Jul 2019 04:10:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 sYEMzR1j0K0B for <dnsop@ietfa.amsl.com>; Thu, 25 Jul 2019 04:10:49 -0700 (PDT)
Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) (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 AC17E12002F for <dnsop@ietf.org>; Thu, 25 Jul 2019 04:10:49 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:46756) by ppsw-41.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1hqbe0-000k3T-RE (Exim 4.92) (return-path <dot@dotat.at>); Thu, 25 Jul 2019 12:10:44 +0100
Date: Thu, 25 Jul 2019 12:10:44 +0100
From: Tony Finch <dot@dotat.at>
To: Samuel Weiler <weiler@csail.mit.edu>
cc: Matthijs Mekking <matthijs@pletterpet.nl>, "dnsop@ietf.org" <dnsop@ietf.org>
In-Reply-To: <alpine.OSX.2.20.1907231804420.14762@dhcp-9328.meeting.ietf.org>
Message-ID: <alpine.DEB.2.20.1907251158030.8471@grey.csi.cam.ac.uk>
References: <56a4b9a1-6e80-be24-0852-fe3b91869f1e@pletterpet.nl> <alpine.OSX.2.20.1907231804420.14762@dhcp-9328.meeting.ietf.org>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/J_g4qSkj7hzlBJX5YLVLv3vIdZA>
Subject: Re: [DNSOP] Obsoleting DLV
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 25 Jul 2019 11:10:51 -0000

Samuel Weiler <weiler@csail.mit.edu> wrote:
>
> That does not include the argument in the below bullet, which I find unclear.
> What does "name redirection" mean in this context?
>
>    o  Since the zones are related to private networks, it would make
>       more sense to make the internal network more secure to avoid name
>       redirection, rather than complicate the DNS protocol.

I guess it's referring to active DNS modification attacks?

Another reason not mentioned in the draft is resilience against loss of
connectivity. If you have a local trust anchor you can validate local
zones even when you can't reach the outside world. With normal DNSSEC
validation everything is screwed if you can't obtain the chain of trust.

Of course, the network should be secure and reliable in its lower layers,
but I tend to think the DNS should be secure and reliable itself, even if
the lower layers are a bit dodgy.

Having thought about this a bit, I now prefer something like catalog zones
as a way to distribute trust anchors.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Lundy, Fastnet: Variable 2 to 4 in east Lundy, otherwise southerly veering
southwesterly 4 to 6. Slight or moderate in east Lundy, but elsewhere moderate
or rough. Thundery showers. Moderate or good.

v2.23.0 | Report a Bug | By Email