# NTS Support in the pools
**URL:** https://community.ntppool.org/t/nts-support-in-the-pools/2939
**Category:** Server operators
**Created:** [July 13, 2023, 12:00pm UTC](https://community.ntppool.org/t/nts-support-in-the-pools/2939 "2023-07-13T12:00:37Z")
**Posts on this page:** 13
**Page:** 1
### Author:  [@gerd](https://community.ntppool.org/u/gerd)
#### Post date: [July 13, 2023, 12:00pm UTC](https://community.ntppool.org/t/nts-support-in-the-pools/2939/1 "2023-07-13T12:00:37Z")
Hi !
Does the pool iiiiin common have NTS support ? Or do you plan separate pools for this ?
Ciao Gerd
---
### Author:  [@alica](https://community.ntppool.org/u/alica)
#### Post date: [July 14, 2023, 8:40am UTC](https://community.ntppool.org/t/nts-support-in-the-pools/2939/2 "2023-07-14T08:40:39Z")
There were some discussion in the past, but no progress until now.
> [@Proper cn in certificate for use with NTS](https://community.ntppool.org/t/proper-cn-in-certificate-for-use-with-nts/1381):
>
> I’m tinkering with NTS on 188.166.95.178 and 193.175.73.151 – NTS seems to be working, but which cn (in the x.509 Certificate) should pool servers use? Turns out that both servers can properly communicate using [char-ntp-pool.charite.de](http://char-ntp-pool.charite.de) and [mail.python.org](http://mail.python.org): server char-ntp-pool.charite.de nts iburst server mail.python.org nts iburst
---
### Author:  [@gerd](https://community.ntppool.org/u/gerd)
#### Post date: [July 14, 2023, 12:43pm UTC](https://community.ntppool.org/t/nts-support-in-the-pools/2939/3 "2023-07-14T12:43:36Z")
Hi !
Ok… im trying to be prepared…
BTW: must the cert point to host/domain name (cname) or to server name or to Ip address ?
Ciao Gerd
---
### Author:  [@marco.davids](https://community.ntppool.org/u/marco.davids)
#### Post date: [July 18, 2023, 7:55am UTC](https://community.ntppool.org/t/nts-support-in-the-pools/2939/4 "2023-07-18T07:55:16Z")
Server names work fine. I haven’t tested with an IP address in the certificate. Not all CA’s support that, so it can be challenging to obtain certificates with an IP address.
---
### Author:  [@ask](https://community.ntppool.org/u/ask)
#### Post date: [July 21, 2023, 1:35am UTC](https://community.ntppool.org/t/nts-support-in-the-pools/2939/5 "2023-07-21T01:35:15Z")
I don’t recall if NTS as it’s specified today supports this, but I think if we supported NTS the pool system would setup individual server names for each server (“server-5a52x.pool-servers.ntppool.dev”) and then having the certs be for those names (either with a public CA like letsencrypt or a small CA operated just for this by the pool).
If/when a server leaves the pool or is marked unhealthy for long enough the hostname and/or certificate could removed/invalidated.
Suggestions or discussion of how this would work by people knowledgable about NTS is most welcome!
---
### Author:  [@Jamesb192](https://community.ntppool.org/u/Jamesb192)
#### Post date: [August 1, 2023, 5:29pm UTC](https://community.ntppool.org/t/nts-support-in-the-pools/2939/6 "2023-08-01T17:29:44Z")
[Here](https://community.ntppool.org/t/dns-srv-records-for-ntp-and-nts/1556) is an old discussion re: srv records and NTS. BTW I think most of you are nuts, and SRV records would be the only reasonable way to get NTS into the pool. [Here](https://gitlab.com/NTPsec/ntpsec/-/snippets/1893083) is a ntpsec-only client-side bolt-on for an NTS pool using SRV records.
---
### Author:  [@marco.davids](https://community.ntppool.org/u/marco.davids)
#### Post date: [August 2, 2023, 7:29am UTC](https://community.ntppool.org/t/nts-support-in-the-pools/2939/7 "2023-08-02T07:29:34Z")
> [@ask](#):
>
> I don’t recall if NTS as it’s specified today supports this
[RFC8915](https://datatracker.ietf.org/doc/html/rfc8915) doesn’t have this, but there once was an attempt to do it:
> **[NTS for the NTP pool](https://datatracker.ietf.org/doc/html/draft-ladd-nts-for-ntp-pool)**
>
> Network Time Security authenticates NTP servers. This document outlines an architecture that uses ACME and SRV records for the NTP pool to carry out NTS.
This is a now expired draft from 2020. Haven’t heard anything about it since then.
---
### Author:  [@davehart](https://community.ntppool.org/u/davehart)
#### Post date: [August 4, 2023, 6:04pm UTC](https://community.ntppool.org/t/nts-support-in-the-pools/2939/8 "2023-08-04T18:04:20Z")
The **NTS for the NTP pool** draft has:
> Clients MAY periodically resolve the pool associated domain names to confirm the server is still trusted by the pool.[¶](https://datatracker.ietf.org/doc/html/draft-ladd-nts-for-ntp-pool#section-4-4)
That would turn over the pool server with most periodic resolutions if the NTS pool names were resolved similarly to today. Not a problem if those periodic resolutions were infrequent, and probably a good thing if the period were at least a day, preferably weeks. Unfortunately that was not specified in this first draft, and there are no more.
---
### Author:  [@Bas](https://community.ntppool.org/u/Bas)
#### Post date: [August 6, 2023, 6:17pm UTC](https://community.ntppool.org/t/nts-support-in-the-pools/2939/9 "2023-08-06T18:17:10Z")
> [@Jamesb192](#):
>
> [Here](https://community.ntppool.org/t/dns-srv-records-for-ntp-and-nts/1556) is an old discussion re: srv records and NTS. BTW I think most of you are nuts, and SRV records would be the only reasonable way to get NTS into the pool. [Here](https://gitlab.com/NTPsec/ntpsec/-/snippets/1893083) is a ntpsec-only client-side bolt-on for an NTS pool using SRV records.
There is no need to have ‘secure-time’ it serves no purpose.
Reasons:
1: If you are so insecure about time, use your own GPS.
2: If you don’t want this, use multiple sources to check time.
There is no reason at all to use NTS instead of NTP as it’s quite simple to check time.
NTS has no place in timekeeping. We should NOT serve those records, as it’s nonsense.
Same as public websites are encrypted, it’s dumb. Not everything has to be encrypted.
If you don’t trust time, buy a GPS. Simple as that. Also a GPS works without Internet 😆
---
### Author:  [@ebahapo](https://community.ntppool.org/u/ebahapo)
#### Post date: [August 17, 2023, 7:42pm UTC](https://community.ntppool.org/t/nts-support-in-the-pools/2939/10 "2023-08-17T19:42:21Z")
> [@ask](#):
>
> I don’t recall if NTS as it’s specified today supports this, but I think if we supported NTS the pool system would setup individual server names for each server (“server-5a52x.pool-servers.ntppool.dev”) and then having the certs be for those names (either with a public CA like letsencrypt or a small CA operated just for this by the pool).
Besides the specific host name in the pool, the certificate might also have to include the wildcard domain as an alternative, or `*.pool.ntp.org`.
As broad as it is, I can’t think of how else to have the certificate to match the host name that a client may be using, such as `pool.ntp.org` or `0.pool.ntp.org` or `europe.pool.ntp.org` or `1.asia.pool.ntp.org` or `ao.pool.ntp.org` or `2.bv.pool.ntp.org`…
---
### Author:  [@marco.davids](https://community.ntppool.org/u/marco.davids)
#### Post date: [August 29, 2023, 1:17pm UTC](https://community.ntppool.org/t/nts-support-in-the-pools/2939/11 "2023-08-29T13:17:18Z")
> [@ebahapo](#):
>
> the certificate might also have to include the wildcard domain as an alternative, or `*.pool.ntp.org`
Yes, but this may not work with older versions of NTPsec:
> **[NTS does not work with wildcard certificates (#729) · Issues · NTPsec / ntpsec...](https://gitlab.com/NTPsec/ntpsec/-/issues/729)**
>
> When an NTS-server is configured with a wildcard-certificate (such as ntppool1.time.nl at the time of writing this issue), NTPsec won't use it and it will log this:
---
### Author:  [@ebahapo](https://community.ntppool.org/u/ebahapo)
#### Post date: [August 29, 2023, 7:03pm UTC](https://community.ntppool.org/t/nts-support-in-the-pools/2939/12 "2023-08-29T19:03:04Z")
Then make it at least NTPsec v1.2.2.
---
### Author:  [@marco.davids](https://community.ntppool.org/u/marco.davids)
#### Post date: [December 22, 2023, 8:43am UTC](https://community.ntppool.org/t/nts-support-in-the-pools/2939/13 "2023-12-22T08:43:53Z")
Perhaps in the future it becomes easier and more doable:
> **[NTS extensions for enabling pools](https://datatracker.ietf.org/doc/draft-venhoek-nts-pool/)**
>
> The aim of this document is to describe a proof of concept system for NTS pools that are able to be used by clients without any knowledge beyond plain NTS. The work here focuses purely on creating an intermediate NTS Key Exchange server that can be...