[Pool] DNS queries per second

Dave Hart davehart at gmail.com
Wed Mar 23 00:53:02 UTC 2011


On Tue, Mar 22, 2011 at 11:59 PM, Ask Bjørn Hansen wrote:
> I don't have any ideas for how to avoid this; but basically a crazy amount
> of the SNTP clients sync just at the top of the hour; or close to it.

It is IMO reasonable to believe the subset of pool.ntp.org clients
which query near the top of the hour overlaps heavily with the subset
that blasts multiple queries back-to-back toward a server with no
spacing between them.  ntpdate from hourly cron will do that, for
example, prior to 4.2.6p2 and 4.2.7p22, where it was changed to
accommodate the default rate limiting in ntpd.

ntpd doesn't enforce rate limits by default, you have to ensure the
relevant ntp.conf "restrict" line specifies "limited" to turn on rate
limiting.  If you do, adding "kod" at the same time likely makes
sense.  With limited and without kod in the restrictions, queries
which exceed the limit are silently ignored.  With kod and limited, a
minor fraction of the rate-limited queries elicit Kiss o' Death
responses with a RATE refid and no usable time information.  This
gives clients an indication their behavior is unwelcome, if they're
still processing responses after the first.

I would recommend anyone running a ntpd pool server give serious
consideration to enabling rate limiting and KoD responses using
something like:

restrict -4 default nomodify limited kod
restrict -6 default nomodify limited kod

or if using ntpd 4.2.6 or later, the more concise equivalent:

restrict default nomodify limited kod

This won't solve the problem of lazy operators (and lazy engineers of
networking gear) configuring systems to use ntpdate from cron or
equivalent, but it will make their setups more fragile (because only
the first of 4 queries from older ntpdate will get a useful response)
and provide an opening for them to see the client's less-than-perfect
exchange and consider updating to a ntpdate that is less aggressive,
or if we're really lucky, come to understand why continous clock
discipline is so much better than baling wire and cron.

Cheers,
Dave Hart


More information about the pool mailing list