[OK, not saying I'm for a blacklist, or willing to run one. I'm not sure how it'd actually help. But some of these statements just can't be left unchallenged.]
Brad Knowles wrote: > I don't think that trying to build this functionality into ntpd is > the way to achieve this goal. The program is bloated enough as it is. Access control hardly seems like bloat in a server. Though the issue with not wanting to hit the disk could be challenging. >> And absolutely none of them would ever need to look-up the blacklist. >> >> You said it yourself, they should be *using* ntp, not *serving* ntp. > > > Go back to that list again. Any or all of them can, and arguably > should, be doing NTP both as client *and* as server. The only people who would be using it would be public NTP servers, most likely only those in pool.ntp.org. > While the probability that any one given SOHO server might be under > attack is fairly low, the probability that Linksys or DLink are > guaranteed to have a significant number of customers under attack at any > one time is pretty high. So, it makes perfect sense that they would > want to extend their existing firewall capabilities to include the use > of such a black list. Considering last I saw neither Linksys, DLink, nor Netgear has even blacklist capabilities for even dshield.org, or any of the email RBLs, or any other blacklist at all, this seems higly unlikely. Further, its possible to limit the blacklist to members of the pool if whoever running it is worried about being overloaded. > Because the way ntpd works is to lock everything in memory, so that > it can guarantee that it never gets paged or swapped out, and that it > never, ever has to hit the disk again. This isn't quite true. ntpd routinely hits the disk to write logging information. _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
