[dns-operations] anycasting for fun and profit

Patrick W. Gilmore patrick at ianai.net
Tue Oct 16 12:51:59 UTC 2012


On Oct 16, 2012, at 08:33 , paul vixie <paul at redbarn.org> wrote:

> dns anycasting can also be done solely with provider-assigned space and
> no ASN of your own. for ISC we have three anycast clouds, one for f-root
> which has its own prefix and its own ASN, one for our public benefit
> secondary service which has its own prefix adjacent to f-root, and one
> for our commercial secondary service which uses provider-assigned
> address space for each named server.
> 
> the advantage to using provider-assigned space is that the global
> routing table carries no separate burden on your behalf. i call this
> "green networking" since it's more ecologically friendly. the
> disadvantage is that if you want to change providers you have to
> renumber. renumbering in this case isn't all that painful since you are
> in control of the NS target name. there's a description at
> <http://www.isc.org/solutions/sns-anycast>.

This works, although limits your anycast nodes to a single provider.

While there is nothing wrong with single-provider anycast, I would argue having anycast instances in multiple providers is beneficial.

Also, it is difficult to find a network with truly global reach, limiting your choices if you want nodes in every corner of the globe.  Moreover, the few networks that are present on very continent all have restrictive peering policies, limiting their reach to certain networks in many places.

To be clear, using your own space doesn't guarantee global reach either.  But it gives you more flexibility, at the expense of greatly increased complexity, time, and effort.

-- 
TTFN,
patrick


> note that the term "anycast" is sometimes overloaded to mean "DNS CDN"
> where each server decides what answer to give for an A or AAAA request
> based on that server's current guess about the client's locality
> relative to various web farms. if the original question is really about
> that, then the answer will have to go beyond routing policy. (ISC does
> not do this, so my description above does not cover it.)
> 
> paul
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> 




More information about the dns-operations mailing list