Public DNS Setup

 Print E-mail
User Rating: / 0
PoorBest 

Inaccurate or incomplete public Domain Name Service (DNS) records are one of the biggest causes for email to not be received by its intended recipient.

For the purposes of this document “local domain” refers to any domain that you wish the SpammerTrap to RECEIVE email for. “Remote domain” refers to any domain or sender that is trying to send an email to you, through the SpammerTrap.

Symptoms

  • Email is being rejected by 1 or more remote domains.
  • Email is not being received by 1 or more local domains.

Cause

Mail Exchanger (MX) records not defined for local domain(s).
  • Forward and/or reverse DNS records not defined for mailserver/SpammerTrap. This includes A/Host record and PTR records for any public mailserver that will send or receive email.
  • Local domain is on a blacklist.

Solution

  • The first step in solving the puzzle will be to verify that all the public DNS records for your domain, as they relate to email, are accurate. In order to verify these settings, we will step you through a typical setup.
  • The following example assumes the following:
  • SpammerTrap deployed inside LAN with private IP address.
  • SpammerTrap is the first email gateway for incoming mail, which is then filtered and delivered to local Exchange server.
  • Exchange server is configured to send outbound email through the SpammerTrap (see smart host). SpammerTrap is the mailserver that is sending all the email to remote domains.
  • The local domain we want to receive email for is "spammertrap.com."
  • Border firewall has been configured to translate all traffic from the public IP or 204.89.241.173 to the SpammerTraps internal IP of 192.168.0.5.
  • SpammerTraps public hostname is mail.spammertrap.com. Note that your public and internal hostnames can be identical or different; it's your choice, but needs to be configured in the networking page of the SpammerTrap.


The first step is to locate your public DNS servers, if you don’t already know what they are. This can be done using the nslookup tool but is much easier to check using domaintools.com. goto the following webaddress http://whois.domaintools.com and enter the domain name you want to check. For this example we will type spammertrap.com and push the lookup button. Scroll down to the "Registry Data" section and to the Name Server listings. It is normal to see more than one name server listed, but you only need to know one of them to do the following checks. We will use the first name server listed, ns2.secnap.net.

Now that we know the public name server for our domain, we will begin to manually check the records it has for us.

Check the public MX record

  1. Open a command prompt and type nslookup then press return
  2. At the > prompt, enter your public DNS server, for this example we will type server ns2.secnap.net and hit return.
  3. Type set type=mx then press return.
  4. Enter the domain name, for example type spammertrap.com and hit return.
  5. The public DNS server returns any MX records for the requested domain. In this case we see a primary MX of fl.us.spammertrap.net and a secondary MX of pa.us.spammertrap.net.

At lease one public MX MUST exist in order for you to receive email to that domain. If you do not have a record see the section "Adding Public DNS Records" towards the bottom.

Check your MX record for integrity

This must be done for EACH of the MX records listed in the previous step.

  1. Open a command prompt and type nslookup then press return
  2. At the > prompt, enter your public DNS server, for this example we will type server ns2.secnap.net and hit return.
  3. Type name of the MX listed in the previous step, for this example we will type fl.us.spammertrap.net and hit return. We see that the hostname "fl.us.spammertrap.net" has a forward DNS record of "204.89.241.173." Also note that our MX record is not a CNAME or alias. This would not comply with the email RFC's. The next step will be to check for a matching reverse DNS or pointer (PTR) record.
  4. Type the IP address you received in step 3, for this example we will type 204.89.241.173 and press return. We see that the IP address of "204.89.241.173" has a reverse DNS record of "fl.us.spammertrap.net." This record matches.
  5. All public mail servers that either send or receive email but have complete DNS records with forward and reverse entries as we see in the example above.

 

Check what IP your mail is coming from

Just because you have all the proper DNS records above does not mean you're free and clear now. It may be very possible that email leaving your organization is using the generic NAT pool IP address and not the IP address of the mail server. For example, traffic from the outside coming to 204.89.241.173 is translated to the internal IP of 192.168.0.5, but traffic coming from the internal IP of 192.168.0.5 is translated to the public IP of the generic pool, 204.89.241.1 for example.

The only way to verify for sure where your emails are coming from is to send an email to an outside recipient and look at the message headers. For this example we will send an email to a test account at yahoo.com. When the message is received open the message, and view the full message headers. For assistance in doing this, consult your email provider's help section (yahoo support in this instance). The header lines you are looking for will look like this:
Received: from
You want to look for the Received line that contains your SpammerTraps hostname, it is usually the second form the last Received line. For this example lets assume it looks like this:
Received: from fl.us.spammertrap.net (fl.us.spammertrap.net [204.89.241.173])
In this example we can 100% verify that email coming out of our domain is coming from the IP address 204.89.241.173. It is not an RFC requirement that email be sent out from the same IP as it comes in, but conventions are that way. If your email leaves your organization from a different IP, then it also must meet the DNS requirements found in the "Check DNS integrity" section.

Check if you have been blacklisted

Another reason you may not be able to send to some domains is because your mail server or entire netblock has been blacklisted. Email blacklists are not regulated by anyone and anyone can create a blacklist. There are several sites that can give you this information. www.dnstools.com is one of the larger ones, however they require a login to use their service now.

Adding DNS Records

Your company's public DNS records will be maintained by you, or your registrar.
If you maintain your own records than you already know how to add/change them, or know who does. If you don't know who maintains the records it's probably your registrar. Give them a call and explain to them what you are trying to do and they should be able to help you.

Keep in mind that public DNS records, once updated, can take as much as 7 days to replicate worldwide. So just because you fixed your DNS 1 hour ago does not mean that the problems you were previously experiencing will go away. You may have to wait for the maximum scavenging period and/or get yourself removed from any blacklists you were listed on due to having improper DNS records.

More Information
DomainTools – http://whois.domaintools.com
RFC 1035 - http://www.faqs.org/rfcs/rfc1035.html
RFC 2181 - http://www.faqs.org/rfcs/rfc2181.html
RFC 3030 - http://www.faqs.org/rfcs/rfc3030.html
nslookup manual page - http://nest.cs.uiowa.edu/22C178s98/manpage/nslookup.html

 
supercilious
supercilious
supercilious
supercilious