Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
神明達哉 <jinmei@wide.ad.jp> Fri, 25 May 2018 17:15 UTC
Return-Path: <jinmei.tatuya@gmail.com>
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 58DA712DB70 for <dnsop@ietfa.amsl.com>; Fri, 25 May 2018 10:15:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.024
X-Spam-Level:
X-Spam-Status: No, score=-1.024 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.599, SPF_PASS=-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 eP9nr2JSqC3i for <dnsop@ietfa.amsl.com>; Fri, 25 May 2018 10:15:57 -0700 (PDT)
Received: from mail-wr0-f177.google.com (mail-wr0-f177.google.com [209.85.128.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10CCE12711B for <dnsop@ietf.org>; Fri, 25 May 2018 10:15:57 -0700 (PDT)
Received: by mail-wr0-f177.google.com with SMTP id k5-v6so10419276wrn.3 for <dnsop@ietf.org>; Fri, 25 May 2018 10:15:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qhdfiDrmSNv/hy8LgDD7ExW2ejYUjzMIVfS5MdPlrqw=; b=W/PlzUilSkQ4pF+bV3gxG/h73cBIYO3cNcHZLi3s5Gnwd4MjrzzfdefUUj+9v6i39f 9m5UhAHqvmh81YqN47dG8L/fVq21rJ8y0RQf5NR+0MZZ0p68BeJxCN54U9vQrubr7KGY vpitW+/+DXhBfBCUaFZ7EysuPBeA8oQgch2WlkGRHPEv/vpCtKPcBjgeH9e2FHhRtjez zHKFqXG616JFYgKSwzo8Bt6KoZu80EQywCem6LOJjO4agWjhk54oy4BiEUipowRbTbXw L5GqO4ClP4yKblYbMbxUnv3Mb2mheS7SLBWlhC4ZQMJit9vaVN5oZEpiMhvMzZ5sy02T Yd6Q==
X-Gm-Message-State: ALKqPwdg6hBkgoUi90J3lH6klEJdOU5JZdC6He+ncVpm2YASCyENBZPw u0idoqAFzr7K1hajSc82Rw9j1Nf7SgqjUoTtp54=
X-Google-Smtp-Source: ADUXVKJpxrdu4PMXlahAjpwI0CK9WFqRMn3FGdkWFVb3bcreEUy15lrC+BxPd+yFafQFuTzdxk4vtLu8GCBdlwRreRs=
X-Received: by 2002:a19:d253:: with SMTP id j80-v6mr2006503lfg.88.1527268555376; Fri, 25 May 2018 10:15:55 -0700 (PDT)
MIME-Version: 1.0
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> <7DE138EC-283A-45E9-80AD-42B2E8A337E4@bondis.org> <CAHw9_iK4ETO-VKZGsgHLoAyvrx8Nv=GBFamuVv69t=2oTxAjew@mail.gmail.com>
In-Reply-To: <CAHw9_iK4ETO-VKZGsgHLoAyvrx8Nv=GBFamuVv69t=2oTxAjew@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Fri, 25 May 2018 10:15:43 -0700
Message-ID: <CAJE_bqdwKugS24rmHZZ9qkj5hafSG=KjhPhEiLqbqpnUiKH+aQ@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
Cc: João Damas <joao@bondis.org>, Tim Wicinski <tjw.ietf@gmail.com>, Suzanne Woolf <suzworldwide@gmail.com>, dnsop <dnsop@ietf.org>, Job Snijders <job@ntt.net>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/twPpp5kWGlZkjcno2ZPbcBzOr5E>
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: Fri, 25 May 2018 17:16:00 -0000
At Wed, 23 May 2018 14:39:40 -0400, Warren Kumari <warren@kumari.net> wrote: > Just so the WG knows, the authors (myself in particular) had some > productive discussions with Job at the RIPE meeting in Marseille. > As a reminder, this mechanism is designed to measure the *user* impact of > the KSK roll - this means that querying the first resolver in e.g: > resolve.conf, getting SERVFAIL and then failing over to the second (or > third or n-th) until a response is received is fine, and expected. > The document currently contains: [...] > "Note that a slew of other issues can also cause SERVFAIL responses, **and > so the sentinel processing may sometimes result in incorrect > conclusions.**" (emphasis added). > An example of a case where an incorrect conclusion could occur is if the > client is using an Anycast recursive resolver (e.g: 8.8.8.8) and some of > the backends of that Anycast network have only the old key, and some have > the new key, and ECMP directs you to different backend. Another exmaple is > if the resolver learns the new key *during* a clients testing. To me these > feel like pathological cases, and are covered by "may sometimes result in > incorrect conclusions". > Does the WG feel that this is sufficient, or would it like additional text? > If so, can you propose some? I don't have a strong opinion on the main question (I'm fine with the current version of this draft regarding this matter). But I'd like to point out that the above quoted text regarding SERVFAIL and "incorrect conclusions" (which I think I proposed before) mainly concerned cases where SERVFAIL is returned for a different reason than the one described in kskroll-sentinel such as query timeout (note the "other issues" in the text). Likewise, "incorrect conclusions" mainly intended such cases as deducing Vnew/Vold/Vleg labels while the corresponding SERVFAIL was returned for a different reason. I think it's slightly different from a type of "incorrect conclusions" discussed in this thread, since an incorrect conclusion is reached not because SERVFAIL is returned for a different reason but because it's inconsistent which server sends which. Again, I'm fine with the current text anyway. But if we want to tweak the text in response to the concern in this thread while preserving the original text quoted above, then we might say something like: OLD [...] Note that a slew of other issues can also cause SERVFAIL responses, and so the sentinel processing may sometimes result in incorrect conclusions. NEW [...] Note that a slew of other issues can also cause SERVFAIL responses and DNS transactions are not always reliable or consistent, and so the sentinel processing may sometimes result in incorrect conclusions. -- JINMEI, Tatuya
- Re: [DNSOP] Working Group Last Call for: draft-ie… Benno Overeinder
- Re: [DNSOP] Working Group Last Call for: draft-ie… Paul Hoffman
- Re: [DNSOP] Working Group Last Call for: draft-ie… Job Snijders
- Re: [DNSOP] Working Group Last Call for: draft-ie… Warren Kumari
- [DNSOP] Working Group Last Call for: draft-ietf-d… tjw ietf
- Re: [DNSOP] Working Group Last Call for: draft-ie… Job Snijders
- Re: [DNSOP] Working Group Last Call for: draft-ie… tjw ietf
- Re: [DNSOP] Working Group Last Call for: draft-ie… Peter van Dijk
- Re: [DNSOP] Working Group Last Call for: draft-ie… Petr Špaček
- Re: [DNSOP] Working Group Last Call for: draft-ie… Job Snijders
- Re: [DNSOP] Working Group Last Call for: draft-ie… Warren Kumari
- Re: [DNSOP] Working Group Last Call for: draft-ie… Job Snijders
- Re: [DNSOP] Working Group Last Call for: draft-ie… Joe Abley
- Re: [DNSOP] Working Group Last Call for: draft-ie… 神明達哉
- Re: [DNSOP] Working Group Last Call for: draft-ie… Joe Abley
- Re: [DNSOP] Working Group Last Call for: draft-ie… Suzanne Woolf
- Re: [DNSOP] Working Group Last Call for: draft-ie… Warren Kumari
- Re: [DNSOP] Working Group Last Call for: draft-ie… Evan Hunt
- Re: [DNSOP] Working Group Last Call for: draft-ie… Benno Overeinder
- Re: [DNSOP] Working Group Last Call for: draft-ie… Bob Harold
- Re: [DNSOP] Working Group Last Call for: draft-ie… George Michaelson
- Re: [DNSOP] Working Group Last Call for: draft-ie… Peter van Dijk
- Re: [DNSOP] Working Group Last Call for: draft-ie… Ondřej Surý
- [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12 Geoff Huston
- Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12 Ralph Dolmans
- Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12 Paul Vixie
- Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12 Paul Hoffman
- Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12 Geoff Huston
- Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12 Paul Vixie
- Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12 Ondřej Surý
- Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12 Job Snijders
- Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12 Mark Andrews
- Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12 Job Snijders
- [DNSOP] on 'when to implement' (was: Re: Working … Peter van Dijk
- Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12 Joao Damas
- Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12 Job Snijders
- Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12 Benno Overeinder
- Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12 Benno Overeinder
- Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12 Joe Abley
- Re: [DNSOP] on 'when to implement' (was: Re: Work… Benno Overeinder
- Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12 Job Snijders
- Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12 Joao Damas
- Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12 Warren Kumari
- Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12 神明達哉