>> [...two possible ideas for dealing with Turk Telekom...]
> Both suggestions are very bad ideas IMO. Consider what might happen
> when N.tr.pool.ntp.org "stops working" (for some definition of that
> term). The end clients might well pick on random victim servers and
> choose very unwise and/or undesirable targets.
Yes...but they might do that no matter what we do.
Another thing that might help is to router-block Turk Telekom netblocks
from reaching the relevant DNS servers. I also wonder if having the
pool.ntp.org servers handing out 127.0.0.1 as NS for tr.pool.ntp.org
would help avoid the trouble.
>> Or perhaps the addresses of Turk Telekom's customer-facing NTP
>> servers, if they have any and their IPs are known?
> +1. Maybe. Suppose those hypothetical NTP servers are not reachable
> from outside Turk Telekom's network. It would then be bad if a
> lookup of N.tr.pool.ntp.org returned one of those IP addresses.
Perhaps. But that this point I don't think we have any options that
don't involve something bad; we just need to figure out which kind of
bad we prefer. Personally I'm trying to find a way that puts the `bad'
preferentially on Turk Telekom and to a minimal extent elsewhere.
> FWIW, Turk Telekom usually send clueful DNS/routing/addressing
> engineers to every RIPE meeting. I could meet them in September and
> arrange an introduction. They may be able to help the NTP Pool
> people find the right guys in the company to get this NTP thing
> properly sorted out.
Unless that has already been tried and failed, it sounds like a much
better approach than any of these technical measures.
Mouse
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
