Re: [DNSOP] Resolver behaviour with multiple trust anchors

Michael StJohns <> Tue, 31 October 2017 19:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2D3313AD2D for <>; Tue, 31 Oct 2017 12:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ARHOC1sBCNg9 for <>; Tue, 31 Oct 2017 12:23:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F8EA1389C1 for <>; Tue, 31 Oct 2017 12:23:32 -0700 (PDT)
Received: by with SMTP id 8so112011qtv.1 for <>; Tue, 31 Oct 2017 12:23:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=7ho0RK9OObcflXRV75bAqoQ4ib034j3QzjKch3Bgir4=; b=TktDopUhm+nJC4s8E+R70SnV2IQ5yHqqs/6HvK+c7gPPppDF+JHwOxFO8zOsT8eYg1 uAzPHao/wkukwPxOLC+ddE12CbEQ7L/xdZXQqugzzqLmNc9MtNrswiLJsPk8Z9EHeZYx 0G9xoovZGasPedgcda0z1QjGtj6edFIBZ7XsJjHCQkm6Vrg2PmSsr/34+bro4eSJxYIb MJNx5IaUGHzT0icLKtqjAd+ce00Y7R/SN8oJhXJWvLSncyvzo0pxHWeVXAN6+qzdOaOW RllfdF0uNjqKare8yZcx5Z0dLA3xevFFI8Ftr/xIcysoqCTxLRYQaREubesjAyKEbV0X KFUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=7ho0RK9OObcflXRV75bAqoQ4ib034j3QzjKch3Bgir4=; b=ogjRjIu+sTinXNCrzjxQLDJBmQIb40+movN+L7rvdXL3YRJKhwChYMDe0U744GDr08 wP88x1m9ynGghD4EbVfixVQrfhC99IoGKabgWB5zWDRtkS2bSiNJEDciRfMQ3TXuN5bl VfXRuKMR1CJs0dRxagv7+rMaoyXxSoO7tHO1h0FzDI8WV8V/rTr5ThENbUUm9bVfU31S R/S9w4jqTjFg7F/Jf+KTRXWZs5OnLvXoMLc27QzJoX6qGgIQhyQql2fi+WV7xvG9gDtg rhjbHbOoZN1HqHxsz18HWqmJM7aZhPZwm/6RrhVpdjjBPASiapIJ8OtJyR1yppAjW67m /3dA==
X-Gm-Message-State: AMCzsaVX9u4vaqE+F9cvDhfcwAdVDJRwgsxPgSO00YdPUA81v1Spcff3 fzU4pIbs+lXeUb0e3fTed33AVeec
X-Google-Smtp-Source: ABhQp+TG3A8QUQOL6cnPa4fIeYraI+YoW2RojSpE1evvKQBzaeatylh58+x1jaSaQbKyA1aG0POa+Q==
X-Received: by with SMTP id h24mr4526037qtk.175.1509477811029; Tue, 31 Oct 2017 12:23:31 -0700 (PDT)
Received: from ?IPv6:2601:152:4400:720f::146e? ([2601:152:4400:720f::146e]) by with ESMTPSA id r16sm1415764qtc.4.2017. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Oct 2017 12:23:29 -0700 (PDT)
References: <>
From: Michael StJohns <>
Message-ID: <>
Date: Tue, 31 Oct 2017 15:23:26 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------1A6F0361FD716DB8F7755784"
Content-Language: en-US
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 19:23:34 -0000

On 10/31/2017 5:39 AM, Moritz Muller wrote:
> Hi,
> 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?

A couple of things -

  Make sure that the subordinate trust anchor is still a trust anchor.   
It's possible that  RFC5011, section 5 came into play:

>   Alternately, a trust point that is subordinate to another configured
>     trust point MAY be deleted by a resolver after 180 days, where such a
>   subordinate trust point validly chains to a superior trust point.
>     The decision to delete the subordinate trust anchor is a local
>     configuration decision.  Once the subordinate trust point is deleted,
>     validation of the subordinate zone is dependent on validating the
>     chain of trust to the superior trust point

The idea here was to deal with the transition from unsigned root to 
signed root, but still allow for situations where the subordinate zone 
wanted to ensure it was able to manage its own trust point. This should 
have been a bind/unbound/powerdns configuration item but who knows.

But sadly - the language in RFC6840 section 5.10 is controlling... 
basically, any implementation can do whatever it wants.

> A DNSSEC validator may be configured such that, for a given response,
> more than one trust anchor could be used to validate the chain of
> trust to the response zone. For example, imagine a validator
> configured with trust anchors for "example." and "zone.example."
> When the validator is asked to validate a response to
> "", either trust anchor could apply.

> When presented with this situation, DNSSEC validators have a choice
> of which trust anchor(s) to use. Which to use is a matter of
> implementation choice. Appendix C discusses several possible
> algorithms.

And once again we see the folly of the words "implementation choice" 
when trying to come up with a coherent DNS.

Later, Mike

> — Moritz
> _______________________________________________
> DNSOP mailing list