[62453] in North American Network Operators' Group
Re: .ORG problems this evening
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Thu Sep 18 11:25:54 2003
Date: Thu, 18 Sep 2003 11:19:49 -0400
From: Leo Bicknell <bicknell@ufp.org>
To: nanog@merit.edu
Mail-Followup-To: nanog@merit.edu
In-Reply-To: <Pine.NEB.4.58.0309181000260.8936@server.duh.org>
Errors-To: owner-nanog-outgoing@merit.edu
--zYM0uCDKw75PZbzx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Thu, Sep 18, 2003 at 10:05:15AM -0400, Todd Vierlin=
g wrote:
> Anycast is *NOT* a "redundancy and reliability" system when dealing with
> application-based services like DNS. Rather, anycast is a geographically
I think you'll find most people on the list would disagree with you
on this point. Many ISP's run anycast for customer facing DNS
servers, and I'll bet if you ask the first reason why isn't because
they provide faster service, or distribute load, but because the
average customer only wants one or two IP's to put in his DNS config,
and gets real annoyed when they don't work. So it is a redundancy
and reliability thing, the customer can configure (potentially) one
address, and the ISP can have 10 servers for it so if one dies all
is well.
Is it appropriate for a gTLD? Now that's a whole different can of
worms. Personally I think they should return the two anycast
addresses, and as many actual server addresses as will fit in the
packet. This is the best of both worlds. When it works, geographicly
distributed load, redundancy at the IP layer, quick responces. When
one of the failure modes is encountered (eg, stuck route) DNS has
the information it needs to switch to a backup as well.
Redundancy is good. Redundancy at two levels is even better,
particularly when they can back each other up. Plus, in this case it
costs them nothing, they just have to tweek a config.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
--zYM0uCDKw75PZbzx
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE/ac0VNh6mMG5yMTYRAhLWAJ0XJysdxHqiUM3yrcVhGZ1je6REmQCaA7qC
wO4zcfNKBz9X8RuxceXDbQw=
=puFM
-----END PGP SIGNATURE-----
--zYM0uCDKw75PZbzx--
