In <[EMAIL PROTECTED]> Brad Knowles <[EMAIL PROTECTED]> writes:
> At 9:28 AM -0500 2005-07-28, wayne wrote: > >> I question whether we really need as many secondary name servers as >> are currently being used. We currently have 9, which is 3 more than I >> have for a anti-spam DNSWL that I run. How many DNS lookups/day are >> being made to pool.ntp.org right now? > > I think we could probably do just fine with one nameserver > from each of the groups. Pick the "best" nameserver each from > bitnames.com and bhms-groep.nl, and eliminate the others > within those domains. That would leave us with five > nameservers in totally different domains, etc.... I don't see the point in eliminating all but one bitnames.com name server. I don't think we need to have the pool name servers distributed over several organizations. On the contrary, I would suggest eliminating everyone except the bitnames.com name servers. Having monitored ns1.rbl.bitnames.com for about a year now, I can say that Ask has done a good job of running that name server and I see no reason why the name servers that in the pool would be any worse. Ask's name servers are probably pumping out 2-4 million DNS lookups per day for me. Having a bunch of well run, wildly distributed name servers run by the project leader has a lot of advantages. We could go with someone like dyndns.org for all the name servers. I have also had very good experiences with them also. >> Also, the 2 minute TTL for the A records is probably too short. I >> don't see much reason to make them shorter than the zone regeneration >> time, and the could be somewhat longer. > > The "refresh" and "retry" are both set to 900 seconds, which > kind of eliminates the value of having a retry at all. True, but that is irrelevant for everyone except the people running the name servers. > The default TTLs for the A records could > also be increased somewhat, as I believe that many common > resolvers use a floor of five minutes no matter what. Yeah, that was what I was referring to. > But I think that these are issues that are considerably less > important than the DNS packet truncation. The truncation isn't *too* bad since it is just the A records for the name servers that are getting tossed. That will cause uneven load on the various pool name servers, but not on the pool NTP servers themselves. By the way, thanks for noticing the problem and bringing the subject up. -wayne _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
