2012/3/1 Beavis <pfu...@gmail.com> > Just want to piggy back on this topic is there any documentation > available online that shows a deployment guideline for Anycast? > > -beavis >
What about RFC 4786? > On Wed, Feb 29, 2012 at 10:31 AM, Warren Kumari <war...@kumari.net> wrote: > > > > 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 > > > > -- > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > > Disclaimer: > http://goldmark.org/jeff/stupid-disclaimers/ > _______________________________________________ > 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 > -- -- AP
_______________________________________________ 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
