Hi, is there any document that contrasts RFC 3974 with the real world? I try to create a set of MX RRs which includes an IPv6 MX host, does not negatively impact reachability from v4-only hosts (or v6-enabled hosts without v6 connectivity), prefers v6 over v4 when possible, and does not waste any IPv4 addresses. This is what I've come up with so far: deneb.enyo.de. 172800 IN MX 9 v6.mail.enyo.de. deneb.enyo.de. 172800 IN MX 10 v4.mail.enyo.de. v6.mail.enyo.de. 172800 IN A 212.9.189.167 v6.mail.enyo.de. 172800 IN AAAA 2001:14b0:202:1::a7 v4.mail.enyo.de. 172800 IN A 212.9.189.167 The A RR of v6.mail is necessary because some broken anti-spam checks reject mail from deneb.enyo.de if they cannot find an A record for the primary MX. The v4.mail MX host is needed because some MTAs suppress A record lookup if they discover an AAAA record (even if there's no v6 connectivity available). I wouldn't be too surprised when this setup leads to bouncing mail, too. 8-> Florian
Florian Weimer wrote:
Hi,
is there any document that contrasts RFC 3974 with the real world?
No, because that setup works perfectly well. Do you have reason to believe that it doesn't?
I try to create a set of MX RRs which includes an IPv6 MX host, does not negatively impact reachability from v4-only hosts (or v6-enabled hosts without v6 connectivity), prefers v6 over v4 when possible, and does not waste any IPv4 addresses.
Then do it like described in the above RFC.
This is what I've come up with so far:
deneb.enyo.de. 172800 IN MX 9 v6.mail.enyo.de. deneb.enyo.de. 172800 IN MX 10 v4.mail.enyo.de.
v6.mail.enyo.de. 172800 IN A 212.9.189.167 v6.mail.enyo.de. 172800 IN AAAA 2001:14b0:202:1::a7 v4.mail.enyo.de. 172800 IN A 212.9.189.167
This will (normally) never hit v4.mail.enyo.de as the SMTP client will try v6.mail.enyo.de IPv6's address, if that connect fails it will try v6.mail.enyo.de's IPv4 address. If v6.mail.enyo.de returns a 4xx then the client will try v4.mail.enyo.de, which only has an IPv4 address.
The A RR of v6.mail is necessary because some broken anti-spam checks reject mail from deneb.enyo.de if they cannot find an A record for the primary MX.
Blame the broken implementation. Not much you can do about except contacting them to fix their setup.
The v4.mail MX host is needed because some MTAs suppress A record lookup if they discover an AAAA record (even if there's no v6 connectivity available).
Then those implementations are wrong and need to be fixed. Thus simply use the following as in the RFC: deneb.enyo.de. MX 10 mx1.enyo.de. deneb.enyo.de. MX 20 mx2.enyo.de. mx1.enyo.de. A 212.9.189.167 AAAA 2001:14b0:202:1::a7 mx2.enyo.de. A <second mx's IPv4 address> AAAA <second mx's IPv6 address> Correct implementations will then first try mx1.enyo.de's IPv6 address, if the IPv6 connect fails it will try mx1's IPv4. If mx1 gives 4xx it will try mx2's IPv6, if that IPv6 connect fails it falls back to mx2's IPv4. This works flawlessly. If there is an implementation/setup that doesn't work with the above setup then contact them to let them fix it. I haven't seen any issues with setups of the above form btw and I have been running a A/AAAA setup for almost 4 years now on several domains. Also note that you might want to have more than 1 physically separated MX. If your sole machine now dies your mail will not be delivered. Having a separated MX will allow it to be directly delivered at that place and not entering queues at remote sites. Unless you loadbalance and have a 99.999999999999999% SLA on the link to the internet of course. Greets, Jeroen
* Jeroen Massar:
Florian Weimer wrote:
Hi,
is there any document that contrasts RFC 3974 with the real world?
No, because that setup works perfectly well. Do you have reason to believe that it doesn't?
Yes, real-world experiments with v6-enabled MX hosts which send and receive significant volumes of mail flatly contradict this document. The last DNS example in Section 2 breaks sender domain verification in Sendmail 8.12 (and others).
try to create a set of MX RRs which includes an IPv6 MX host, does not negatively impact reachability from v4-only hosts (or v6-enabled hosts without v6 connectivity), prefers v6 over v4 when possible, and does not waste any IPv4 addresses.
Then do it like described in the above RFC.
I did, it doesn't work.
This is what I've come up with so far:
deneb.enyo.de. 172800 IN MX 9 v6.mail.enyo.de. deneb.enyo.de. 172800 IN MX 10 v4.mail.enyo.de.
v6.mail.enyo.de. 172800 IN A 212.9.189.167 v6.mail.enyo.de. 172800 IN AAAA 2001:14b0:202:1::a7 v4.mail.enyo.de. 172800 IN A 212.9.189.167
This will (normally) never hit v4.mail.enyo.de as the SMTP client will try v6.mail.enyo.de IPv6's address, if that connect fails it will try v6.mail.enyo.de's IPv4 address.
In the world, different things happened because AAAA records can mask the existence of A records. Sure, it's a bug, but I would expect that
The A RR of v6.mail is necessary because some broken anti-spam checks reject mail from deneb.enyo.de if they cannot find an A record for the primary MX.
Blame the broken implementation. Not much you can do about except contacting them to fix their setup.
I wish publish DNS which is as conservative as possible, while still enabling IPv6. This shouldn't be impossible. If it is, we simply need some other transition mechanism. If I must choose between "SMTP over IPv6" and "reliable Internet mail", my choice is clear, and most people will share my preferences.
Then those implementations are wrong and need to be fixed.
Sure, but the ETA for that fix on real machines is mid-2007 to the end of 2008, and these estimates only deal with one piece of software (Exim in Debian). The other requirement (for interoperability, the primary MX MUST have an A record) is not amenable to a fix because it is rather widely implemented and not clearly a bug.
Thus simply use the following as in the RFC:
There are several examples in that RFC, and I've tried most of them.
deneb.enyo.de. MX 10 mx1.enyo.de. deneb.enyo.de. MX 20 mx2.enyo.de.
mx1.enyo.de. A 212.9.189.167 AAAA 2001:14b0:202:1::a7 mx2.enyo.de. A <second mx's IPv4 address> AAAA <second mx's IPv6 address>
Doesn't work, it suffers from the same AAAA-masks-A problem I mentioned.
Correct implementations
Real-world implementations behave differently, I'm afraid. And in the end, I receive my mail from real-world implementations which are not necessarily completely correct.
This works flawlessly.
No, it doesn't.
If there is an implementation/setup that doesn't work with the above setup then contact them to let them fix it.
Too many machines to fix, I'm afraid. The AAAA-masks-A bug manifests itself even if there is no working IPv6 connectivity. It has been gradually introduced to the general mail server population since mid-2004, and since June 2005, there should be a measurable number of hosts affected by it.
Hi, On Wed, Dec 21, 2005 at 02:42:24PM +0100, Florian Weimer wrote:
If there is an implementation/setup that doesn't work with the above setup then contact them to let them fix it.
Too many machines to fix, I'm afraid. The AAAA-masks-A bug manifests itself even if there is no working IPv6 connectivity. It has been gradually introduced to the general mail server population since mid-2004, and since June 2005, there should be a measurable number of hosts affected by it.
Interesting. My home DNS setup (since over a year now) looks like this: greenie.muc.de. 14m32s IN MX 5 kirk.greenie.muc.de. kirk.greenie.muc.de. 9m16s IN AAAA 2001:608:4::3 kirk.greenie.muc.de. 9m18s IN A 193.149.48.167 and I haven't had any reproduceable mail reception or delivery problems since then. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
* Gert Doering:
Hi,
On Wed, Dec 21, 2005 at 02:42:24PM +0100, Florian Weimer wrote:
If there is an implementation/setup that doesn't work with the above setup then contact them to let them fix it.
Too many machines to fix, I'm afraid. The AAAA-masks-A bug manifests itself even if there is no working IPv6 connectivity. It has been gradually introduced to the general mail server population since mid-2004, and since June 2005, there should be a measurable number of hosts affected by it.
Interesting.
My home DNS setup (since over a year now) looks like this:
greenie.muc.de. 14m32s IN MX 5 kirk.greenie.muc.de. kirk.greenie.muc.de. 9m16s IN AAAA 2001:608:4::3 kirk.greenie.muc.de. 9m18s IN A 193.149.48.167
Selective quoting. 8-) There are a couple more MX records: greenie.muc.de. 900 IN MX 15000 mx1.muc.de. greenie.muc.de. 900 IN MX 16000 mx-150.space.net. greenie.muc.de. 900 IN MX 16500 mx-200.space.net. These are IPv4-only, and they help to pamper over the AAAA-masks-A issue. If a broken Exim installation sees just this record for kirk.greenie.muc.de: kirk.greenie.muc.de. 9m16s IN AAAA 2001:608:4::3 it still falls back to the other MXes. But your experience indicates that this setup should be fairly safe (especially if you exchange mail regularly with some other site in Stuttgart which is thought to suffer from the AAAA-masks-A bug 8-).
Hi, On Wed, Dec 21, 2005 at 03:23:27PM +0100, Florian Weimer wrote:
Selective quoting. 8-) There are a couple more MX records:
greenie.muc.de. 900 IN MX 15000 mx1.muc.de. greenie.muc.de. 900 IN MX 16000 mx-150.space.net. greenie.muc.de. 900 IN MX 16500 mx-200.space.net.
Indeed.
These are IPv4-only, and they help to pamper over the AAAA-masks-A issue. If a broken Exim installation sees just this record for kirk.greenie.muc.de:
kirk.greenie.muc.de. 9m16s IN AAAA 2001:608:4::3
it still falls back to the other MXes.
So if I understand this correctly, having a v4-only backup MX should solve all problems commonly experienced? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
* Gert Doering:
So if I understand this correctly, having a v4-only backup MX should solve all problems commonly experienced?
As far as I know, the primary MX needs an A record (to satisfy Sendmail), and there needs to be a MX which has an A record only (and no AAAA or A6 record; this is done to satisfy Exim installations). My initial question to this list was whether if you can do this with just a single IPv4 address, and still prefer IPv6 over IPv4 (assuming that IPv6-capable hosts prefer IPv6 hosts over IPv4 hosts if they have the same priority).
On Wed, Dec 21, 2005 at 04:08:16PM +0100, Florian Weimer wrote:
* Gert Doering:
So if I understand this correctly, having a v4-only backup MX should solve all problems commonly experienced?
As far as I know, the primary MX needs an A record (to satisfy Sendmail), and there needs to be a MX which has an A record only (and no AAAA or A6 record; this is done to satisfy Exim installations). My initial question to this list was whether if you can do this with just a single IPv4 address, and still prefer IPv6 over IPv4 (assuming that IPv6-capable hosts prefer IPv6 hosts over IPv4 hosts if they have the same priority).
At least at uninett.no this is done with only one IPv4 address. The primary MX has both A and AAAA, and the secondary is only A, but with same IPv4 address as primary. Well, you can check mx's for uninett.no yourself. I know several sites that have both A and AAAA for all MXs. It doesn't sound safe to me, but I assume it can't be that problematic then...? Stig
On Wed, Dec 21, 2005 at 04:13:04PM +0100, Stig Venaas wrote:
On Wed, Dec 21, 2005 at 04:08:16PM +0100, Florian Weimer wrote:
* Gert Doering:
So if I understand this correctly, having a v4-only backup MX should solve all problems commonly experienced?
As far as I know, the primary MX needs an A record (to satisfy Sendmail), and there needs to be a MX which has an A record only (and no AAAA or A6 record; this is done to satisfy Exim installations). My initial question to this list was whether if you can do this with just a single IPv4 address, and still prefer IPv6 over IPv4 (assuming that IPv6-capable hosts prefer IPv6 hosts over IPv4 hosts if they have the same priority).
At least at uninett.no this is done with only one IPv4 address. The primary MX has both A and AAAA, and the secondary is only A, but with same IPv4 address as primary. Well, you can check mx's for uninett.no yourself.
I know several sites that have both A and AAAA for all MXs. It doesn't sound safe to me, but I assume it can't be that problematic then...?
Like Gert and Jeroen, we do that, and have not had complaints of failed or problematic email (and have done it for a long time). That's on a domain handling maybe 100K mails a day. -- Tim/::1
On Dec 21, Stig Venaas <Stig.Venaas@uninett.no> wrote:
I know several sites that have both A and AAAA for all MXs. It doesn't sound safe to me, but I assume it can't be that problematic then...? In my experience (linux.it and other domains, IIRC since three years) a single MX record with A + AAAA records has not caused deliverability errors for incoming nor for outgoing mail. The same applies to a domain with A and AAAA records and no explicit MX.
(I had many more troubles from broken CPMTA installs, which for some unknown reason in Italy are often configured by default to not deliver mail to domains without a MX record.) -- ciao, Marco
* Marco d'Itri:
On Dec 21, Stig Venaas <Stig.Venaas@uninett.no> wrote:
I know several sites that have both A and AAAA for all MXs. It doesn't sound safe to me, but I assume it can't be that problematic then...?
In my experience (linux.it and other domains, IIRC since three years) a single MX record with A + AAAA records has not caused deliverability errors for incoming nor for outgoing mail. The same applies to a domain with A and AAAA records and no explicit MX.
Try to get logs from master.debian.org. I'm pretty sure they will show some bounces. bugs.debian.org (= spohr.debian.org) probably has similar issues. Just because you don't know about these bounces doesn't mean they don't exist. 8-)
On Dec 27, Florian Weimer <fw@deneb.enyo.de> wrote:
Try to get logs from master.debian.org. I'm pretty sure they will show some bounces. bugs.debian.org (= spohr.debian.org) probably has similar issues. I get my spam and bugs as usual from the Debian machines, so if there is a problem it looks like it is intermittent.
-- ciao, Marco
On Wed, 21 Dec 2005, Florian Weimer wrote:
As far as I know, the primary MX needs an A record (to satisfy Sendmail), and there needs to be a MX which has an A record only (and no AAAA or A6 record; this is done to satisfy Exim installations).
Where did you get that exim needs to see at least one MX with ONLY A record? -- William Leibzon Elan Networks william@elan.net
* william elan net:
On Wed, 21 Dec 2005, Florian Weimer wrote:
As far as I know, the primary MX needs an A record (to satisfy Sendmail), and there needs to be a MX which has an A record only (and no AAAA or A6 record; this is done to satisfy Exim installations).
Where did you get that exim needs to see at least one MX with ONLY A record?
Some of the mail I sent to deneb.enyo.de through an MX running Exim bounced, and Marc Haber and I figured out that it was due to an AAAA-masks-A bug in Exim: <http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20051212/msg00196.html> Of course, this is a clear Exim bug, and no doubt it will be fixed soon in the official distribution. But it will take some time until this fix is deployed in the field, and in the meantime, I still need to receive mail from affected sites.
Hi, | So if I understand this correctly, having a v4-only backup MX should | solve all problems commonly experienced? Yes. Note that BIT has not seen any MTA problems, even though BIT may be somewhat bolder than most. We have our MX records pointing to: bit.nl mail is handled by 100 mx1.bit.nl. bit.nl mail is handled by 200 mx2.bit.nl. bit.nl mail is handled by 300 mx3.bit.nl. ... and each of these has an IPv4 and an IPv6 address. -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment -----------------------------------------------
participants (8)
-
Florian Weimer -
Gert Doering -
Jeroen Massar -
md＠Linux.IT -
Pim van Pelt -
Stig Venaas -
Tim Chown -
william(at)elan.net