[DNSOP] Resolver behaviour with multiple trust anchors

Moritz Muller <moritz.muller@sidn.nl> Tue, 31 October 2017 09:39 UTC

Return-Path: <moritz.muller@sidn.nl>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1E643138F47 for <dnsop@ietfa.amsl.com>; Tue, 31 Oct 2017 02:39:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 09BM-fm81Qa3 for <dnsop@ietfa.amsl.com>; Tue, 31 Oct 2017 02:39:26 -0700 (PDT)
Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 184E213F5E4 for <dnsop@ietf.org>; Tue, 31 Oct 2017 02:39:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=from:to:subject:thread-topic:thread-index:date:message-id:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-mailer:x-ms-exchange-messagesentrepresentingtype:x-ms-exchange-transport-fromentityheader:x-originating-ip:content-type:mime-version; bh=LGP709nUbA9le9/bJnEA2ucwg37wnNtRrGkLmjmTF1A=; b=LhCocLGpctN9G3i1iW07hov/m4zEwHripb1JM03Y8rZ4n0RGQCaC09ZT6eoVcyuDlesStsGa6gIY6eXVnkgnBVkvgTF2hsrs9Jz8kzoJ6H3gIVRgRBQaKZayBR3QEgQy3kbQkWO32lZvRI9icjoefCEVEHeAsBWyvXdsogWPAq3Aq1xAsgYP05ZQTXJveh6L1ld+O4WlqQBOQTeCFDkOkR6UiwoTrtX2FmZdN2ZoIc9thLO1OqLZX+rEUioqActJFwTqPaZb5TQMe2t3kZ+MByA8m+3bfD1utj+W9Z77x+weKOzL7kvsH+aiI5wS77xWALIfLeQ6E+hTISPCFYkJtA==
Received: from ka-mbx02.SIDN.local ([]) by arn2-kamx.sidn.nl with ESMTP id v9V9dOJD016189-v9V9dOJF016189 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for <dnsop@ietf.org>; Tue, 31 Oct 2017 10:39:24 +0100
Received: from ka-mbx01.SIDN.local ( by ka-mbx02.SIDN.local ( with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 31 Oct 2017 10:39:23 +0100
Received: from ka-mbx01.SIDN.local ([fe80::e051:e184:7a9f:b09d]) by ka-mbx01.SIDN.local ([fe80::e051:e184:7a9f:b09d%13]) with mapi id 15.00.1130.005; Tue, 31 Oct 2017 10:39:24 +0100
From: Moritz Muller <moritz.muller@sidn.nl>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: Resolver behaviour with multiple trust anchors
Thread-Index: AQHTUiwiqVxvIHBV0Uun1GqDhxVA2w==
Date: Tue, 31 Oct 2017 09:39:23 +0000
Message-ID: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-mailer: Apple Mail (2.3273)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_E3B668C3-F4D6-497A-9A63-BDB90D919C31"; protocol="application/pgp-signature"; micalg="pgp-sha512"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pgmqJw7Gp7mk-hhs0W8Vc0rfRdQ>
Subject: [DNSOP] 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: Tue, 31 Oct 2017 09:39:28 -0000


Together with my colleagues I have been stumbling upon a, for me, unclear case when validating trust anchors.

Assuming that a resolver has enabled DNSSEC validation and has the root keys configured.
Additionally, it has configured manually a trust anchor for a TLD (that has also published its DS in the root zone).
Now, for example due to a key rollover at the TLD, the manually configured trust anchor of the TLD does not match the DS in the root anymore.

How should a resolver treat the signatures of this TLD?
The resolvers of BIND, Unbound, and PowerDNS seem to treat the signatures of the TLD as bogus, but we didn't find any specifics in RFC 4034 and 4035 that describe how resolvers should behave in this case.
Knot resolver treats them as NOERROR (according to the developers).
If we interpret section 4.3 of RFC 4035 then we would have assumed that the signature must be treated as secure.

Did we miss something, or is there indeed clarification needed?

— Moritz