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