|
Re: national security
2003-12-04 20:34:30
Paul,
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(_at_)sopac(_dot_)org (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.)
|
|