On Feb 29, 2012, at 11:00 AM, Todd Snyder wrote: > The reason I’ve heard a few times is that users are uncomfortable using only > 1 address. In the past I’ve done 2 or 3 addresses just so that we can give > out 3 addresses that all point to the same pool of servers. > > Silly, I know, but sometimes it’s easier to placate than to change > someone/groups understanding of the > world/networking/resilience/dns/loadbalancing.
It's partly silly, it's also partly not wanting to have all your eggs in one basket. Having more than one anycast address provides protection against things like routing attacks / leaks, overenthusiastic ACLs, router blackholes and similar. It also provides a backup in case the primary node chosen by your routing infrastructure is unavailable -- if you only have a single anycast address (192.0.2.1) and the instance chosen by your routing system is down (for example though a DoS, misconfiguration, etc) you have no service. If you have a second address (10.10.10.10) that is announced by a different constellation you have redundancy. Also, anycast provide the closest instance according to the *network topology* -- this doesn't always equate to fastest response -- if is not uncommon for a longer BGP path to have a shorter latency. providing multiple addresses allows the resolver to choose based upon time. W > > > $0.02 > t. > > From: bind-users-bounces+tsnyder=rim....@lists.isc.org > [mailto:bind-users-bounces+tsnyder=rim....@lists.isc.org] On Behalf Of ju > wusuo > Sent: Tuesday, February 28, 2012 10:56 PM > To: bind-users@lists.isc.org > Subject: Anycast DNS > > Have seen some anycast DNS implementations using more than one address, some > times even on the same subnet, any considerations or reasons for doing that? > > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from your > system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
