[DNSOP] sentinel and timing?

Paul Wouters <paul@nohats.ca> Wed, 07 February 2018 15:43 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A71A812DA6D for <dnsop@ietfa.amsl.com>; Wed, 7 Feb 2018 07:43:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id HcvqKWJ50x48 for <dnsop@ietfa.amsl.com>; Wed, 7 Feb 2018 07:43:22 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca []) (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 3F1FB12704A for <dnsop@ietf.org>; Wed, 7 Feb 2018 07:43:22 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zc5Fg5Qh5z73H for <dnsop@ietf.org>; Wed, 7 Feb 2018 16:43:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1518018199; bh=zLf1bGlKB4uaewzE5yY7NXazzwneve9uMiWPwJTAJNA=; h=Date:From:To:Subject; b=dCNxY/XeXXcyCb29d4uzO7ta9tQ+uNLMj7HrsONv8j5L2CC87thOOTcVwH7xs+eem N3N1O90lqXMJjdmjFiHgOoe94ofDJrewvZvwLP6Pfd0NKsuA+drAxBWm8uwBlE3h8B yEXP0nDd8iM4fgU6QdiKAawQyG5iKeMOIj6WEcgs=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id JrJvecKyz-Lh for <dnsop@ietf.org>; Wed, 7 Feb 2018 16:43:18 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <dnsop@ietf.org>; Wed, 7 Feb 2018 16:43:17 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id CD39F92C; Wed, 7 Feb 2018 10:43:16 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca CD39F92C
Received: from localhost (localhost []) by bofh.nohats.ca (Postfix) with ESMTP id C3FC84023304 for <dnsop@ietf.org>; Wed, 7 Feb 2018 10:43:16 -0500 (EST)
Date: Wed, 7 Feb 2018 10:43:16 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: dnsop <dnsop@ietf.org>
Message-ID: <alpine.LRH.2.21.1802071035280.6369@bofh.nohats.ca>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Y_A0qw5EsFV11EvotaYOEtgls1o>
Subject: [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: Wed, 07 Feb 2018 15:43:29 -0000

I think it is useful to know how long the DNS resolver process has been
up, and/or how long the server running the DNS resolver has been up,
when it is sending the sentinel queries.

That would allow us to detect if we are looking at spun up server
instances and/or provisioned containers with old software stuck to
KSK2010, versus old software running forever on an unmaintained server.

There is one sentinel query that is supposed to be for something that
does not exist:

 	c.  a third query name that is signed with a DNSSEC signature that
 	       cannot be validated (i.e. the corresponding RRset is not signed
 	       with a valid RRSIG record).

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.

draft-ietf-dnsop-kskroll-sentinel-00 could also do a better job of
descibing the client queries and the server replies better. Right now
it seems to be rather handwavy with terms like "envisaged to use",
instead of just properly defining the exact query.