Re: [DNSOP] sentinel and timing?

Paul Wouters <paul@nohats.ca> Thu, 08 February 2018 18:52 UTC

Return-Path: <paul@nohats.ca>
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 C6D3712D810 for <dnsop@ietfa.amsl.com>; Thu, 8 Feb 2018 10:52:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kZpoyppBJrk for <dnsop@ietfa.amsl.com>; Thu, 8 Feb 2018 10:52:15 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 4720F12D838 for <dnsop@ietf.org>; Thu, 8 Feb 2018 10:52:13 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zcnP55y8rzF0X for <dnsop@ietf.org>; Thu, 8 Feb 2018 19:52:09 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1518115929; bh=0tlr+Ib1O7SkwWNrF6yzdAcgoMAi9HG6J9s3jTnxvpc=; h=Date:From:To:Subject:In-Reply-To:References; b=l/z1/squ3M4nL3T8B7P1sjAVzGVe5VjM6jKHDPHv3k/OZMbXreGraszeaQJOLvW/z lnbRHnkcXjPR18hPRyOuka9NeVOewlONMgrjPDNiMfh3uYUa9I3QSJLy0S3M3vzN0S Y62RnqkI1JBQkgyAsRCI7jQkRMDDt7KyTlplWyiQ=
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 pQ8hLYCGw0hQ for <dnsop@ietf.org>; Thu, 8 Feb 2018 19:52:07 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (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>; Thu, 8 Feb 2018 19:52:06 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id BF36930B3F5; Thu, 8 Feb 2018 13:52:05 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca BF36930B3F5
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BBFCE402333A for <dnsop@ietf.org>; Thu, 8 Feb 2018 13:52:05 -0500 (EST)
Date: Thu, 8 Feb 2018 13:52:05 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: dnsop <dnsop@ietf.org>
In-Reply-To: <7816D681-7A97-466C-A77F-7A0CC87C4F8F@hopcount.ca>
Message-ID: <alpine.LRH.2.21.1802081342460.24808@bofh.nohats.ca>
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> <7816D681-7A97-466C-A77F-7A0CC87C4F8F@hopcount.ca>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KlU6mHmjmd8mAu2DG7LgDPrVILs>
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: Thu, 08 Feb 2018 18:52:18 -0000

On Thu, 8 Feb 2018, Joe Abley wrote:

> I don't disagree with the need for more data, but I think the hole you mention is not so giant. As far as I can tell it's a result of:

How do you know without the data?

> 1. RFC5011 support not being turned on in nameservers that have been upgraded but whose older, DNSSEC-validating configuration has been preserved across updates (most cases), and
>
> 2. RFC5011 support exercising a code path that requires a writable, persistent filesystem to store an updated trust anchor, which turns out not to be available (fewer, but some cases).

3. gold images instantiated in private clouds

4. AMI images used in AWS

5. docker containers

6. kubernetes containers

7. old configs not getting updated unrelated to 1. and 2.

> unbound-anchor and its use in package and system start scripts is, I think, a key reason why the two problems described above don't show up in unbound.

Even for bind, the OS vendors update the packages with the new keys, so
I think your statement is somewhat simplified.

It could also be that we keep seeing new updated software doing initial
old keys then going to new keys. Or it could be that we see the same
readonly containers/chroot instances starting up.

the uptime of OS tells you if these are highly customized containers.
the uptime of the process tells you if this is an instance that might
update itself still (maybe no hold timer via cron, only via daemon?)

> I think that the sentinel approach of measuring end-user impact from the end-user perspective gets us much closer to useful data in general. However, it's not clear to me how even a trusted, accurate sense of uptime across all resolvers would help with those questions.

I didn't say anything about not using sentinel. I was only wondering if
we can use those to get more data with respect to resolver state.

Paul