rDNS entry

I'm trying to configure a mail relay server so that no upstream server will reject my traffic for whatever reason. My latest effort was to have a PTR record created on the external DNS. Checking my records on DNSstuff, I get the following:

IP address: 111.222.333.444
Reverse DNS: mail.domain.com.
Reverse DNS authenticity: [Could be forged: hostname mail.domain.com. does not exist]

The actual host is a stand-alone Windows box in a DMZ, so it's true that the above FQDN does not have a corresponding host machine. My question is, will upstream mail servers with "reverse DNS query" enabled reject my traffic because of this? If so, what's the best solution for binding the above FQDN to my stand-alone server?

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

it_consultant

RDNS for mail services is put in by your ISP. Submit a request to your ISP with the hostname and IP and they will add it for you. This generally only takes a few minutes. In order to run an email server you must do this, otherwise 60% of the email servers out there will reject your mail.

Forsaken_GA

mikedisd2 wrote: »

The actual host is a stand-alone Windows box in a DMZ, so it's true that the above FQDN does not have a corresponding host machine. My question is, will upstream mail servers with "reverse DNS query" enabled reject my traffic because of this? If so, what's the best solution for binding the above FQDN to my stand-alone server?

You don't necessarly have to have a host machine dedicated to it, but you should have a host record. Usually it's the other way around, A record but no PTR. Just configure an A record with the same info in the PTR and you should be fine. Otherwise, yes, some mail servers may reject you.

Everyone

Forsaken_GA wrote: »

You don't necessarly have to have a host machine dedicated to it, but you should have a host record. Usually it's the other way around, A record but no PTR. Just configure an A record with the same info in the PTR and you should be fine. Otherwise, yes, some mail servers may reject you.

^^ This.

Whatever the last hop when leaving your network is for SMTP traffic just needs to have DNS entries in your external DNS that match what it is giving remote systems when it connects.

So when your mail gateway says "helo mail.domain.com" to a remote server, if it does a DNS lookup to make sure the IP connecting to it matches what the helo command says it is, you need both a PTR and an A record for it. The MX record should also contain this FQDN.

You're supposed to have a unique IP for it, some stuff will give warnings if your IP resolves to more than 1 name... if it looks up the IP and gets back mail.domain.com and firewall.domain.com and www.domain.com, it'll usually still accept the message, but not be very happy about it.

it_consultant

The PTR is normally pointed to the ISP router device itself - they will have a generic rDNS (or PTR) set up by default for their management or whatever. It is easier to just to have them change it then try to match your A records with what the ISP's default is. Usually it is something ridiculously cryptic. Ask them to match it to mail.domain.com and you will see these problems melt away. The problem with matching to the ISP's default rDNS is that a lot of spam filters automatically trust "mx.domain.com" "smtp.domain.com" or "mail.domain.com" enough that they don't greylist them automatically on first connection.

Everyone

it_consultant wrote: »

The PTR is normally pointed to the ISP router device itself - they will have a generic rDNS (or PTR) set up by default for their management or whatever. It is easier to just to have them change it then try to match your A records with what the ISP's default is. Usually it is something ridiculously cryptic. Ask them to match it to mail.domain.com and you will see these problems melt away. The problem with matching to the ISP's default rDNS is that a lot of spam filters automatically trust "mx.domain.com" "smtp.domain.com" or "mail.domain.com" enough that they don't greylist them automatically on first connection.

Not if you own the address block and run your own DNS.

it_consultant

Everyone wrote: »

Not if you own the address block and run your own DNS.

I didn't think this was the situation OP was in. It sounded like a standard mail server behind a firewall kind of deal. I stand by my recommendation, it makes life a lot smoother to have your SMTP HELO match rDNS, and to have that HELO be something fairly standard.

Forsaken_GA

it_consultant wrote: »

I didn't think this was the situation OP was in. It sounded like a standard mail server behind a firewall kind of deal. I stand by my recommendation, it makes life a lot smoother to have your SMTP HELO match rDNS, and to have that HELO be something fairly standard.

Well, judging by the information in the original post, he already has rDNS set. The reverse of the DNS is showing up as mail.whatever.com, so that part is already taken care of. However, the rdns is set to an A record that does not exist, and that's where the unhappiness of the tool comes from. So he needs to define an A record for that hostname and he should be fine.

mikedisd2

Forsaken_GA wrote: »

Well, judging by the information in the original post, he already has rDNS set. The reverse of the DNS is showing up as mail.whatever.com, so that part is already taken care of. However, the rdns is set to an A record that does not exist, and that's where the unhappiness of the tool comes from. So he needs to define an A record for that hostname and he should be fine.

Sorry, was away for a few days. This ought to resolve the issue; I did ask the external DNS provider to create/update the A record but looks like he didn't. I had a few problems getting this mail route happening and don't want to prolong it any more. Thanks for all the info.

EDIT: Yeah, they didn't make the A record match the PTR. I assumed they would do the job properly.

it_consultant

Who is your DNS provider? Most let you go in and modify your A records through a portal or something.