Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors

Mark Andrews <marka@isc.org> Thu, 02 November 2017 21:24 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 516AB13F65E for <dnsop@ietfa.amsl.com>; Thu, 2 Nov 2017 14:24:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 6rVrAy0kA5FB for <dnsop@ietfa.amsl.com>; Thu, 2 Nov 2017 14:24:45 -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 D429013B11B for <dnsop@ietf.org>; Thu, 2 Nov 2017 14:24:45 -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 8E7DF3AC656; Thu, 2 Nov 2017 21:24:31 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 36EEF16007C; Thu, 2 Nov 2017 21:24:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1DA0416008A; Thu, 2 Nov 2017 21:24:31 +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 OnFbP0dM0ix1; Thu, 2 Nov 2017 21:24:31 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id C8DCE16007C; Thu, 2 Nov 2017 21:24:30 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 2FB1A8EAAC52; Fri, 3 Nov 2017 08:24:28 +1100 (AEDT)
To: Edward Lewis <edward.lewis@icann.org>
Cc: Warren Kumari <warren@kumari.net>, Bob Harold <rharolde@umich.edu>, Matt Larson <matt@kahlerlarson.org>, Ólafur Guðmundsson <olafur@cloudflare.com>, Paul Wouters <paul@nohats.ca>, "dnsop@ietf.org" <dnsop@ietf.org>, Moritz Muller <moritz.muller@sidn.nl>
From: Mark Andrews <marka@isc.org>
References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <CAN6NTqxy4SWxsUNZyBA=1TZxdhWtVxaTDYLoA1qO2nKf202g9w@mail.gmail.com> <E94AE36A-CA69-47DB-A2B7-41D0C3644855@nohats.ca> <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> <alpine.LRH.2.21.1710311541090.23568@bofh.nohats.ca> <54030D6D-0B7D-4408-A50A-FDBD66A940B4@kahlerlarson.org> <CA+nkc8CqoX87L9YPoJfx7dSOZY4Pm5RXKNvKVBkFB_KX+EK4KQ@mail.gmail.com> <CAHw9_iJ5dYaHQOSnhSg2cGq8aa+fNPR8KsdR_xB=zVdtMANgKg@mail.gmail.com> <1E0EA91F-CAB7-4BB9-A528-D2E60C8E4187@icann.org>
In-reply-to: Your message of "Thu, 02 Nov 2017 15:41:51 -0000." <1E0EA91F-CAB7-4BB9-A528-D2E60C8E4187@icann.org>
Date: Fri, 03 Nov 2017 08:24:28 +1100
Message-Id: <20171102212428.2FB1A8EAAC52@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zqL6DN9xDpkjDSEpV3K35doevhw>
Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors
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, 02 Nov 2017 21:24:48 -0000

This is only about which trust anchors applies for a given name with
you have several configured with different names.  Multiple trust
anchors with the same name is still any match will do.

There are enough senarios where you want *only* the closest
trust-anchor to apply that that is what was coded.  This does however
result in occassional breakages when that trust anchor is not keep
up to date and it is only being used to provide a trust anchor for
a site in the event of a link failure.  That said if you have the
trust anchor there for link failures you *need* to keep them up to
date or they do not do their job when the link fails.  Having
validation fail is a good way to show that they are out of date and
that your processes have failed.

I don't see a reason to change from only using the deepest match.
It is the best overall strategy.  If you are getting validation
failures because the trust anchors are out of date, fix the process
that keeps the trust anchors up to date.  Once that is done worring
about DS overriding a configured trust anchor is moot.

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