[time-nuts] Strange reports of bocked messages to timenuts
rvassar at rob-vassar.com
Fri May 23 10:41:43 EDT 2008
It's not a security issue, but a load and RFC compliance issue. It's
a case of almost works but not quite.
When you have a MX record pointing at a CNAME record, you double the
load placed on the DNS servers used by other MTA's sending you
messages. Large ISP/Telco deployments often have outbound mail relay
systems cranking out 400+ msgs/second, possibly with multiple DNS
lookups per message. You can easily imagine seeing thousands of DNS
queries per second, and anything that adds load needlessly is going
to be frowned upon.
But there's more! There's this little odd property of CNAME
records. They're selfish. You cannot configure multiple records of
the same name if one is a CNAME record. So if you had configured
meow.febo.com as a CNAME, and tried to add a MX containing
meow.febo.com, you'd have no published MX record at all. I would
love to configure a SSHFP record pointing at a CNAME record for a
host that changes IP addresses regularly, but no DNS server will
return the SSHFP record if it finds a CNAME record of the same name.
There's a couple other little gotchas that don't apply here, but
that's the reason it's considered "RFC ignorant".
Rob Vassar - KC6OOM/5
On May 17, 2008, at 4:27 PM, John Ackermann N8UR wrote:
> All --
> Thanks for the information on the MX record issues. The problem
> resulted from a changed configuration a couple of years ago where we
> didn't go quite far enough in making sure that everything works --
> febo.com has been on the net since something like 1996 (the domain was
> actually registered in late 1994, but at first I used -- believe it or
> not -- uucp for the mail link), and over that time there were various
> gyrations that happened to keep DNS happy as the world changed.
> The last change was reversing things so that meow.febo.com was the
> and febo.com was the A record. We did that to address some other
> issues, and obviously forgot to change the MX record appropriately.
> I'll do that as soon as Hamvention is over...
> But what's interesting is that the error has been in place for over
> years, and this is the first time it's ever caused any problems. And
> I'm really not sure what the security implication is of an MX pointing
> to a CNAME. I can see that it could result in lower reliability by
> putting an extra link in the DNS chain, but that's not really a
> Anyway, this will be fixed as soon as I have a chance.
> Mike S said the following on 05/17/2008 10:52 AM:
>> At 06:55 AM 5/17/2008, John Ackermann N8UR wrote...
>>> I think this is some sort of weird backscatter problem; I've
>>> never seen
>>> this message before.
>>> But I've unsubscribed this joconnell person in the hopes that will
>>> stop it.
>> It will, but the root problem is at febo.com (failure to follow
>> which is resulting in message rejection and a bounce back to the
>> Reply-To: addresses (including time-nuts at febo.com).
>>>> WHY DID THIS HAPPEN ?
>>>> 550 ######## DNS RHS BLACKLIST: http://www.rfc-ignorant.org
>> If you follow the link and look up febo.com, and find that
>> reports that febo.com has an MX (meow.febo.com) which ns1.febo.com
>> is a CNAME (to febo.com)"
>> RFC1912 says:
>> Don't use CNAMEs in combination with RRs which point to other
>> like MX, CNAME, PTR and NS. (PTR is an exception if you want to
>> implement classless in-addr delegation.) For example, this is
>> strongly discouraged:
>> podunk.xx. IN MX mailhost
>> mailhost IN CNAME mary
>> mary IN A 184.108.40.206
>> [RFC1034] in section 3.6.2 says this should not be done, and
>> explicitly states that MX records shall not point to an alias
>> defined by
>> a CNAME.
>> But that is exactly what febo.com is doing:
>> dig -t MX febo.com
>> ;; ANSWER SECTION:
>> febo.com. 495834 IN MX 10 meow.febo.com.
>> dig meow.febo.com
>> ;; ANSWER SECTION:
>> meow.febo.com. 573937 IN CNAME febo.com.
>> febo.com. 193364 IN A 220.127.116.11
>> Having said that, the system which is doing the bouncing
>> (conwin.ie) is
>> brain-dead and doing something even worse - sending the bounce
>> with no
>> From: header (I assume, since my email server ends up putting a local
>> From: on it to make the message RFC legal).
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/
> and follow the instructions there.
More information about the time-nuts