ICANN/DNSO
DNSO Mailling lists archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: Registration data backup? (RE: [ga] We can't be against it?)


Marc Schneiders wrote:

> Are you *sure* there is no decent backup system in place at NSI? I
> have no idea, but would be surprised if not.
 
So would I. In fact, that were the case I'd be entirely amazed, completely
dumbfounded, ... (searching for stronger expression and not finding one).

However, 'backup' has several meanings, and I'm not sure they're all
covered.

One is the normal backup mechanisms any business applies to its critical 
data. This has a number of levels: RAID arrays, duplicate servers, backup
to removable media both on and off the primary sites, ... This is the one
I'm almost certain NSI are doing. They'd have to be insane or spectacularly
incompetent not to.

Methinks their ICANN contract should require this type of backup, along
with the full set of RFC 2870 root server admininstration standards, and
compliance should be audited. However, that's just good business practice
on ICANN's part; no big issues arise.

Question:
Do the contracts in fact require that and how is it audited?

Escrow, timely provision of data to an outside organisation, is a separate
question. Various people, notably Froomkin, have been rather pointedly
asking about this and getting no good answers.

Of course this question ties in to the whole issue of who owns the data
in DNS and whois. Auerbach has some good comment:
http://www.cavebear.com/cavebear/growl/index.htm
See the section on whois in the "What I would say ..." paper. I will
not go into those issues here.

Rick Wesson writes, in the "Net security's a losing battle" thread:

| As one who sat on the ICANN Escrow committee I can state that the
| committee did create a final draft that specified escrow formats
| and how escrow would be done. The document was forwarded to ICANN
| and I have no clue why they didn't implement it. All ICANN need to
| do is publish their requirements on escrow, and start up their 
| service, which they have had over 9 months to complete.

Qusetions:
Is this draft online? Where?
Will the draft be implemented? When and how? 
If not, why not and what is the alternative?

There are several additional questions -- overlapping both with both
NSI backup and with escrow, but by no means synonymous -- in the area
of disaster recovery, and more generally with system resiliency in the
face of failures or malice.

I cannot see that these are big issues, assuming that the root servers
are suitably geographically dispersed and that they are properly (RFC
2870) managed.

Questions:

Are root servers suitably dispersed? It appears not entirely so from
the map at:
http://www.wia.org/pub/rootserv.html
One in Japan, two in Western Europe, ten in the US.
Is that map out of date?

Should we not add at least one server each in Eastern Europe, mainland
Asia, South America and the Antipodes? This might save network overhead
as well as increasing resiliency against various failures.

A report on Y2K readiness of the root servers:
http://www.icann.org/committees/dns-root/y2k-statement.htm
had this text:

> Due to protocol limitations, the number of these machines is currently
> limited to 13, although efforts are underway to remove this limitation. 

Has that limitation been removed yet? If so, should we now add servers?
If not, can we get it removed? 

Are all the root servers well-managed? Do the ICANN contracts require
this and provide for auditing?

Are servers other than the root a concern? If so, are they an ICANN
concern? Clearly an accident or an attacker could do considerable
damage to the net without touching the root -- for example hitting
the zone servers for .uk, .jp or .org. Can and should ICANN require
RFC 2870 standards for administration of those?

Do the NSI-run TLDs such as .com live on servers separate from the
root servers? Should they?
--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html



<<< Chronological Index >>>    <<< Thread Index >>>