Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

Joao Damas <joao@bondis.org> Thu, 17 May 2018 13:26 UTC

Return-Path: <joao@bondis.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 E3E8412E874 for <dnsop@ietfa.amsl.com>; Thu, 17 May 2018 06:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 b-za9j1oeeg8 for <dnsop@ietfa.amsl.com>; Thu, 17 May 2018 06:26:49 -0700 (PDT)
Received: from smtp1.bondis.org (smtp1.bondis.org [194.176.119.250]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E025120713 for <dnsop@ietf.org>; Thu, 17 May 2018 06:26:44 -0700 (PDT)
Received: from dhcp-26-134.ripemtg.ripe.net (dhcp-26-134.ripemtg.ripe.net [193.0.26.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: joao) by smtp1.bondis.org (Postfix) with ESMTPSA id 1DAB9620210; Thu, 17 May 2018 15:28:35 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Joao Damas <joao@bondis.org>
In-Reply-To: <20180517112945.GB91015@vurt.meerval.net>
Date: Thu, 17 May 2018 15:26:40 +0200
Cc: Geoff Huston <gih@apnic.net>, Tim Wicinski <tjw.ietf@gmail.com>, Suzanne Woolf <suzworldwide@gmail.com>, dnsop <dnsop@ietf.org>
X-Mao-Original-Outgoing-Id: 548256400.1968499-1c1f7e3bc9a1f33b9b23b52c524a2c83
Content-Transfer-Encoding: quoted-printable
Message-Id: <7DE138EC-283A-45E9-80AD-42B2E8A337E4@bondis.org>
References: <CADyWQ+EE9YCCM03wKvd-HefpoQVqhOfeeLKLV8L2LJj+tqmEzA@mail.gmail.com> <CACWOCC936z-4j8e+d7bvhfr_Mk8tk64tkuiRDTRtrqrBTJBKJw@mail.gmail.com> <CAHw9_iLgTvPHe5jeL-0QZJ4+cxes8bBpCEULuDKThpjXoKzrbA@mail.gmail.com> <20180406134501.GC49550@vurt.meerval.net> <4A943DE7-81BC-41AC-93F7-4EC0975DF6B6@gmail.com> <5E7C31BE-EA5F-4A68-96FE-975CFAF77E42@apnic.net> <20180507190705.GP91015@vurt.meerval.net> <20180517112945.GB91015@vurt.meerval.net>
To: Job Snijders <job@ntt.net>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1gTs3JYDaVORXfQWul3N4J59Q-o>
Subject: Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
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: Thu, 17 May 2018 13:26:52 -0000


> On 17 May 2018, at 13:29, Job Snijders <job@ntt.net> wrote:
> 
> On Mon, May 07, 2018 at 07:07:05PM +0000, Job Snijders wrote:
>> 3/ Section 3 states: "The responses received from queries to resolve
>> each of these names would allow us to infer a trust key state of the
>> resolution environment.".
>> From what I understand, in today's DNS world we can only reasonably
>> expect to do one query per packet. It is well understood that many
>> operators use BGP-4 anycasting (ECMP), the likes of dnsdist, and/or
>> simple UDP loadbalancers. I think it may be good to document that
>> running 3 queries (in essence 3 independent experiments) may not
>> generate sufficient data to properly infer the state (or any state) of
>> the resolution environment. Each query (as part of a single sentinel
>> data gathering session) may be handled by an entirely different resolver
>> with different keys, contaminating any lookup in the proposed truth
>> tables. Section 4 covers a number of cases where the results are
>> indeterminate. It maybe should be added to Section 4 that the client has
>> no awareness of how the resolver environment is constructed, and thus
>> requiring multiple independent queries to infer state has its downsides.
> 
> Do the authors agree with the above observation?

No, not really, at least in my case. What you are saying is that an incoherent system behaves in inconsistent manners (a service exposes itself to the outside as a homogeneous system but doesn’t behave that way). In that case the problem is not one or more queries, the problem is an internally misconfigured system.
If you are referring to the case when a client has several resolvers that I can try, I think what we can do is stress even more is that this measures the client’s resolver environment, not aspects of particular resolvers. We are after finding out whether a user can get a successful resolution in their configure environment.

Joao