1

I have an application that's running a REST API and recently a requirement came up to have an NTP server associated with the application. My question is whether or not it makes sense to have an endpoint on the API that users can query (i.e. api/ntp/time) which returns NTP packets, and what are the implications of a setup like this?

I've been trying to connect to this endpoint using ntp clients like ntpdate and Python's ntplib, but those clients are making the assumption that there will be an NTP server running on the IP address at port 123, and the past few days of research have shown that this assumption largely holds true for most any NTP client software.

I'm using an endpoint to serve this information for a few reasons:

  1. I don't have any control over the webserver configuration for the application, so I can't proxy pass from port 123 or anything like that
  2. I have no control over what ports any of the web applications run on
  3. I have no real access to any stratum 1 device; we're running off of the assumption that the host serve is keeping its clock appropriately synched to a stratum 1 device (which is actually a safe assumption in our case).
sjyn
  • 11
  • 2
  • 1
    If #3 is true, why don't you just return the host's date/time? Or do you _really_ need a NTP connection? – Lenniey Nov 13 '18 at 15:22
  • 6
    It doesn't make sense to run "NTP over HTTP"; these are completely different protocols for completely different purposes. You can certainly have an API endpoint tell clients what the server's idea of the date is, but you can't really assure more accuracy than about 1 second. That's enough for some things, like old versions of Kerberos that require clock synchronization, but you can't run a TV station with so little accuracy, or you'll fail to air the beginning or end of programs... – Michael Hampton Nov 13 '18 at 15:31
  • I think both these comments help me feel a little better about the setup. The main purpose of this project requirement was to give devices that have no on-board clock a general concept of what time it is, and ultimately the end use won't be seeing data at any interval finer than a minute, so it may suffice to just use the NTP packet structure to report time from the endpoint. – sjyn Nov 13 '18 at 15:43
  • 1
    You don't even need an API endpoint if you have a sane web server, because the server should be returning a `Date:` header in it's response that says what date and time the server thinks it is (in fact, dependence on this by some applications is becoming a rampant problem in the ntp.org pool, individual servers are seeing positively insane amounts of bogus HTTP traffic that really just wants to parse the `Date:` header). – Austin Hemmelgarn Nov 14 '18 at 16:28

1 Answers1

2

As noted in the comments, NTP is not suitable for proxying over HTTP. From your comment you need an NTP server running on the network that devices which don't have an on-board clock an synchronize to. It is common for devices without an on-board clock to set their clock from an NTP server on startup, and many have and NTP client that allows them to stay synchronized. On-board clocks tend to drift, so using NTP for devices with on-board clocks is recommended practice.

Your server should be running an NTP client so that its time is accurate. You can then use the server time to respond with the server's time. I would suggest using either UTC or providing the UTC offset if providing time in your local time zone. Consider a format like 2018-10-16T19:20:30.45+01:00 which includes fractional seconds. Devices using this data to set their clock will end up with their time running a little behind the correct time due to latency effects. NTP has mechanisms to correct for latency.

BillThor
  • 27,737
  • 3
  • 37
  • 69