Reverse DNS mismatch

[Bob]

Hello.

Im running 5.3.13 on windows, 32 bit. Every once in a while I check my
server against mxtoolbox, an today I found SMTP reverse DNS mismatch.
My WAN IPV4 address is correct under settings/network showing my correct
external ip address. Do I need to change something else?

Everything seems to work, just pretty slowly (more on that later) :)

Thanks for any tips.
Bob


#############################################################
This message is sent to you because you are subscribed to
the mailing list <CGat...@mail.stalker.com>.
To unsubscribe, E-mail to: <CGateP...@mail.stalker.com>
To switch to the DIGEST mode, E-mail to <CGatePr...@mail.stalker.com>
To switch to the INDEX mode, E-mail to <CGatePr...@mail.stalker.com>
Send administrative queries to <CGatePro...@mail.stalker.com>

[Bill Cole]

On 4 Apr 2014, at 9:28, Bob wrote:

> Hello.
>
> Im running 5.3.13 on windows, 32 bit. Every once in a while I check
> my server against mxtoolbox, an today I found SMTP reverse DNS
> mismatch. My WAN IPV4 address is correct under settings/network
> showing my correct external ip address. Do I need to change something
> else?
>
> Everything seems to work, just pretty slowly (more on that later) :)
>
> Thanks for any tips.

I don't track all of the details of MXToolbox's tests, but a few things
seem likely to be causing trouble for maxboostracing.com:

1. 2 MX records pointing to different names that resolve to the same IP
is odd and pointless.
2. Using DynDNS isn't necessarily unwise for a domain that handles
email, but if your address is actually dynamic, it's going to create
problems, especially given (1) and the potential for DNS caches with
operationally stale but unexpired A records.
3. Putting any machine engaging in any form of SMTP behind a device that
performs malicious attacks on basic SMTP functionality (such as Cisco's
PIX/ASA assault on SMTP that they ridiculously refer to as "fixup") is
always a bad idea.
4. If you run a mail server using a public IP whose PTR resolves to a
name in a domain that you don't control and is obviously constructed
from the IP address you will have chronic delivery problems, some of
them silent.

[bob]

Hi Bill, thanks for your reply. See below inline:

On 4/4/2014 11:09 AM, Bill Cole wrote:
> On 4 Apr 2014, at 9:28, Bob wrote:
>
>> Hello.
>>
>> Im running 5.3.13 on windows, 32 bit. Every once in a while I check
>> my server against mxtoolbox, an today I found SMTP reverse DNS
>> mismatch. My WAN IPV4 address is correct under settings/network
>> showing my correct external ip address. Do I need to change something
>> else?
>>
>> Everything seems to work, just pretty slowly (more on that later) :)
>>
>> Thanks for any tips.
>
> I don't track all of the details of MXToolbox's tests, but a few
> things seem likely to be causing trouble for maxboostracing.com:
>
> 1. 2 MX records pointing to different names that resolve to the same
> IP is odd and pointless.

If I do an nslookup on my domain I do see the address be resolved
correctly. I also see it time out 3 times first though, But I might
blame local resolvers for that? Where do you see that issue?

> 2. Using DynDNS isn't necessarily unwise for a domain that handles
> email, but if your address is actually dynamic, it's going to create
> problems, especially given (1) and the potential for DNS caches with
> operationally stale but unexpired A records.

The IP address is static, so I dont have to worry about that I would assume.

> 3. Putting any machine engaging in any form of SMTP behind a device
> that performs malicious attacks on basic SMTP functionality (such as
> Cisco's PIX/ASA assault on SMTP that they ridiculously refer to as
> "fixup") is always a bad idea.

This is behind a Cisco ASA. Hmmm.. I definitely have the inspect
statement there. You saying i should remove the ESMTP line?

policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect ip-options
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
inspect pptp

> 4. If you run a mail server using a public IP whose PTR resolves to a
> name in a domain that you don't control and is obviously constructed
> from the IP address you will have chronic delivery problems, some of
> them silent.

From what I can see, the PTR record points directly at my outside IP
address, on the domain I do control. Im pretty sure that is correct but
then again Im not sure of much when it comes to dns stuff :)

Thank you again for your response, I really appreciate it.
Bob

[bob]

by the way, these are the errors Im seeing. That 15 second transaction
time is what Im seeing when I hit "send" on an email and Im out of the
office. It sits on my desktop for 15 seconds, then does eventually send:

http://maxboostracing.com/dns.bmp


Bob

On 4/4/2014 11:09 AM, Bill Cole wrote:

[rw...@ropeguru.com]

In regard to the "Transaction Time" issue. There is an option under
SETTINGS:MAIL:SMTP:RECEIVING to Delay Prompt for non-client senders.
Mine is set to 0. COuld it be that it is set on yours and for some
reason when you are out of the office and sending from a remote
location, CommuniGate is not seeing you as a client and that option
has a delay set?

Robert

[bob]

I just went to that section and it is set to 0 sec. what determines if
Im a 'client' or not?

Bob

[Nicolas Hatier]

"#1. 2 MX records pointing to different names that resolve to the same IP is odd and pointless. "

> dig maxboostracing.com mx
;; ANSWER SECTION:
maxboostracing.com.     21475   IN      MX      10 mx1.maxboostracing.com.
maxboostracing.com.     21475   IN      MX      10 mx2.maxboostracing.com.

> dig mx1.maxboostracing.com A
mx1.maxboostracing.com. 43200   IN      A       68.15.54.108

> dig mx2.maxboostracing.com A
mx2.maxboostracing.com. 43200   IN      A       68.15.54.108

You could remove both MX records completely, as maxboostracing.com resolves to 68.15.54.108 too. You can also remove the A record for mx1 and mx2


"#2 Using DynDNS isn't necessarily unwise ..."
OK if the IP is really static, though you could use a DNS provider that sounds less dynamic.


"#3. Putting any machine engaging in any form of SMTP behind a device that performs malicious attacks on basic SMTP functionality [...] is always a bad idea"

> telnet 68.15.54.108 25
Trying 68.15.54.108...
Connected to 68.15.54.108.
[...wait...]
220 maxboostracing.com ESMTP CommuniGate Pro 5.3.13

For me it now looks OK, you probably removed the ESMTP line from the PIX.


"#4. If you run a mail server using a public IP whose PTR resolves to a name in a domain that you don't control and is obviously constructed from the IP address you will have chronic delivery problems, some of them silent. "

> dig -x 68.15.54.108
;; ANSWER SECTION:
108.54.15.68.in-addr.arpa. 21599 IN     PTR     wsip-68-15-54-108.ri.ri.cox.net.

Here you have a problem. The PTR must be maxboostracing.com or something.maxboostracing.com. Since your IP is static, ask your ISP to provide you a valid PTR record. You usually cannot set that up yourself, and certainly not in your own DNS server.



Nicolas Hatier

[bob]

Hi Nicolas thank you! More info inline.

On 4/4/2014 12:26 PM, Nicolas Hatier wrote:

"#1. 2 MX records pointing to different names that resolve to the same IP is odd and pointless. "

> dig maxboostracing.com mx
;; ANSWER SECTION:
maxboostracing.com.     21475   IN      MX      10 mx1.maxboostracing.com.
maxboostracing.com.     21475   IN      MX      10 mx2.maxboostracing.com.

> dig mx1.maxboostracing.com A
mx1.maxboostracing.com. 43200   IN      A       68.15.54.108

> dig mx2.maxboostracing.com A
mx2.maxboostracing.com. 43200   IN      A       68.15.54.108

You could remove both MX records completely, as maxboostracing.com resolves to 68.15.54.108 too. You can also remove the A record for mx1 and mx2

OK I just deleted those records.

"#2 Using DynDNS isn't necessarily unwise ..."
OK if the IP is really static, though you could use a DNS provider that sounds less dynamic.


"#3. Putting any machine engaging in any form of SMTP behind a device that performs malicious attacks on basic SMTP functionality [...] is always a bad idea"

> telnet 68.15.54.108 25
Trying 68.15.54.108...
Connected to 68.15.54.108.
[...wait...]
220 maxboostracing.com ESMTP CommuniGate Pro 5.3.13

For me it now looks OK, you probably removed the ESMTP line from the PIX.

Yes, I did remove the inspect statement. :) When I connect as you did, I still get that 15 second wait.

"#4. If you run a mail server using a public IP whose PTR resolves to a name in a domain that you don't control and is obviously constructed from the IP address you will have chronic delivery problems, some of them silent. "

> dig -x 68.15.54.108
;; ANSWER SECTION:
108.54.15.68.in-addr.arpa. 21599 IN     PTR     wsip-68-15-54-108.ri.ri.cox.net.

Here you have a problem. The PTR must be maxboostracing.com or something.maxboostracing.com. Since your IP is static, ask your ISP to provide you a valid PTR record. You usually cannot set that up yourself, and certainly not in your own DNS server.

Aha.. thank you, I will try to email them and get that set up. Its cox, so I can imagine how that will go!
Thank you so much!
Bob

[Bill Cole]

On 4 Apr 2014, at 11:22, bob wrote:

> Hi Bill, thanks for your reply. See below inline:
>
>
> On 4/4/2014 11:09 AM, Bill Cole wrote:
>> On 4 Apr 2014, at 9:28, Bob wrote:
>>
>>> Hello.
>>>
>>> Im running 5.3.13 on windows, 32 bit. Every once in a while I check
>>> my server against mxtoolbox, an today I found SMTP reverse DNS
>>> mismatch. My WAN IPV4 address is correct under settings/network
>>> showing my correct external ip address. Do I need to change
>>> something else?
>>>
>>> Everything seems to work, just pretty slowly (more on that later) :)
>>>
>>> Thanks for any tips.
>>
>> I don't track all of the details of MXToolbox's tests, but a few
>> things seem likely to be causing trouble for maxboostracing.com:
>>
>> 1. 2 MX records pointing to different names that resolve to the same
>> IP is odd and pointless.
>
> If I do an nslookup on my domain I do see the address be resolved
> correctly. I also see it time out 3 times first though, But I might
> blame local resolvers for that?

Almost certainly. If you were not using Windows, I'd say that was the
result of 3 non-functional nameservers listed in /etc/resolv.conf ahead
of a working resolver and/or unwise timeout & retry settings. On
Windows, I have no idea what the equivalents would be except that it is
somewhere in your DNS settings.

> Where do you see that issue?

I *was* seeing it in the MX records for maxboostracing.com which pointed
to mx1.maxboostracing.com and mx2.maxboostracing.com, both of which had
A records pointing to the same IP. Those have vanished now (with a SOA
serial that has incremented by 4) and there's just an A record for
maxboostracing.com, which should work but would be problematic if you
wanted to split your web and mail servers to different IP's. Some people
might warn you against reliance on the fallback to the A record in the
absence of an MX, but it should not be a major issue.

>> 2. Using DynDNS isn't necessarily unwise for a domain that handles
>> email, but if your address is actually dynamic, it's going to create
>> problems, especially given (1) and the potential for DNS caches with
>> operationally stale but unexpired A records.
>
> The IP address is static, so I dont have to worry about that I would
> assume.

Right. If your address actually changed often you'd be stuck between
keeping your DNS accurate and spam detection tools that see short TTL's
as shady.

>
>> 3. Putting any machine engaging in any form of SMTP behind a device
>> that performs malicious attacks on basic SMTP functionality (such as
>> Cisco's PIX/ASA assault on SMTP that they ridiculously refer to as
>> "fixup") is always a bad idea.
>
> This is behind a Cisco ASA. Hmmm.. I definitely have the inspect
> statement there. You saying i should remove the ESMTP line?

Yes. I suspected the ASA because I did manual SMTP connections to your
server and saw that it had a delayed & mangled banner and mangled
response to EHLO. The fact that Cisco still offers this horrible
misfeature despite a decade of grotesque failures calls into question
their competence to proxy *ANY* higher-layer protocol. Aside from the
mostly trivial banner issues, the EHLO reply mangling makes secure
transport of mail into your server impossible because there's no
"STARTTLS" announcement there. Everything is sent in unencrypted.

>> 4. If you run a mail server using a public IP whose PTR resolves to a
>> name in a domain that you don't control and is obviously
>> constructed from the IP address you will have chronic delivery
>> problems, some of them silent.
>
> From what I can see, the PTR record points directly at my outside IP
> address, on the domain I do control. Im pretty sure that is correct
> but then again Im not sure of much when it comes to dns stuff :)

A PTR record isn't for a domain, it's for an IP address. That's why it
is often referred to as "Reverse DNS". Having a PTR for your domain is
useless. The PTR that counts is for the IP, which is resolved by
reversing the octets and tacking on 'in-addr.arpa' (which "dig does for
me with a "-x" here):

$ dig -x 68.15.54.108

; <<>> DiG 9.9.4-P2 <<>> -x 68.15.54.108
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22972
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;108.54.15.68.in-addr.arpa. IN PTR

;; ANSWER SECTION:
108.54.15.68.in-addr.arpa. 77523 IN
PTR wsip-68-15-54-108.ri.ri.cox.net.

;; AUTHORITY SECTION:
54.15.68.in-addr.arpa. 77522 IN NS ns1.coxmail.com.
54.15.68.in-addr.arpa. 77522 IN NS ns2.coxmail.com.

;; ADDITIONAL SECTION:
ns1.coxmail.com. 77523 IN A 68.1.16.109
ns2.coxmail.com. 77523 IN A 68.111.106.70

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Apr 04 13:14:38 EDT 2014
;; MSG SIZE rcvd: 178


Having forward (A) and reverse (PTR) DNS that is perfectly symmetrical
is not mandatory and is often a poor fit for how an address is actually
used, but having a PTR name that makes you look like "Just Another
Random Anonymous Cox Customer" makes many mail systems very dubious of
your mail's legitimacy. Any random spammer can set up forward DNS
pointing to any IP, but only entities with formally allocated IP space
(or their customers to whom they delegate zones under .in-addr.arpa) can
make the PTR for an IP address resolve to an expressive name.
Incoherence between the name claimed in SMTP by the user of an IP
address (you) and the name assigned to it by the IP's registered owner
(Cox) is a strong hint that the machine using that IP has been hijacked
by a spambot. That's obviously not a perfect test, but the correlation
is so strong that many people are perfectly willing to handle the
exceptions on a special-case basis.

Simple bottom line: talk to Cox about getting that PTR fixed to point to
a name of your choosing (probably maxboostracing.com). You can't fix it
without their help.

[Bill Cole]

On 4 Apr 2014, at 11:27, bob wrote:

> by the way, these are the errors Im seeing. That 15 second transaction
> time is what Im seeing when I hit "send" on an email and Im out of the
> office. It sits on my desktop for 15 seconds, then does eventually
> send:
>
> http://maxboostracing.com/dns.bmp

See my prior reply for some background babble, but here are the
expansion of those 3 warnings in order:

1. The first thing a SMTP server sends when a sender connects is the
"banner" which is supposed to start with "220 " and the domain name by
which the server knows itself. The first time I looked this morning,
your banner was nothing but "220 " and a string of asterisks, a telltale
sign of Cisco stupidity. The second time it included
"maxboostracing.com" but of course that's not what Cox's PTR ("Reverse
DNS") says is the hostname of that IP address. No sane mail software
actually changes its behavior in a significant way based on mismatches
of the banner name with anything else, but I guess MXToolbox likes
having things to scold about. More charitably, their checking this did
lead you to investigate and learn about actually significant issues
(i.e. Cisco SMTP violence and getting a pretty PTR) so it isn't a bad
thing to note.

2. If you have enabled TLS (often referred to by its ancestral name
"SSL") and loaded an expensive server certificate (or even a test
freebie) into CGP, it is useless for receiving or sending email because
Cisco doesn't think anyone should ever have email transport privacy.
That's just one of the things they intentionally break when you let an
ASA or PIX massage SMTP. "Evil or stupid?" is a question whose answer no
longer matters, because they've been doing this in the face of
widespread unalloyed ridicule for over a decade.

3. My check and those by others here concur: your banner is slow to
appear after connecting. 15s isn't really as bad as MXToolbox indicates,
because senders are supposed to wait a minimum of 5 minutes for the
banner and even in this age of rampant discarding of SMTP standards a
timeout shorter than a minute is very rare. On the other hand, many
spambots don't bother waiting for a banner at all and will start sending
SMTP commands almost instantly after connecting, which makes an
intentional banner delay of up to 5 seconds very useful for identifying
them. Since you've said you don't have a delay set in CGP, this may be a
consequence of Cisco interference or it may be due to the same thing
that is causing your nslookup delays. CGP modifies the content of its
banner based on whether it deems a connection to be from a "client IP"
and that is dependent on "round trip" (IP->name->IP) DNS if you've told
CGP to detect clients by name.

[Juergen P. [core]]

hi,

One or more SOA fields are outside recommended ranges. Values that are out of specifications could cause delays in record updates or unnecessary network traffic. The SOA fields out of range are:

mname | ns1.mydyndns.org. | expire | 604800 | EXPIRE - RFC1912 suggests a value between 1209600 to 2419200.

No MX records exist within the zone. This is legal, but if you want to receive E-mail on this domain, you should have MX record(s).

check the syntax.

kr

on that domain some n Fri, 04 Apr 2014 11:09:55 -0400

--

Best Regards

Juergen Paulhart

VoIP / SIP / IM / E-Mail : juer...@core.at

TEL: +43 676 30 592 44  

VoIP Support:  +43 1 236 46 60 600

https://www.core.at

***  IT Security, Cloud based Communication Technologies & Hosted Unified Communications ***

  thug nature  <<<

[Bill Cole]

On 5 Apr 2014, at 6:54, Juergen P. [core] wrote:

> hi,
>
>
>
> One or more SOA fields are outside recommended ranges. Values that are
> out of specifications could cause delays in record updates or
> unnecessary network traffic. The SOA fields out of range are:
>
> mname | ns1.mydyndns.org. | expire | 604800 | EXPIRE - RFC1912
> suggests a value between 1209600 to 2419200.

It is ridiculous to treat operational advice in RFC1912 from 1996 (a
year before the invention of dynamic DNS updates) which was only ever
relevant to how authoritative servers interact to modern DNS
configuration. The "EXPIRE" value has no function outside of the
secondary authoritative servers for a zone, so it is crazy to try to
validate its published value.

> No MX records exist within the zone. This is legal, but if you want to
> receive E-mail on this domain, you should have MX record(s).

If a domain would have a single MX resolving to a name with a single A
for the bare domain name or which resolves to the same IP as the single
A for the bare domain, the MX is functionally useless. Treating the lack
of an MX for a domain which has a single A record as problematic for
mail in any way is technically invalid and extremely rare.

[Juergen P. [core]]

bill, 

maybe  i'm crazy and say ridiculous things but dnstool tester programs online,  checkup tools(old and new - means form this century ), dig, and other software  still do that tests.

furthermore i posted the results of my preferred dns tester -  i dont have that much time searching for all corresponding rfc's for each case.

 If a domain would have a single MX resolving to a name with a single A for the bare domain name or which resolves to the same IP as the single A for the bare domain, the MX is functionally useless. Treating the lack of an MX for a domain which has a single A record as problematic for mail in any way is technically invalid and extremely rare.

mx records are never useless. thats why intelligent dns-servers translates default records also to MX and send them to the querying host.

if you dont enter an mx-record it means not that it is not used by the dns-server serving your domain.

sorry that i was too fast and did not mention what was/is technically possible and what not because i thought you need a solution.

SUMMARY:

PTR record is not correct:

68.15.54.108 resolves to wsip-68-15-54-108.ri.ri.cox.net

SOLUTION:

let your provider change the PTR config.

i suggest using a hostname and adopt dns to serve that.

i still suggest using MX records because its easier for non-experts like me to reproduce some errors.

if you want to be on the safe side you should also have a look at the following problems:

your certificate chain for https is not correct.

SOA Expire Value out of recommended range 

you dont have any valid SPF/TXT records

there are some TLS-Issues

regards

[Nicolas Hatier]

The 15 seconds wait can come from CGP settings.
Settings / Mail / SMTP / Receiving / Delay Prompt for...

NH

[Tom Rymes]

On 04/04/2014 12:26 PM, Nicolas Hatier wrote:

<snip>

> /"#2 Using DynDNS isn't necessarily unwise ..." /

> OK if the IP is really static, though you could use a DNS provider that
> sounds less dynamic.

<snip>

I won't weigh in on the rest of this thread, as other, more learned
folks already have. However, I thought I should take a moment to correct
a misconception about Dyn (formerly DynDNS). Although Dynamic DNS is
where this company got its start, it has grown far, far beyond that, and
seems to specialize in some pretty advanced DNS, mail delivery, and
other products. In other words, having Dyn pop up as a DNS provider may
or may not indicate anything to do with a dynamic IP.

Having said that, someone pointed out that the OP's domain is delegated
to ns1.mydyndns.org, which is a deprecated delegation. The OP should log
into his Dyn account and review the delegation settings there and update
them to what they should be. A pretty large warning will be fairly
obvious when logged in to the portal.

Tom

[Tom Rymes]

On 04/05/2014 1:51 PM, Bill Cole wrote:

<snip>

> If a domain would have a single MX resolving to a name with a single A
> for the bare domain name or which resolves to the same IP as the single
> A for the bare domain, the MX is functionally useless. Treating the lack
> of an MX for a domain which has a single A record as problematic for
> mail in any way is technically invalid and extremely rare.

I'm sure you're right, Bill, but it could just as easily be stated that,
while an MX is not strictly required, it is essentially cost-free and
may be useful in some circumstances, even if only for broken
implementations. Or have I missed something?

Tom