North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Open Letter to D-Link about their NTP vandalism

  • From: Alain Hebert
  • Date: Fri Apr 07 18:14:30 2006


Should not be hard to fix...

Its clearly a missuses of services.

Couple of thinks:

Since its bgp and DIX customers surely have to provide a list of subnets to announce (filter and such), add those the the ntp server,

or use ipf/ipfw/iptables to filter in the dix customers

and I would redirect the others traffic to a dummy clock with a messed up time... after a few complaints DLINK would wake up.
(Dont try to pin any legal issues to this ... its DIX servers/bandwidth/ressources, DLink (and its customers) has no regard on what DIX does with its ressources)


Also there is a list of ntp servers in the device and I'm sure DLink never got the permission from most of them.

So try to contact the 100+ ntp services for a class action.


DLink should use,,, and even better provide their own

Jeff Shultz wrote:

Rubens Kuhl Jr. wrote: service is described as:

DK Denmark (
Location: Lyngby, Denmark
Geographic Coordinates: 55:47:03.36N, 12:03:21.48E
Synchronization: NTP V4 GPS with OCXO timebase
Service Area: Networks BGP-announced on the DIX
Access Policy: open access to servers, please, no client use
Contacts: Poul-Henning Kamp ([email protected])
Note: timestamps better than +/-5 usec.

I think he should use dns views to answer the queries to and either:
( a ) answer to all queries from outside his service area
( b ) answer a D-Link IP address to all queries from outside his
service area (which could lead to getting their attention; dunno if
from their engineers or from their lawyers).

Neither of which would solve the problem of his bandwidth being used by these, although (b) might actually serve to get their attention.

Perhaps as a thanks to him for the public service he provides the DIX, all of the users at DIX could set their external routers to reject incoming NTP packets from networks other than their own? Or even combine that with (b), although it might be more effective if it targeted, oh, instead of an IP address.

Then at least it would not be taking up internal DIX bandwidth capacity.

By no means am I encouraging legally actionable activity, however, and as noted, (b) just might be.

Alain Hebert [email protected] PubNIX Inc. P.O. Box 175 Beaconsfield, Quebec H9W 5T7
tel 514-990-5911 fax 514-990-9443