Bad neighbor policy?
Many years ago, I needed to deploy a bunch of UNIX machines very quickly. When
I created the golden system image, it included an ntp.conf file that pointed
to a nearby public stratum 2 server not under my administrative control. This
was dumb, because I could (and should) have just had my boxen chime against a
local machine, and have it (and only it) hit the stratum 2 box.
About a week later, I got an email from the admin of the stratum 2 server
that politely pointed out these facts. A half hour later, cfengine had
fixed my error, and I red-facedly responded to the gent whose resources I
had ignorantly abused.
Well, a Danish member of the FreeBSD team is running up against the same
issue on a much larger scale, except that D-Link is the abuser, and they aren’t fixing the problem.
If I had any dlink gear, I’d call and ask them for a fix. thousands of customers clogging their phone lines about this can’t be wrong.
There are a few more details from Richard Clayton, who helped Poul-Henning Kamp track down the problem originally.
In my experience, D-Link has some of the worst firmware and driver software out there. I refuse to buy anything from them more complicated than a switch after several bad experiences.
One of the sad things about this is there’s already a service set up that would do what D-Link really needed, with very little effort on their part. Pointing an NTP client at pool.ntp.org will automatically direct it to a randomly-chosen NTP server, out of a pool of servers whose admins have agreed to provide this service.