Re: [Ntp] NTS Pools

Luke Valenta <> Wed, 17 April 2024 17:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 37BFDC14CF18 for <>; Wed, 17 Apr 2024 10:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7wRWH7Gh6uWt for <>; Wed, 17 Apr 2024 10:28:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 3C7D9C14F5EA for <>; Wed, 17 Apr 2024 10:28:26 -0700 (PDT)
Received: by with SMTP id d9443c01a7336-1e51398cc4eso54329985ad.2 for <>; Wed, 17 Apr 2024 10:28:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google09082023; t=1713374905; x=1713979705;; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=TBRdMfo+h0MpZY6V8sCkRvJs4A6ns5Vd6TaTdOsxD2c=; b=a285GGb3Mv4or3l/wjMk7qPhOYlvK5QDRon47mOp3Z8P6H16mn6/c57umnS+72sbOT zSMNd7YzEQB6XjfoK7I4WvuT/SGJuHLV5be6eS3AXM4XtZ4ampGSHzFPJL9bgMJovF4A 7zYF0KADuazfJPY2BjWcMCtM2W1uUWaOYcsG/yXLvLyq+PQBvXwJvRugKcNlGeWinLnD wzNxpgsTzCjhG8/Vcm/vkPwGEVNK1SJt4/rNlV+YUb/sieNLr0It2rWZk+EyRyReJSSd JwebgJKY+K/KON7OBqRldONjhC4yLs/4uetdv63OZSmmeX/LIe1Frl0WB0ikNnJl1nhI j1jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1713374905; x=1713979705; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=TBRdMfo+h0MpZY6V8sCkRvJs4A6ns5Vd6TaTdOsxD2c=; b=eiEAzNYOF8hssZcaSGoj5aVjtMMeAr0Z5khj/oJZaS2kslLxXIGoKlWFuEX2BKRxmE svc1u5D9RMiN7cuDyl5BoqpYxGZyhRcagLz3VRPG6/KYjma9gXBdgQO3+jdNgAmShEFN Nudn29+i6c06WlX68vN8BaVCFqVzd9VnGLie33YTALZZkG6q7/25f3xRXcthomG1IVe1 d9xloTiyJkP4o4SIBlRUuYqj/yT89wdyIQugTR91pWAUVOJ00JT+ZDahDsVk3M8x3749 Q5ncIFj/GUCJKBc4PQRYTapW/WEOwFjJ4f6hPwhqedV75nqNPngcFuZ5qjnZUZTLW883 R0og==
X-Gm-Message-State: AOJu0YxdmzILNE5Wg+i7Tp4e9vziruub8mmlMVmZ4FYeWQoRlNr/vyNv 2VJoFwRgUS83TtBq/VK5y9nqJ2obVP3XcWmsrE7pSx4T3DOnk1415G5s6DRGJHUx4AIsKX9C8Cp bGV994ghodjJ97RS+Sc3x7k90XIDvDUXBF8pPLyTLyU+xFPrjlLY=
X-Google-Smtp-Source: AGHT+IGmJAevVGcAp7XHjJUL5/3ZdlUcpnePMgs49MBX5+PKWRj21ekzJx0QBq0VxmLn59b7kOilIJDmZAWorqnKK4U=
X-Received: by 2002:a17:903:32c5:b0:1e2:8841:8d67 with SMTP id i5-20020a17090332c500b001e288418d67mr170450plr.32.1713374905112; Wed, 17 Apr 2024 10:28:25 -0700 (PDT)
MIME-Version: 1.0
From: Luke Valenta <>
Date: Wed, 17 Apr 2024 13:28:14 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="000000000000968c8906164e2e92"
Archived-At: <>
Subject: Re: [Ntp] NTS Pools
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Apr 2024 17:28:36 -0000

Sorry for chiming in late, but just wanted to voice another opinion here.

> My primary goal currently is to work towards a pool or pool-like solution
> 1) Is drop in for end-users. I.e. if you have a working NTS client,
> the pool can be used without any changes to software.

I'm not sure I agree with this requirement. We currently still see a fairly
low number of NTS requests to our public time service (at least in
comparison to NTP requests), so it seems like now is as good a time as any
to make changes to clients, even if those changes take some time to see
widespread deployment.

> The rationale behind the first subpoint is that this is in my view
> critical for adoption. Without it, I think it is hard to get to a
> critical level of adoption. Furthermore, requiring specific support in
> the client likely means there will always be some clients not
> supporting that pool.
> ...
> Given these goals, I myself find the NTS-KE load balancer approach the
> most attractive. Requirement 1 limits the options to either Shared
> domain name, NTS-KE generating cookies or NTS-KE load balancer.

If we remove requirement 1, I personally find the DNS SRV Records proposal
from Watson [1] to be the most attractive option. The NTS pool operator's
job remains largely the same as in the status quo--to provide a discovery
mechanism for NTP providers. The interaction between pool operators and NTP
providers remains minimal (especially if we drop the "pool associated
domain names" part).

In [2], Miroslav raised some concerns about some client support for SRV
records and DNSSEC. I don't have a great sense of how much of a blocker
this would be overall, but surely it would allow for an easier transition
to NTS pools for _some_ platforms.

My main concern with the NTS-KE load balancer approach is that it
significantly increases operational strain and uptime requirements for the
NTS pool operator, which might make it infeasible for a volunteer-led
organization to run.


Luke Valenta
Systems Engineer - Research