[AusNOG] IPv6 reverse DNS and Mail ...

[Mark Smith]

>________________________________
> From: Robert Mibus <mibus at mibus.org>
>To: Mark Smith <markzzzsmith at yahoo.com.au> 
>Cc: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net> 
>Sent: Thursday, 23 May 2013 3:15 PM
>Subject: Re: [AusNOG] IPv6 reverse DNS and Mail ...
> 
>
>
>On Wed, May 22, 2013 at 7:26 PM, Mark Smith <markzzzsmith at yahoo.com.au> wrote:
>
>MTAs can be a good choice as one of the first servers to IPv6 enable when dipping your toe in the IPv6 water, as acceptable latency for email delivery can be measured in the order of minutes rather than milliseconds. If your IPv6 is broken despite your efforts, the MTA will fall back to IPv4 within 30 seconds, and then delivery will still occur. If you have end-users who don't find that acceptable, tell them they should be using Instant Messaging, rather than Percolated Messaging.
>>
>
>
>Many MTAs will *not* automatically fall back to IPv4 correctly.
>

That's unfortunate. When they were converted to support IPv6, they should have followed the implementation advice for getaddrinfo(), which is to walk through the list of returned A/AAAAs until a connection succeeds. I don't know about Windows or OS X, however under Linux, the ordering of the list can be influenced using /etc/gai.conf. Even IPv4 only applications would benefit from this, as there is no assurance that a A query will only reply with a single A RR. 

Happy eyeballs is an improvement to this technique because it is making these connection attempts in parallel rather than series. While it would still be an improvement for an MTA, as MTAs aren't low latency sensitive, unlike "eyeballs", the older sequential method would be more acceptable.

Of course, it is best to lab this stuff before deploying it into production, or at least do google searches to see if people have had trouble with your chosen MTA and IPv6 before you enable it in production.

>
>I've seen MTAs repeatedly banging only on IPv6 without falling back at all; I've seen MTAs get SERVFAIL for AAAA DNS lookups, and just keep retrying AAAA lookups rather than falling back; I've also seen MTAs trying multiple AAAA addresses on a dual-stacked DNS record, before trying any IPv4 ones.
>
>
>It's a lot better now that there are several large providers that do IPv6 MXes and MTAs, because there's a good chance that someone with a broken MTA setup will find out before you have to deal with them - but it's not all roses.
>
>
>Is it worth doing? Yes, absolutely. But there's no widely deployed "happy eyeballs"-style code for MTAs, so - like with using IP reputation - do consider the business risk in potentially not being able to get mail from random people who might email you once then move on to another vendor [or whatever the case may be in your business], and make sure you are on the lookout for potential signs of lost mail and delivery issues etc.
>
>
>My suggestion for dipping your toes in the water, are DNS servers. Enabling IPv6 on a caching resolver lets it talk to IPv6-enabled authoritative nameservers, and enabling at least some of your authoritative nameservers means your clients should be able to fall back to an alternate nameserver if they really have problems.
>

Is this a manual fall back, or are you saying that some of the resolvers in the clients list are IPv6 enabled and others aren't, and the resolver timeout takes care of falling back if IPv6 lookups fail? One of the advantages of picking something a behind the scenes service like SMTP delivery is that if there are negative effects, they won't be visible or the delays they introduce won't be all that unacceptable to the clients. DNS failures OTOH will be very visible - for interactive services, humans have a positive or negative feedback limit of around 3 to 5 seconds before they think there is a failure and will take remedial actions (like push the print button again ...)

Regards,

Mark.