Domain Name Services (DNS) and Email Delivery

Posted by: admin in Untagged  on Jun 29, 2010 Print PDF

Domain Name Services (DNS) and email delivery are closely linked services so unless DNS services are correctly configured for sending and receiving email servers, mail delivery will be broken. Please note that statement,”It takes two to tango,” absolutely and positively applies to email transfers. Seldom do customers realize that most of the time it’s not their email sever that broken, it’s the other guys server that’s the problem.

DNS services power the Internet. It was the Invention of DNS that enabled the Web, as we know it today.  I hate to admit it but I do remember when the entire world would exchange hosts files nightly. This scheme hit the wall in the early 1980s, when there were only about 10,000 hosts on the Internet. A good short history of DNS and how mail was delivered before DNS can be found at Domain Name System (DNS) History.

For every message your email server’s Message Transfer Agent (MTA) sends:

  • Since the MX record must be a hostname not an IP address, your MTA must next lookup the IP addresses for the MX servers hostnames using a DNS Record lookup.

 

You probably didn’t realize that your email server will typically make anywhere from 30 to 50 DNS lookups for every message it receives. When we examine the email delivery process we find:

  • That when the sending MTA connects to the receiving MTA, the receiving server will attempt to convert the IP address of the connecting server into a hostname using a DNS PTR record lookup.

The real DNS work is just starting. Many anti-spam detection techniques rely heavily on DNS checks:

  • To finally  deliver the message from the gateway to the mail hub may require an additional DNS A record lookup.

So if DNS services are slow, email processing will backup and if DNS services fail, email processing will stop.

If the DNS records for a specific domain are broken, email to or from that domain may not be deliverable.

Trouble-shooting DNS problems fall into two categories, your DNS services are broken or another domains DNS services are broken.

Checking your DNS services:

If mail delivery has slowed down and messages are backing up on the gateway(s). The first thing to check is if your gateways DNS services are working correctly. A few simple tests should quickly show if problems exist.

To see if DNS is working you can run a few `dig` commands. Login to your gateway as the root user and run:

dig ns fsl.com

This should return an answer similar to:

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> -t ns fsl.com

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62655

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

 

;; QUESTION SECTION:

;fsl.com.               IN    NS

 

;; ANSWER SECTION:

fsl.com.          86400 IN    NS    ns2.sgmhost.com.

fsl.com.          86400 IN    NS    ns1.sgmhost.com.

 

;; Query time: 71 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)

;; WHEN: Wed Jun 23 09:34:32 2010

;; MSG SIZE  rcvd: 69

 

If instead you get the answer

No servers could be reached

Your DNS services are not working. Try running

dig @8.8.8.8 ns fsl.com

This command uses the nameserver at IP 8.8.8.8 (google-public-dns-a.google.com). If this command succeeds, all of the nameservers listed in /etc/resolv.conf are broken and you’ll need to fix that problem to restore email services.

If email processing is slow and emails are backing up in the inbound mqueue, another useful `dig` test is to run:

time dig –t ns google.com

This should return lines similar to these after the results of the dig command:

real 0m0.027s

user 0m0.003s

sys  0m0.015s

The times returned should always be less than 1 second. If they are longer you may have a broken DSN server listed in your /etc/resolv.conf file.

Checking other domains DNS services:

There are two type DNS failures for domains that you are exchanging mail with:

  • The other domain has missing or damaged MX or DNS records
  • The other domain has incorrectly configured DNS records for the server that is sending mail for the domain.

You can easily test for missing or damaged MX or DNS records. Login to the gateway as the root user and run:

To test for Name Server (NS) records:

dig NS fsl.com

Should return records containing lines similar to:    

; <<>> DiG 9.3.4-P1 <<>> ns fsl.com

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15508

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

 

;; QUESTION SECTION:

;fsl.com.               IN    NS

 

;; ANSWER SECTION:

fsl.com.          86400 IN    NS    ns1.sgmhost.com.

fsl.com.          86400 IN    NS    ns2.sgmhost.com.

To test for MX records, run:

dig MX fsl.com       

Should return records containing lines similar to:

 

;; ANSWER SECTION:

fsl.com.          14334 IN    MX    20 gw20.safeguardmail.net.

fsl.com.          14334 IN    MX    30 gw30.safeguardmail.net.

fsl.com.          14334 IN    MX    10 gw10.safeguardmail.net.

To test for Host (A) records, run:

dig gw10.safeguardmail.net

Should return records containing lines similar to:

gw10.safeguardmail.net.    600  IN   A    67.228.190.178

To test for Pointer (PTR) records:

dig gw10.safeguardmail.net

Should return records containing lines similar to:

;; ANSWER SECTION:

gw10.safeguardmail.net. 351   IN    A     67.228.190.178

Every domain that expects to send email MUST be configured in accordance with the RFCs governing email delivery:

  •   Publish DNS Name Server (NS records)
  • Publish DNS Hostname (A) records for the IP address of every server listed as an MX record
  • Publish DNS Pointer (PTR) records for the IP address of every server that might send email for the domain. NOTE that the PTR record must only exist. It does not have to match the IP of the DNS A record for the FQDN.

If these rules are not followed, many sites can and will refuse to accept any email from that domain.

There are two other common configuration problems that are not technically DNS problems but often prevent mis-configured form sending email. RFC 2821 specifies that the sending servers response to the MTA HELO argument must be

  •   A FQDN or ip-domain literal, e.g. [67.228.190.178].
  • The FQDN must be in a Top Level Domain (TLD). Exchange.local is NOT a FQDN in a TLD.

Since the sending server typically uses its hostname to respond to the HELO prompt, if the hostname of the sending system is not a FQDN in a TLD, many email gateways will (correctly) reject any email from that server. [If you understood FQDN in a TLD, you will pass the test and are starting to speak “email”]

SPF records

DNS is used to publish Sender Policy Framework (SFP) Records. SPF DNS records provide a simple way for sites to publish the names and addresses of servers that are allowed to send email for their domain. If you receive an email from a server that’s sending mail for xyz.com and that server is not in the list of servers allowed to send mail for xyz.com you can assume the email is a forgery.

How SPF are created and used is well documented on the SFP web site so I won’t cover the details here. A wizard is even provided to help you create the SPF record for your site.

I strongly recommend that all sites publish SPF records.

When a site publishes SPF authoritative SFP records, you should block email from servers that are sending email for that domain that are not listed in the site’s SFP records.

DNSBL lookups

Wikipedia has published an excellent short article that explains how DNS-based Black Hole Lists (DSNBL) evolved, how they work and the different types of DNSBL lists that are used. It should be required reading for all email administrators.

We strongly recommend configuring BarricadeMX to use DNSBLs at the MTA level before it is accepted for delivery. Specifically we recommend using:

 

zen.spamhaus.org [Subscription Service]

bl.spamcop.net [Free]

list.dnswl.org [Free]

dbl.spamhaus.org [Subscription Service]

black.uribl.com [Subscription Service]

gold.uribl.com [Subscription Service]

Sites that are noted as [Subscription Service] above require that most sites purchase a subscription before using that DNSBL lookup service. Please see http://www.fsl.com/images/docs/readme_rbl_use_ms_sa.pdf for specific the “Terms of Use” for each site. You should not enable the BarricadeMX or BarricadeMX Plus products to use these lists unless you have a paid subscription for the list. If you do not have such subscriptions we recommend that you use the free bl.spamcop.net list and list.dnswl.org  as your DBSBL services.

If you need a subscription, you may purchase it directly from the RBL vendors but we are able to provide OEM feed Mirrors for the two vendors we recommend using, Spamhaus and URLBlacklist, with special pricing for FSL customers. If you want subscribe to either of these services please contact info@fsl.com and let us know the approximate number of email accounts that that should be covered.

If you use the services without a subscription, your access to the sites may be blocked. The symptoms of having access to the RBL sites blocked are a slowdown of email deliveries and a buildup of unprocessed messages in the incoming mail queue. If you experience any of these problems, please contact support@fsl.com as soon as possible.

Caching Name servers

To provide the most resilient DNS services possible, most sites should seriously consider stetting up a Caching Name Server to provide DNS services on their email gateways. On a Red Hat or CentOS server installing a caching name server is as simple as running:

            yum install caching-named

Then modify /etc/named.conf to set-up stub zones for any local name look-ups and modifying /etc/resolv.conf to use only 127.0.0.1 as the IP address of your name server. 

Next week.

That’s it for this week. Please send any corrections or comments directly to steve@fsl.com and I’ll post anything that relevant to the blog to try to reply directly.

 

Next weeks topic will be “When Email leaves your domain”


[ Back ]