[Ntp] Antw: [EXT] Circular dependencies

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Thu, 12 November 2020 07:31 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D82F3A14C4 for <ntp@ietfa.amsl.com>; Wed, 11 Nov 2020 23:31:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 iFUuYx1QG3jp for <ntp@ietfa.amsl.com>; Wed, 11 Nov 2020 23:31:28 -0800 (PST)
Received: from mx1.uni-regensburg.de (mx1.uni-regensburg.de [194.94.157.146]) (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 576483A14C2 for <ntp@ietf.org>; Wed, 11 Nov 2020 23:31:27 -0800 (PST)
Received: from mx1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B5A8C600004E for <ntp@ietf.org>; Thu, 12 Nov 2020 08:31:22 +0100 (CET)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx1.uni-regensburg.de (Postfix) with ESMTP id 470DF600004D for <ntp@ietf.org>; Thu, 12 Nov 2020 08:31:18 +0100 (CET)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Thu, 12 Nov 2020 08:31:19 +0100
Message-Id: <5FACE4C6020000A10003C9E1@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.3.0
Date: Thu, 12 Nov 2020 08:31:18 +0100
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: watsonbladd@gmail.com, "ntp@ietf.org" <ntp@ietf.org>
References: <CACsn0c=Xu31KyHu8+uq+fKBMVRt+YaJGZCfSn2ph1WXfm2atHw@mail.gmail.com>
In-Reply-To: <CACsn0c=Xu31KyHu8+uq+fKBMVRt+YaJGZCfSn2ph1WXfm2atHw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/-gQAWURkVBTujZtMC3JJyG-GCB4>
Subject: [Ntp] Antw: [EXT] Circular dependencies
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2020 07:31:30 -0000

>>> Watson Ladd <watsonbladd@gmail.com> schrieb am 11.11.2020 um 18:21 in Nachricht
<CACsn0c=Xu31KyHu8+uq+fKBMVRt+YaJGZCfSn2ph1WXfm2atHw@mail.gmail.com>:
> Dear NTP WG,
> 
> I just realized there is a mailing list bug report that's a lot more
> interesting than it seems. They have a DNSSEC validating resolver and
> were using an NTP daemon to set the clock (and the RTC was busted) But
> the time is needed to verify liveness of the signatures for DNSSEC to
> validate, and without the names don't resolve, including the NTP
> server names.
> 
> This is probably a bigger issue with NTS, as certs with IP addresses
> are harder to get. Roughtime can use its own keys, but does still rely
> on the DNS often, so it won't necessarily be a solution. Any ideas?

Hi!

We have similar problems with network/LDAP/user resolution, and I wondered what the "best" solution would be. When eventually deciding it would be best to have local copies of the LDAP users involved, I noticed that the tools (useradd, usermod) would not allow to create identical local users if a user with the same name exists in LDAP...

I guess  the situation should be better with the host name scenario, but unlike (system) users, DNS records change more frequently. Maybe some type of local cache ("boot persistant") would be best.

Interestingly autokey had the same problem: If the system has no time, it cannot get the time via autokey...

Regards,
Ulrich


> 
> Sincerely,
> Watson Ladd
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp