1. all this presumes that the root file is in good shape and has not been tampered.
How do you know the data in the file you disseminate are not polluted or changed?
2. where is the best documentation - from your own point of veiw - of a root server organization.
thank you
jfc
At 02:53 05/12/03, Paul Vixie wrote:
On Fri, Dec 05, 2003 at 10:44:00AM +1200, Franck Martin wrote: > Oh, btw to install a root server, any PC will do, it is not something > difficult as it carries only a couple of hundred records (200 countries > and a few gTLDs), not the millions of a .com.
On Fri, 2003-12-05 at 12:16, Suzanne Woolf wrote: > Operationally, this is a dangerous half-truth. It may be the case that > you can run a nameserver that believes it is authoritative for the > root zone and will answer for it in this way. But under real world > conditions (significant numbers of queries, possibility of DDoS or > other attack, etc.) this is far from adequate.
franck@xxxxxxxxx (Franck Martin) writes: > This is not a dangerous half-truth, It has to be demystified. Let's take > the example of a country like Tonga. A simple PC will do for them because > the number of Internet Users there is may be about a 1000 people. With > anycast properly set up only the packet of that country will reach the > local root-server (proximity), so it is unlikely to be under heavy load > with a 1000 of people on the Internet there...
my experience differs. when a root name server is present it has to be fully fleshed out, because if it isn't working properly or it falls over due to a ddos or if it's advertising a route but not answering queries, then any other problem will be magnified a hundredfold. doing root name service in a half-baked way is much worse than not doing it at all, since over time the costs of transit to a good server will be less than the costs of error handling and cleanup from having a bad one.
moreover, your statement "only the packet(s) of that country will reach the local root server" is presumptive. under error conditions where transit is leaked, such a server could end up receiving global-scope query loads. in our current belt-and-suspenders model, we (f-root) closely monitor our peer routing, AND we are massively overprovisioned for "expected" loads, since a ddos or a transit-leak can give us dramatically "unexpected" loads.
if you know someone who is willing to provision a "root" name server without a similar belt and similar suspenders, then please tell them to stop.
> Finally before a root-server is installed somewhere, someone will do an > assessment of the local conditions and taylor it adequately. I want > countries to request installation of root servers, and I know about 20 > Pacific Islands countries that need root-servers in case their Internet > link goes dead. > > cf www.picisoc.org if you want to join us...
on a connectivity island (which might be in the ocean or it might just be a campus or dwelling), the way to ensure that local service is not disrupted by connectivity breaks is to make your on-island recursive name servers stealth slaves of your locally-interesting zones. in new zealand for example it was the custom for many years to use a forwarding hierarchy where the nodes near the "top" were stealth slaves of .NZ, .CO.NZ, etc. that way if they lost a pacific cable system they could still reach the parts of the internet which were on the new zealand side of the break.
using a half-baked root-like server to do the same thing would be grossly irresponsible, both to the local and the global populations.
note that f-root, i-root, j-root, k-root, and m-root are all doing anycast now, and it's likely that even tonga would find that one or more of these rootops could find a way to do a local install. (c-root is also doing anycast but only inside the cogent/psi backbone; b-root has announced an intention to anycast, but has not formally launched the programme yet.)