Re: [DNSOP] Obsoleting DLV

Mark Andrews <marka@isc.org> Thu, 25 July 2019 13:05 UTC

Return-Path: <marka@isc.org>
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 AAB8212015F for <dnsop@ietfa.amsl.com>; Thu, 25 Jul 2019 06:05:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 F9AT5RjYkulm for <dnsop@ietfa.amsl.com>; Thu, 25 Jul 2019 06:05:09 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 914D71200B5 for <dnsop@ietf.org>; Thu, 25 Jul 2019 06:05:09 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 51F423AB008; Thu, 25 Jul 2019 13:05:09 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 43F7E160052; Thu, 25 Jul 2019 13:05:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 30EEE16007C; Thu, 25 Jul 2019 13:05:09 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xWGKwtzyAQZf; Thu, 25 Jul 2019 13:05:09 +0000 (UTC)
Received: from [IPv6:2001:67c:370:1998:d9a3:4a5b:bb47:7329] (nat64-5a.meeting.ietf.org [31.130.238.90]) by zmx1.isc.org (Postfix) with ESMTPSA id ACC5B160052; Thu, 25 Jul 2019 13:05:08 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <alpine.DEB.2.20.1907251158030.8471@grey.csi.cam.ac.uk>
Date: Thu, 25 Jul 2019 23:05:05 +1000
Cc: Samuel Weiler <weiler@csail.mit.edu>, Matthijs Mekking <matthijs@pletterpet.nl>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B586ACA7-3902-48EB-8188-84A96375C1F4@isc.org>
References: <56a4b9a1-6e80-be24-0852-fe3b91869f1e@pletterpet.nl> <alpine.OSX.2.20.1907231804420.14762@dhcp-9328.meeting.ietf.org> <alpine.DEB.2.20.1907251158030.8471@grey.csi.cam.ac.uk>
To: Tony Finch <dot@dotat.at>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QqfTIQVQU8tiPrJlbN9cw7OYtGc>
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 13:05:12 -0000


> On 25 Jul 2019, at 9:10 pm, Tony Finch <dot@dotat.at> wrote:
> 
> 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.

You just slave the private DLV registry and load the trust anchors from that
after validating each DLV RRset.

> 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.
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org