Re: [DNSOP] Obsoleting DLV

Samuel Weiler <weiler@csail.mit.edu> Wed, 24 July 2019 23:22 UTC

Return-Path: <weiler@csail.mit.edu>
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 692CC12027B for <dnsop@ietfa.amsl.com>; Wed, 24 Jul 2019 16:22:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 sHdzbAltRvYO for <dnsop@ietfa.amsl.com>; Wed, 24 Jul 2019 16:22:02 -0700 (PDT)
Received: from cyrus.watson.org (cyrus.watson.org [204.107.128.30]) by ietfa.amsl.com (Postfix) with ESMTP id 832A912006E for <dnsop@ietf.org>; Wed, 24 Jul 2019 16:22:02 -0700 (PDT)
Received: from dhcp-8906.meeting.ietf.org (dhcp-8906.meeting.ietf.org [31.133.137.6]) by cyrus.watson.org (Postfix) with ESMTPSA id CB23917164; Wed, 24 Jul 2019 23:22:01 +0000 (UTC)
Date: Wed, 24 Jul 2019 19:22:01 -0400
From: Samuel Weiler <weiler@csail.mit.edu>
To: Matthijs Mekking <matthijs@pletterpet.nl>
cc: "dnsop@ietf.org" <dnsop@ietf.org>
In-Reply-To: <56a4b9a1-6e80-be24-0852-fe3b91869f1e@pletterpet.nl>
Message-ID: <alpine.OSX.2.20.1907231804420.14762@dhcp-9328.meeting.ietf.org>
References: <56a4b9a1-6e80-be24-0852-fe3b91869f1e@pletterpet.nl>
User-Agent: Alpine 2.20 (OSX 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gA1HbwFrXyJlEmEpy_jrcWg7v7s>
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: Wed, 24 Jul 2019 23:22:05 -0000

On Tue, 2 Jul 2019, Matthijs Mekking wrote:

> Here's a draft with discussion why also the protocol should go
> away. We would like to hear what you think about it.

The discussion of the private network use case in section 2 has two 
minor errors plus one bit that is unclear.

When we designed DLV, we certainly considered a private network use 
case.  RFC5074 does not strictly have public trust anchors take 
precedence over ("mask") DLV records [1].

I suggest replacing the text in section 2 starting with "One other..." 
with:

    One other possible reason to keep DLV is to distribute trust anchors
    for private enterprises.  The authors are not aware of any such use
    of DLV.

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.

-- Sam


[1] Specifically, 5074 says to use public trust anchors first.  If 
they give a validation result other than "Secure", then do DLV 
processing.  I'm not 100% sure of how BIND's logic works here.