Anycast provider for SMTP?

[jabley at hopcount.ca (Joe Abley)]

On 18 Jun 2015, at 7:51, Ray Soucy wrote:

> You can certainly do anycast with TCP, and for small stateless 
> services it
> can be effective.  You can't do anycast for a stateful application 
> without
> taking the split-brain problem into account.

It's really difficult to apply broad "can" or "can't", "works" or 
"doesn't work" advice here since there really are no absolutes. What 
works and what doesn't depends on the intersection between theory and 
practice (including other peoples' networks), and is broader than the 
architectural decision to use or not use anycast.

The text I pasted much earlier from RFC 4786 was a result of a lot of 
discussion (and more than a handful of objections to our attempts to 
answer this question, and to the document as a whole existing at all).

In the general, mathematical sense, it's never safe to use anycast with 
TCP; "safe" here means "entirely safe in all circumstances". Since we 
live on the Internet, we know nowhere is safe, so this answer is 
unsatisfying and doesn't help us make real-world decisions.

In the pragmatic, throw it at the wall and see what sticks sense, it's 
usually fine to use anycast with TCP; "usually" means things like 
"pretty sure I remember this working just fine at my last job" and "in 
our very particular situation the helpdesk phone didn't seem to ring". 
There's usually very little science attached to this answer, either in 
terms of comprehensive data about failures or in terms of characterising 
the precise environment and considering the ways in which it is similar 
or dissimilar to others.

If anycast is being considered as part of a solution to a particular 
problem, we might consider an answer of the form "anycast, when it 
works, is expected to solve that problem; anycast might introduce new 
problems, though, so we also need to think about a fall-back to a 
situation where the old problems are reintroduced but the new ones are 
gone". This kind of fudges around the difficulty in confidently 
enumerating all the new problems with an anticipation that anycast will 
work enough of the time to make it worth using at all.

So, in the example at hand, using an MX RRSet that tries first to 
deliver to an SMTP service that is distributed using anycast but will 
fall back to SMTP service that is not might be a reasonable approach, 
e.g.

$ORIGIN QUIRKAFLEEG.ORG.

@  MX 10 ANY.MX   ; service provided at DEFRA, NLAMS, USIAD, HKHKG
    MX 20 DEFRA.MX ; service provided just at DEFRA
    MX 20 NLAMS.MX ; service provided just at NLAMS
    MX 20 USIAD.MX ; service provided just at USIAD
    MX 20 HKHKG.MX ; service provided just at HKHKG.

so a client will first attempt to deliver to ANY.MX.QUIRKAFLEEG.ORG, and 
if that fails we'll try one of the others.

For this particular question I still think that geoip/dns is a more 
straightforward approach, since it avoids the possible timeout and retry 
behaviour of the client that might delay delivery of mail in the event 
that the anycast MX is unavailable.


Joe