"KoD": is it something to avoid in the server configuration or still useful?

Kiss of Death packet is sent by the server when multiple NTP client packets are received with less spacing than two seconds in between. This is the case when “kod” parameter is in the configuration of the NTP server. At the time of standardizing that rule the (probably just implicit) assumption was that there is only one single NTP client behind one client IP address. I believe that this assumption is less and less true due to the widespread use of NAT. Client packets may interleave from multiple, different NTP clients behind the same NATed IP address, without respect of the required two seconds spacing in between.

I do not put the kod option in the configuration of the NTP servers I am managing. What is your take on that?

The system here may be affected by that, but the two second timeout may be to long ?. Ideally, a more granular approach might feature a system tunable to set that to lower value, or count the number from the same ip before sending a kod or dropping packets ?..

I removed kod and limited altogether to fully support NATed clients, as long as they are using the latest protocol (enforced using version).

1 Like

I disabled limited for the same reason, but afaics, kod needs limited to function, so it does nothing, included or not. Don’t restrict version and have seen a few ntp v1 clients in the tcpdump screen. Never knew that even existed…

Most clients don’t understand a KoD response. It can actually cause them to quickly send another request, which increases the traffic, opposite of what it is supposed to do. There is one case where I found it useful though. When decommissioning a server, I let it respond, but only for few hours, to all requests with KoD RATE and a large poll value. This greatly reduces the amount of traffic from old ntpd clients, which don’t switch to a different server when it becomes unreachable, but at least they can lower their polling rate to become insignificant.