[time-nuts] Strange reports of bocked messages to timenuts

Robert Vassar rvassar at rob-vassar.com
Fri May 23 14:41:43 UTC 2008


John,


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".


Cheers,

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  
> CNAME
> 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  
> two
> 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  
> security
> problem.
>
> Anyway, this will be fixed as soon as I have a chance.
>
> John
> ----
> 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  
>> RFCs),
>> 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  
>> "ns1.febo.com
>> reports that febo.com has an MX (meow.febo.com) which ns1.febo.com  
>> says
>> is a CNAME (to febo.com)"
>>
>> RFC1912 says:
>>
>>    Don't use CNAMEs in combination with RRs which point to other  
>> names
>>    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       1.2.3.4
>>
>>    [RFC1034] in section 3.6.2 says this should not be done, and  
>> [RFC974]
>>    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       24.123.66.139
>>
>> 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/ 
> time-nuts
> and follow the instructions there.





More information about the Time-nuts_lists.febo.com mailing list