| ▲ | simonjgreen 4 hours ago | |||||||
I’m pretty sure this way they’ve hardcoded the NTPs is actually against the ToS for use of the NTP pool too. The way a vendor embedding NTP is _meant_ to do so is documented here: https://www.ntppool.org/en/vendors.html On another note, back when I ran a web hosting business we hosted a few NTP servers in the pool. It’s such a simple thing to give back, and worth anyone who can make a stable contribution doing so. | ||||||||
| ▲ | kelnos 2 hours ago | parent | next [-] | |||||||
> The pool is currently keeping the time of an estimated 5-15 million systems accurate. When was this page last updated? I would expect that number to be in the hundreds of millions these days, perhaps even billions. | ||||||||
| ▲ | lgeek 3 hours ago | parent | prev | next [-] | |||||||
If you do run an NTP server, please make sure it's not vulnerable to DDoS amplification (monlist, readvar, etc need to be disabled) and apply some rate limiting to make it less useful for reflection attacks. And be proactive about monitoring its traffic volume. If you see high packet rate from a specific IP address or prefix, it's very likely not them abusing your service, but rather you attacking them by responding to spoofed requests. | ||||||||
| ▲ | jameshilliard 4 hours ago | parent | prev | next [-] | |||||||
> The way a vendor embedding NTP is _meant_ to do so is documented here: https://www.ntppool.org/en/vendors.html Note that in the past I've had companies writing embedded linux based firmware using ntppool for time sync request their own vendor zones, however a lot of those requests were ignored so it's unclear if that's still expected. In the end they ended up just using the default ntppool domains since they never got their own vendor zones. | ||||||||
| ||||||||
| ▲ | robinpie 4 hours ago | parent | prev [-] | |||||||
Yes, they should absolutely be using a vendor zone instead of a CNAME under tesla.com. | ||||||||