DO NOT run scheduled requests to a public server at the top of the hour, pick a random minute. The worst victims of this problem are community NTP servers - at every hour and especially 00:00:00 UTC, the traffic spike is just impressive.
Also consider rate-limiting and exponential backoff in retry loops. Otherwise the results can be quite spectacular.
Some Internet folklore from China: In 2009, a random guy paid for DDoS to attack a competing game server and disabled its DNS service. Just a regular day, right? Following that, a popular video player with 1 billion installations, appropriately named Storm, all entered an endless retry loop to phone home, DNS requests flooded China Telecom's backbone and caused a nationwide network outage. The attackers suddenly found themselves to the state's enemies.
@niconiconi systemd unit options, in case one uses a systemd timer:
these two options may be adjusted depending on how much (or little) variance there should be.
@niconiconi Pro tip: If you run an NTP server, shut it down for five minutes around midnight for maintenance.
That will teach them.
No, it will not teach anything. This has been discussed to some extend in the public NTP server community. My take-away: There is nothing short-term that can be done to rectify the situation.
There's a "kiss of death" packet defined in the protocol, which you can send to badly programmed rogue clients (it contains no usable time info), or you can ignore their requests. Either will cause many to simply send more requests without exponential backoff.
I personally know too many people who would rather copy/paste fifteen bad stackoverflow examples than to read even the synopsis of a standards document...
But I just head a great idea for a cyberpunk work of fiction where covert members of the FOSS army sneak into companies and other places housing old hardware and destroy (or even update) them.