Re: [DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?

Paul Vixie <paul@redbarn.org> Thu, 08 February 2018 17:32 UTC

Return-Path: <paul@redbarn.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 9EC16126D73 for <dnsop@ietfa.amsl.com>; Thu, 8 Feb 2018 09:32:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 LO4bhDdkW8_b for <dnsop@ietfa.amsl.com>; Thu, 8 Feb 2018 09:32:40 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E2C12D7E3 for <dnsop@ietf.org>; Thu, 8 Feb 2018 09:32:39 -0800 (PST)
Received: from [IPv6:2001:559:8000:c9:20e3:e8bd:ee44:7bb4] (unknown [IPv6:2001:559:8000:c9:20e3:e8bd:ee44:7bb4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 8720A7594C; Thu, 8 Feb 2018 17:32:39 +0000 (UTC)
Message-ID: <5A7C89B6.2000907@redbarn.org>
Date: Thu, 08 Feb 2018 09:32:38 -0800
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.22 (Windows/20171208)
MIME-Version: 1.0
To: Matt Larson <matt@kahlerlarson.org>
CC: Joe Abley <jabley@hopcount.ca>, sthaug@nethelp.no, Ed Lewis <edward.lewis@icann.org>, dnsop WG <dnsop@ietf.org>
References: <564E7616-6B47-48E2-B3DC-68A22032F441@icann.org> <20180208.152419.74654265.sthaug@nethelp.no> <A03DAC63-E005-4811-B706-B0284273DE6B@hopcount.ca> <32CB34DD-D682-42D7-B869-5A03057FCCC1@kahlerlarson.org>
In-Reply-To: <32CB34DD-D682-42D7-B869-5A03057FCCC1@kahlerlarson.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/AxyydDRuBHRtF4LrUSUv8LxAfhU>
Subject: Re: [DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 08 Feb 2018 17:32:47 -0000


Matt Larson wrote:
> I would love to see BIND's trusted-keys syntax deprecated. Not the
> ability to configure a trust anchor statically, mind you, just the
> syntax. Changing the syntax and refusing to start with trusted-key in
> the configuration file would force those who are dragging old config
> files behind them unchanged to update.

tough love is hard to give away. BIND9 ships inside a lot of packaged 
Linux systems, and i don't imagine that ISC would ask or that RH would 
agree to (another) deliberate invalidation of a working config file.

the old one can be made to generate syslog warnings. but there would be 
some lengthy crossover period during which both old and new config 
worked, so that eventually, ISC and RH could include a python or perl 
script that would convert old format to new.

it's doable, but not in the style you suggest, or in a short time.

-- 
P Vixie