Re: [DNSOP] Resolver behaviour with multiple trust anchors

Michael StJohns <> Tue, 31 October 2017 21:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FF3013F70B for <>; Tue, 31 Oct 2017 14:04:12 -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 Kovzuo2gYflD for <>; Tue, 31 Oct 2017 14:04:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B1E013F6F0 for <>; Tue, 31 Oct 2017 14:03:59 -0700 (PDT)
Received: by with SMTP id p1so453553qtg.2 for <>; Tue, 31 Oct 2017 14:03:59 -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=GcdfD0+bHRAm2eJnHr665H+PUN92XmEnW6RK81osEgM=; b=pZqO95KEfxUwMNF+w81QxMMKPtcCQATJ31JwWOj/E0qiBhkQqHScoVyTM2LNhEe/yp 6Yi8nLFe7ftJSX3uDPFjGN/+b1zwnEUzS57bAtP884te/YCz3SJCtaCmkRaaPTBGrqkR dpHRNuVIQLbnkV1WxGTnkvqPOQxoQqLGNDlgtfVJ43nPgB1kXE/X8CgkW6PYvP37FcLu W+Mt+b7px2bsmRcFmQUor+yhLZiAA/MID3c4mFJB+tZkUag1iIzVL3iNwcCaRPTHeDuY 0pSKRvwwz8mCE0ogzjiCeMFKH/s+VPjrEg/exaKm7iVUfsvrUkvV3HKw08B+YahOaYl1 vzig==
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=GcdfD0+bHRAm2eJnHr665H+PUN92XmEnW6RK81osEgM=; b=dIdXDhaZ1W3HAZjbPvNUZkyiA8L7t9mIu26OmqCGWMH47wsDXpPW+3oVoBHb9ZctlQ XBmJOI6QdWBzzpWr9TlpLcUPftCcEmPCwFRg1yIrcUpf4vLEQtWB6UAtnwXC1RuhaSEG 0k3M7xghr2LOyUeVWGhWh8t23wAhFNxVERQ1wu+NgTFVSdGQhiOzFYAQUHcYqshun2ZX T1lrc6ieBvsGOwn7t6Wo7nzTFakLvrd59TZX3uyStxSdxPyWyQphXpKtb9x5V+y/VJZI lWRzDfxfp5RP9tQHI4lcsHdd2Vvf9sChXXBznkzZ3Hq1/OSYZzwDN/6nBSj9Nr95JDdO Cl0g==
X-Gm-Message-State: AMCzsaVmnEndvLNs56vjfTvOruIfgeN3jDgYJgXcNuo0gBcMWTLNnxns l61kbawKwAwtvPtj/M8mKUfNIB4J
X-Google-Smtp-Source: ABhQp+QjZfGyR661xKOnjhhdGermvC9MYSefeC1RHcgbX+q7zTVgxl6B5+AZRWKn1lA33Y3/Slgs7Q==
X-Received: by with SMTP id e58mr5106221qtc.234.1509483837968; Tue, 31 Oct 2017 14:03:57 -0700 (PDT)
Received: from ?IPv6:2601:152:4400:720f::146e? ([2601:152:4400:720f::146e]) by with ESMTPSA id l1sm1559360qtf.5.2017. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Oct 2017 14:03:57 -0700 (PDT)
References: <> <> <>
From: Michael StJohns <>
Message-ID: <>
Date: Tue, 31 Oct 2017 17:03:54 -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="------------638A584F5362DFF6DC96BEFB"
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 21:04:12 -0000

On 10/31/2017 4:51 PM, Paul Hoffman wrote:
>> And once again we see the folly of the words "implementation choice" 
>> when trying to come up with a coherent DNS.
> The full quote makes the situation murkier: it is a combination of 
> implementation choice plus configuration options. Some folks on this 
> list strongly prefer that, others strongly don't.

My main and only desire when querying the DNS is that given the same 
inputs to the system you should always get the same output. Getting 
different answers on something that's as important as security because 
you queried different implementations  continues to seem to be to be a 
bad idea.

Having a standard default (which was not what this was) and having 
configuration options to change it for good reason is different than 
"which to use is a matter of implementation choice".

Later, Mike