Re: [DNSOP] Resolver behaviour with multiple trust anchors

Philip Homburg <> Tue, 31 October 2017 18:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D00B013F5AE for <>; Tue, 31 Oct 2017 11:24:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qsqO7F5uEpS4 for <>; Tue, 31 Oct 2017 11:24:19 -0700 (PDT)
Received: from ( [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C558313F502 for <>; Tue, 31 Oct 2017 11:24:18 -0700 (PDT)
Received: from (localhost [::ffff:]) by with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1e9bCx-0000EpC; Tue, 31 Oct 2017 19:24:15 +0100
Message-Id: <>
Cc: "Paul Hoffman" <>
From: Philip Homburg <>
References: <> <>
In-reply-to: Your message of "Tue, 31 Oct 2017 07:42:32 -0700 ." <>
Date: Tue, 31 Oct 2017 19:24:14 +0100
Archived-At: <>
Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Oct 2017 18:24:21 -0000

>It sounds like clarification is needed if even one (much less three) 
>systems treat such a signature as Bogus. My reading of RFC 4035 is that 
>any chain that successfully leads to a trust anchor should return 
>Secure, even if a different chain returns Bogus.

If extra trust anchors are configured for security reasons (as opposed to
availability) then I would expect some sort of longest match on the
trust anchor that is to be used.

For example, if I configure a trust anchor for for security
reasons, then that is probably because I don't fully trust the .com zone
or even the root zone.

If then a record fails to validate using the trust anchor that is configured
for, then it would be very bad if the resolver turns around and
suddenly trusts the information from the .com zone.