number of dns

Simon Waters Simon at wretched.demon.co.uk
Mon Jan 19 23:43:19 UTC 2004


hdu wrote:
> I would like to look at some academic paper discuss on number of dns servers
> to host a domainname. Do anyone know that?
Not seen any.

All the academics I know would be more interested in the general
problem, of which DNS is but one concrete example. I think the specific
case is of little academic interest.

I suspect the risk analysis is pretty straight forward, if you calculate
probability of failure of servers, and network links, and then just
compute the probability of concurrent failure of all service providers
(link + server). You need to allow a 'time to repair' to do the
calculation, but in that sense it is very similar to the calculation of
disk failure rates in disk arrays.

You probably assume anything more dramatically wrong than that (failure
of core Internet routing) invalidates the need for the DNS anyway, or is
beyond your control.

Since it is easy to duplicate DNS servers (for most purposes) more is
better till you allow for the consequences of one being compromised.
Although here the poor deegation habits of Internet users already add a
hard to assess risk here.

I suspect the marginal benefit of extra servers is far outweighted by
cost at about 3 or 4 servers (unless your service is absolutely
critical, or must survive deliberate distributed denial of service attacks).

Most 'professional' DNS services deploy three or more servers for key
domains, on physically and logically diverse networks, and rarely report
complete loss of service due to technical failures. The bigger problem
is administrative error - deleting the wrong domain - wrong TTL etc, or
failure to monitor and thus respond if a server is unavailable for some
reason.


-- Attached file included as plaintext by Ecartis --

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFADGuYGFXfHI9FVgYRAi+NAKCTibHbqA8UPg7mOcKCI2Yi1fGvtgCeIRDS
EHVGlLO38ZIi8xhNJbkKHmU=
=gi+T
-----END PGP SIGNATURE-----




More information about the bind-users mailing list