While that setup may have worked well, it's not an anycast implementation I would suggest that others follow. Having the same set of servers announcing multiple IP addresses (assuming those addresses are both in the same set of addresses given out to those doing dns lookups) leaves you open to a failure mode where a single server stops responding to queries but doesn't withdraw its routing announcement. If a user sees that server as the closest instance of both DNS server IP addresses, they will see that as a failure of "both" of their DNS servers.

Agreed, that's a possibility. In practice it hasn't really turned out to be a problem for us.

A more reliable way of doing this is to have multiple anycast clouds with their own servers, each serving a single service address. That way, an incomplete failure (on query response but no route withdrawl) of a local server for one service address won't have any effect on access to the second service address.

Yes, we have been doing some of this also. Part of the problem is the desire to spread the load among the servers: Some of this comes naturally from the different server locations in our network - but with 2 addresses per server we can also balance the load somewhat by announcing either one or two addresses per server. Steinar Haug, Nethelp consulting, sthaug@nethelp.no