Re: [DNSOP] kskroll-sentinel responses

"Paul Hoffman" <paul.hoffman@vpnc.org> Sat, 23 December 2017 22:30 UTC

Return-Path: <paul.hoffman@vpnc.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 136FD1267BB for <dnsop@ietfa.amsl.com>; Sat, 23 Dec 2017 14:30:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 mF9bxLZcSaDb for <dnsop@ietfa.amsl.com>; Sat, 23 Dec 2017 14:30:52 -0800 (PST)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 8C1521200C1 for <dnsop@ietf.org>; Sat, 23 Dec 2017 14:30:52 -0800 (PST)
Received: from [10.32.60.51] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id vBNMUeVL095086 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 23 Dec 2017 15:30:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.51]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Geoff Huston <gih@apnic.net>
Cc: dnsop <dnsop@ietf.org>
Date: Sat, 23 Dec 2017 14:30:43 -0800
X-Mailer: MailMate (1.10r5443)
Message-ID: <6615AB2F-F579-4F9C-9869-271EAB544181@vpnc.org>
In-Reply-To: <C79FED8F-91A7-41C9-A1D6-7DC290B8B938@apnic.net>
References: <20171221103623.045eed5e@titan.int.futz.org> <df3a8c29-38ea-6dd0-db4d-f8562653dd69@bellis.me.uk> <C79FED8F-91A7-41C9-A1D6-7DC290B8B938@apnic.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9ejw8xKBRy_Grems38LwNIyGQFo>
Subject: Re: [DNSOP] kskroll-sentinel responses
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: Sat, 23 Dec 2017 22:30:54 -0000

On 23 Dec 2017, at 11:59, Geoff Huston wrote:

> In situations where a client may have multiple resolvers in their 
> local
> /etc/resolv.conf configuration, and recursive resolvers may themselves
> /use forwarders, it is not immediately obvious which resolver
> generated the response, so I’m unsure of the interpretation of any
> attempt to embed some form of additional information into either the 
> IP
> address of the named object.

Exactly right. Having a browser run this test can easily lead to false 
positive and false negative results for a user who expects that seeing 
something in their browser means something.

> The intent of the test is to establish a usable test along the lines 
> of
> "If you can retrieve this named object you are ready for a Root Zone 
> KSK
> roll" The issues around the diversity of behaviours in the DNS turn 
> this
> dsimple songle fetch into a compound fetch of three named objects, but
> the semantic intent is the same. That is: "From the pattern of the
> results of performing these three tests we can compute a likelihood of
> concluding whether or not, you, the end user, will, or will not, be
> affected by a pending KSK roll.

... for the current set of resolvers that you are using. A quite 
believable scenario is that while you're sitting in a coffee shop, you 
get one set of results, but a different set when you change to your home 
ISP or your organization's network.

> From a large enough sample of users was
> can then estimate the 'impact' of a KSK roll on the total user
> population.

To get a good estimate, you'll need to sample the same user multiple 
times, looking for changes in the results. The design methodology for 
such a study will be daunting.

> Note that the intent is not to try and isolate the behaviour of a 
> single
> resolver, nor to attempt to diagnose the reasons for that behaviour.

Agree. Note, however, that the sentinel can indeed be used to isolate 
the behavior of a single resolver if you run the test against a known 
address, not against "whatever /etc/resolv.conf gives me".

> The
> intent is to look at the user and the set of resolvers that the user's
> DNS is configured to use, and determine if the user's DNS will be
> "stranded" in the even of a KSK roll.

How can this protocol tell the set of resolvers that the user's DNS is 
configured to use? Either you are seeing the results as an amorphous 
blob (as described in Section 4), or as a specific result because you 
are sending the queries to a single known resolver address.

--Paul Hoffman