Re: [DNSOP] sentinel and timing?

Warren Kumari <warren@kumari.net> Mon, 12 February 2018 00:29 UTC

Return-Path: <warren@kumari.net>
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 91D8C1270AE for <dnsop@ietfa.amsl.com>; Sun, 11 Feb 2018 16:29:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 cxBZQCN7yHq8 for <dnsop@ietfa.amsl.com>; Sun, 11 Feb 2018 16:29:32 -0800 (PST)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 48CA2126D3F for <dnsop@ietf.org>; Sun, 11 Feb 2018 16:29:31 -0800 (PST)
Received: by mail-wm0-x22f.google.com with SMTP id i186so6673559wmi.4 for <dnsop@ietf.org>; Sun, 11 Feb 2018 16:29:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3MdccYzy8aBzI+al0U5bLy1qckJFU27d2Jt0B+hpCCc=; b=kDMjhPg2D2lnWeSO08XtqjPbOLkrax5quneD7N+ndJAwRsZAS1nDKdCkzzJE7mBADY uZr7Aye64l9+5HhJ3aAWjBoA6xF/VyxU5J26M1bN7YXAT+T/OFJgIPntBUdZzSDB1O7M Q6s48gLv/B4zcNSGOExbCXNId7jKCHefpVz2mLMFsPt7gNtDbW8TVFiR9ojGzAiZq4IQ GMpZIS0jyg7HqNjJ1XySPUPWA+/dESNAO02MHm+CnhkmhdXo0iwfOW4RXI/3pYhFG9CK PqIaBfBpSsq8OC5CvxYZnDsMr48e5Yrlot6OiRmHv2rDc7HrEz+ikI2WAM/VVEGKVAqY NuyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3MdccYzy8aBzI+al0U5bLy1qckJFU27d2Jt0B+hpCCc=; b=KBPTP/U9VzsmeoL0cgtE7elY66Fhzhpzg7zcI+q0JzxjqH9BVRT2+BkmivbdT3INgz N2Ms8IgS05lwlMrLx8Yarw+/gBY7tgyHJX6ozdWEQK54/nrTBViDq9bd6uiojEk2gNWr brIw9WSkb8yQxWKZBHl5R7sPL3vDGQ7q5LDRVMofXJ3rFJgA8lchFIx7rWsrGp4WSWUQ CHXyN/79wFuTvSoZt6aLlo7wbQhvpwb9xAmsuo23+uWL6juFtbz+Hj93S7bUA9k9I4Re /9zgXhQbsIyTEwlyDryfUD4wv5uIutBkwNJNUpfgbDeeB+GH7uKOPvoqHRUlNtF5Zr3g UkYg==
X-Gm-Message-State: APf1xPCHYQJiCreyz0GSUq4dbt879hFKboIrlniuNs6uQpmJ9jVrABPW j1XflM9JqSt50WJKn41YAHldzVKB3LDVJYHgJN7+Lw==
X-Google-Smtp-Source: AH8x226FYvtYXT2B9lzcGhE+TuRU5SXQnHnzm3kRzj7/Y8h6BtsIjhWAnZQBIOTmmHd6zBG0GUKtdLsWZXL5RYzH/Bc=
X-Received: by 10.28.209.137 with SMTP id i131mr2006319wmg.1.1518395369395; Sun, 11 Feb 2018 16:29:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.152.242 with HTTP; Sun, 11 Feb 2018 16:29:28 -0800 (PST)
In-Reply-To: <7A63BB96-4EF7-4DFE-8BEA-4656C3040CC5@apnic.net>
References: <alpine.LRH.2.21.1802071035280.6369@bofh.nohats.ca> <20180207215502.46daf6bc@titan.int.futz.org> <alpine.LRH.2.21.1802080059480.6658@bofh.nohats.ca> <7A63BB96-4EF7-4DFE-8BEA-4656C3040CC5@apnic.net>
From: Warren Kumari <warren@kumari.net>
Date: Mon, 12 Feb 2018 00:29:28 +0000
Message-ID: <CAHw9_iLvLMJ1VcizCfggZFSQJ_H98nyEsgab49Jj-p7wZ9tVCw@mail.gmail.com>
To: Geoff Huston <gih@apnic.net>
Cc: Paul Wouters <paul@nohats.ca>, Robert Story <rstory@isi.edu>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="f403045f578a9f2d3b0564f8f860"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3ymSSTZEgFWvbXvPCTigqVopvd4>
Subject: Re: [DNSOP] sentinel and timing?
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: Mon, 12 Feb 2018 00:29:34 -0000

On Friday, February 9, 2018, Geoff Huston <gih@apnic.net> wrote:

>
>
> > On 8 Feb 2018, at 5:02 pm, Paul Wouters <paul@nohats.ca> wrote:
> >
> > On Wed, 7 Feb 2018, Robert Story wrote:
> >
> >> On Wed 2018-02-07 10:43:16-0500 Paul wrote:
> >>> How about using this query to also encode an
> >>> uptime-processstartedtime value? Maybe with accurancy reduced to
> >>> minutes. I think that would return valuable data.
> >>
> >> -1 for feature creep and the technical reasons Joe mentioned.
> >
> > We have a giant hole in our understanding of why there are updated
> > nameservers running the latest software with the older keys. We
> > need to gain understanding and we know we need more data.
> >
> > Getting more data is the core mission, not feature creep. If there is
> > a technical better way to do this, it's worth considering.
> >
>
> The sentinel mechanism is proposed to be capable of posing a question to a
> user’s
> “DNS Resolution cloud” - it is not intended capable of posing a question to
> an individual DNS resolver.
>
> <no hats>

The sentinel mechanism also *only* switches certain valid answers (received
from authorative servers) into a *SERVFAIL*:
             "SERVFAIL    2       The name server encountered an internal
                                  failure while processing this request,
                                  for example an operating system error
                                  or a forwarding timeout."

KSK Sentinel seems like it stretches "internal failure" a fair bit, but no
where near breaking point. Having the resursive server return any sort of
other response (especially for a zone it isn't also authorative for) is
making up answers from whole cloth, and that feels like a huge change.

While I think it would be great to be able to send questions to resolvers
and get all sorts of interesting stats (uptime, qps, list of keys, list of
zones, phase of moon), I don't think that this is the protocol to do it.
This is really now a knoch on your idea - I'd encourage you to write a
draft with a "status query" type solution, but that's a (IMO) separate
thing.

W
P.S: This written on a plane. Apoloigies if it is OBE, etc.
</>

What I am trying to say is that here is a big difference between a question
> of:
>
> "will this user be impacted at the point of the roLl of the KSK”
>
> and
>
> “what are the trust keys for this resolver?”, or
> “What is the process uptime of the DNS process on this resolver?”
>
> My intuition is that the mechanisms to implement a measurement
> framework for these questions would necessarily be very different.
>
> Geoff
>
>
>
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf