pfunix at gmail.com
Thu Mar 1 03:40:32 UTC 2012
Just want to piggy back on this topic is there any documentation
available online that shows a deployment guideline for Anycast?
On Wed, Feb 29, 2012 at 10:31 AM, Warren Kumari <warren at 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.
>> From: bind-users-bounces+tsnyder=rim.com at lists.isc.org [mailto:bind-users-bounces+tsnyder=rim.com at lists.isc.org] On Behalf Of ju wusuo
>> Sent: Tuesday, February 28, 2012 10:56 PM
>> To: bind-users at 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 at lists.isc.org
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> bind-users mailing list
> bind-users at lists.isc.org
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
More information about the bind-users