I was thinking about the not the closest-server problem today, and realized this is a good application for BGP-DNS http://www.enyo.de/fw/software/bgpdns/ Making it possible to look at the reqeustor's network location and retrun the "closest" servers.
-Ejay
I did a little writeup of something along these lines a few months back
when pool.ntp.org first came up. I've not had a chance to develop it yet
however.
Because NTP is a UDP application, Anycast may be a more appropriate
solution for finding a "close" NTP clock. Of course, if your network is
multicast enable, NTP already supports multicast.
Take a look at powerdns and its mysql backend. Then look at the database
that's on mysql's website re:networks and their geographical location.
I'm sure that powerdns (open source) could be modified to do the
appropriate query and return the correct ip address. much simpler.
Curtis
ejay.hire@isdn.net ("Ejay Hire") writes:
I was thinking about the not the closest-server problem today, and =
realized this is a good application for BGP-DNS =
bgpdns Making it possible to look at =
the reqeustor's network location and retrun the "closest" servers.
you mean you believe you can predict which server is going to be best(*)
for a given client by looking at aspath length? to quote rocky the
squirrel, "that trick never works!"
what you're looking for in terms of an ntp server is "best isochrony".
as long as the delay and loss constant it doesn't matter how high they
are. a secondary sort term would be server load, but presumably a
server which was too loaded could just stop answering new clients.
time, like netnews, should roughly follow router topology. get time from
your isp and let them get it from GPS/GOES or their peers/transits/whatever.
We run NTP client and server on all of our customer touching and core routers and we just tell them to make their WAN gateway their NTP server. This works well for us and we need to have correct and synchronized time on all of our routers for logging and debugging purposes anyway. The processor penalty seems to be very minimal (if anything) to respond to NTP requests and seems to make sense to further the load distribution as much as possible. Do others do this? does anyone see a reason it shouldn't be done this way? It just seemed to make sense to me.
-Robert
Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
"Good will, like a good name, is got by many actions, and lost by one." - Francis Jeffrey
Already published in other forums.
As a general principle, having an open UDP port exposes your network
infrastructure to either something like a NTP worm (if one was written)
or a great attack amplifier by spoofing NTP queries from a victim's IP
address. You can search Google for other NTP specific security issues.
Unfortunately, ISPs need to supply services to customers and every
service is potentially vulnerable to some type of attack. Even an
isolated network such as the proposed GOVNET is vulnerable to certain
types of attacks.
ISPs provide time services in a few common ways
1. They don't provide time service, use a "public" time server
2. They provide time service from/to only selected NTP servers
3. They provide time service from router interface to only the direct
customer network
4. They provide time service to anyone
: ISPs provide time services in a few common ways
: 1. They don't provide time service, use a "public" time server
: 2. They provide time service from/to only selected NTP servers
: 3. They provide time service from router interface to only the direct
: customer network
: 4. They provide time service to anyone
The RON box we host provides Strat 1 multi and unicast NTP service.
All our hosts sync to multicast NTP and the users are welcome to do so, too.
Enterprise customers may sync one or two hosts,
unicast, to the Strat 1 clock and set up their own chimers for their
users or just use the multicast service.
I admin two NTP Strat. 2 Linux boxes, with are open to all our users
who can't hear multicast.
James Edwards
jamesh@cybermesa.com
Routing and Security Administrator
I don't see how a (unicast) NTP service could be used as an effective
amplifier, though it could be used to conceal the source of a ~1:1 DDoS
attack.