[ntp:questions] Thoughts on KOD

Jason Rabel jason at extremeoverclocking.com
Mon Jul 7 14:05:51 UTC 2014

I have to agree on some points with these two below. From my experience also, using KOD usually results in more packet pounding from
bad clients (from what I can only assume is poor coding of custom clients).

The realization is that many clients don't run the standard NTP distribution, but rather some old hacked down / self-coded minimal
NTP / SNTP version to run on embedded hardware. Likewise many of the routers don't even use NTPD code with a constantly running
daemon, but rather more along the lines of ntpdate code that cron triggers at regular intervals.

Sending a date in the past could trigger the client to treat it as invalid, and it simply will make a request again & again,
expecting some more legitimate value. Also that could be seen as (unintentionally) malicious. So I do not think that is route we
would want to go.

I think the best thing to do would be to keep it simple and "not reply" to a bad client... It might make a few follow-up queries,
but eventually it would (hopefully) give up.

Adding more code to KOD and increasing its complexity does not seem like a wise choice to me, especially when you would need to
consider backwards compatibility, and in the case of bad clients, no compatibility.

>> I think it is best to remove KOD from ntpd.
>> It does not serve a useful purpose, because precisely the kind of
>> clients that you want to say goodbye to, do not support it.
>> In real life it has either no effect at all, or it even has a negative
>> effect because the client does not understand it and re-tries the
>> request sooner than it would when no reply was sent at all.
> Seconded.
> I recommend providing motivation for the undesired clients to stop using
> the server, by the server sending a regular response indicating that it
> is not synchronised or replying in some other way that has no
> timekeeping value to the offending client. Another way would be to use a
> bogus fixed timestamp that is in the past (i.e. one that suggests that
> there is no passage of time on the server).
> My recommendation is based on the assumption, yet to be verified in
> practice, that this server behaviour won't result in worse client
> behaviour than would be the case if the server just served the client's
> request as normal.

More information about the questions mailing list