This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RDNS CNAME for MX Record Issue

Okay, so I'm not sure if this is by design or if it is indeed an issue. Just encountered a third-party that's using a CNAME for their MX PTR record and the UTM (9.209-8) rejects it with "RDNS invalid".

"Dig" returns a valid response and checking their domain on various DNS validation sites, everything reports "OK" with their MX and PTR setup.

From what I can gather, it's generally considered "not the best" to use CNAMEs for MX PTR records but there also doesn't appear to be any hard and fast RFC rules that forbid it. So, on to my question; do I just deal with it and create an exception for these people or is this something that should go into a "feature request" list or is this a bug that needs to be fixed?

Thanks!


This thread was automatically locked due to age.
  • Are you talking about the PTR record of the public IP or about the MX record? These are different types.

    An MX record has to point to an A record, pointing to a CNAME is a non-standard configuration (as stated in RFC 974).

    So if you can't convince that third party to correct their DNS zone you will have to define an exception excluding RDNS check for this domain.

    ----------
    Sophos user, admin and reseller.
    Private Setup:

    • XG: HPE DL20 Gen9 (Core i3-7300, 8GB RAM, 120GB SSD) | XG 18.0 (Home License) with: Web Protection, Site-to-Site-VPN (IPSec, RED-Tunnel), Remote Access (SSL, HTML5)
    • UTM: 2 vCPUs, 2GB RAM, 50GB vHDD, 2 vNICs on vServer (KVM) | UTM 9.7 (Home License) with: Email Protection, Webserver Protection, RED-Tunnel (server)
  • Are you talking about the PTR record of the public IP or about the MX record? These are different types.


    Sorry, I guess that wasn't very clear. Their forward lookup MX record is fine; the PTR record is using a CNAME:

    ~$ dig millenniumpartners.net MX +nocomments
    

    ; <>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <>> millenniumpartners.net MX +nocomments
    ;; global options:  printcmd
    ;millenniumpartners.net.                IN      MX
    millenniumpartners.net. 7121    IN      MX      10 mail.millenniumpartners.net.
    millenniumpartners.net. 165202  IN      NS      ns87.worldnic.com.
    millenniumpartners.net. 165202  IN      NS      ns88.worldnic.com.
    mail.millenniumpartners.net. 7121 IN    A       12.226.35.115
    ns87.worldnic.com.      7121    IN      A       207.204.40.144
    ns88.worldnic.com.      7121    IN      A       206.188.198.44

    ~$ dig mail.millenniumpartners.net A +nocomments

    ; <>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <>> mail.millenniumpartners.net A +nocomments
    ;; global options:  printcmd
    ;mail.millenniumpartners.net.   IN      A
    mail.millenniumpartners.net. 6954 IN    A       12.226.35.115
    millenniumpartners.net. 165035  IN      NS      ns88.worldnic.com.
    millenniumpartners.net. 165035  IN      NS      ns87.worldnic.com.
    ns87.worldnic.com.      6954    IN      A       207.204.40.144
    ns88.worldnic.com.      6954    IN      A       206.188.198.44

    ~$ dig -x 12.226.35.115 +nocomments

    ; <>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <>> -x 12.226.35.115 +nocomments
    ;; global options:  printcmd
    ;115.35.226.12.in-addr.arpa.    IN      PTR
    115.35.226.12.in-addr.arpa. 78693 IN    CNAME   115.112-28.35.226.12.in-addr.arpa.
    115.112-28.35.226.12.in-addr.arpa. 78693 IN PTR mail.millenniumpartners.net.
    112-28.35.226.12.in-addr.arpa. 78693 IN NS      cbru.br.ns.els-gms.att.net.
    112-28.35.226.12.in-addr.arpa. 78693 IN NS      cmtu.mt.ns.els-gms.att.net.
    cbru.br.ns.els-gms.att.net. 78693 IN    A       68.94.156.132
    cmtu.mt.ns.els-gms.att.net. 78693 IN    A       99.99.99.132

    ~$ host 12.226.35.115
    115.35.226.12.in-addr.arpa is an alias for 115.112-28.35.226.12.in-addr.arpa.
    115.112-28.35.226.12.in-addr.arpa domain name pointer mail.millenniumpartners.net.
  • Yes, I would have expected that to work.  Is 'Strict RDNS' selected?  What does the SMTP log file show for one of these?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hi Bob, yes 'Strict RDNS' is selected (I already had some internal debate on that topic due to the overwhelming amount of ill-informed admins out there; not that RDNS is the end-all be-all of anti-spam measures, but that's another discussion. When 68% of your inbound mail is spam and 18% of that is stopped by RDNS checks, every little bit helps as far as I'm concerned).

    The log just shows 'extra="RDNS invalid"' and 'Invalid RDNS entry for 12.226.35.114':

    /var/log/smtp.log:2014:11:18-12:56:53 pututmp01 exim-in[22430]: 2014-11-18 12:56:53 id="1003" severity="info" sys="SecureMail" sub="smtp" name="email rejected" srcip="12.226.35.114" from="foo.bar@millenniumpartners.net" to="foo.bar@putnam-fl.com" size="7360" reason="rdns_helo" extra="RDNS invalid"
    
    /var/log/smtp.log:2014:11:18-12:56:53 pututmp01 exim-in[22430]: 2014-11-18 12:56:53 H=(mail.millenniumpartners.net) [12.226.35.114]:36609 F= rejected RCPT : Invalid RDNS entry for 12.226.35.114
    /var/log/smtp.log:2014:11:18-12:56:53 pututmp01 exim-in[22430]: 2014-11-18 12:56:53 SMTP connection from (mail.millenniumpartners.net) [12.226.35.114]:36609 closed by DROP in ACL


    So like I said, I'm not sure if it's just the fact that the UTM doesn't like the CNAME and/or whether or not this should be a bug report or a feature request or something else.

    Thanks!
  • I believe that this should have passed the RDNS test, and that it did in the past, so I would make an Exception and submit this to Sophos Support.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Thanks Bob, I'll get a ticket open today. I did dig through the older logs and apparently this hasn't ever worked as this particular firm first tried to send email into us just on Nov. 17.