RXN Logo RXN Doodle
| Home | Services | Chemistry | Materials | Elements | Help |
RXN Communications offers Domain Name System (DNS) services to RXN customers in the form of RXN DNS Service. The following are answers to Frequently Asked Questions (FAQ) about DNS services. Please direct any additional questions you may have to support@rxn.com .

RXN DNS FAQ - Q uestion and A nswer Table of Contents:


1. What is DNS?
2. How can I learn more about DNS?
3. What is BIND?
4. How can I learn more about BIND?
5. How do I setup an Virtual Domain with RXN DNS Service?
6. How do I configure DNS to support Email Validation?

7. Return to the Previous Menu.
8. Return to the RXN Communications Home Page.

Q 1. What is DNS?
A "The Domain Name System (DNS) is a hierarchical, distributed method of organizing the name space of the Internet. The DNS administratively groups hosts into a hierarchy of authority that allows addressing and other information to be widely distributed and maintained. A big advantage to the DNS is that using it eliminates dependence on a centrally-maintained file that maps host names to addresses." --from RFC 1325 - Answers to Commonly asked New Internet User Questions.

$Id: 1,v 1.1 1999/11/26 06:40:58 rjd Exp $

^ Return to DNS FAQ Table of Contents
   
Q 2. How can I learn more about DNS?
A More can be learned about DNS through supporting web sites:
Internet Software Consortium BIND
DNS Resources Directory
Domain Name System FAQ - Part 1
Domain Name System FAQ - Part 2
Langfeldt's Linux DNS HOWTO
Online DNS tools are available at the following sites:
DNS Tools by Paul Balyoz
DNS tools at SamSpade.org
Additionally, a number of internet Requests For Comment (RFC) have been written on DNS:
RFC 1032 - Domain Administrators Guide
RFC 1033 - Domain Administrators Operations Guide
RFC 1034 - Domain Names - Concepts and Facilities
RFC 1035 - Domain Names - Implementation and Specification
RFC 1591 - Domain Name System Structure and Delegation
RFC 1713 - Tools for DNS debugging
RFC 1912 - Common DNS Operational and Configuration Errors
RFC 2182 - Selection and Operation of Secondary DNS Servers
RFC 2219 - Use of DNS Aliases for Network Services
RFC 2541 - DNS Security Operational Considerations

$Id: 2,v 1.4 2003/06/07 04:52:24 rjd Exp $

^ Return to DNS FAQ Table of Contents
   
Q 3. What is BIND?
A "BIND (Berkeley Internet Name Domain) is an implementation of the Domain Name System (DNS) protocols and provides an openly redistributable reference implementation of the major components of the Domain Name System, including:
  • a Domain Name System server (named)
  • a Domain Name System resolver library
  • tools for verifying the proper operation of the DNS server

The BIND DNS Server is used on the vast majority of name serving machines on the Internet, providing a robust and stable architecture on top of which an organization's naming architecture can be built. The resolver library included in the BIND distribution provides the standard APIs for translation between domain names and Internet addresses and is intended to be linked with applications requiring name service."

--from Internet Software Consortium BIND

$Id: 3,v 1.1 1999/11/26 07:20:34 rjd Exp $

^ Return to DNS FAQ Table of Contents
   
Q 4. How can I learn more about BIND?
A More can be learned about BIND through supporting web sites:
Internet Software Consortium BIND
A Brief History of BIND
DNS Resources Directory

$Id: 4,v 1.1 1999/11/26 07:25:23 rjd Exp $

^ Return to DNS FAQ Table of Contents
   
Q 5. How do I setup an Virtual Domain with RXN DNS Service?
A Setting up your own Virtual Domain with RXN DNS Service involves just a few simple steps:
  • Select an available domain name.
  • Register your choosen domain name.
    • Registration can usually be performed immediately at the accredited registrars web site. Most registrars will charge a small fee for this service. When you register your domain, be certain to specify that the root servers should point to the RXN domain name servers:
        Primary DNS Server
          Hostname: ns1.rxn.com
          IP Address: 65.41.114.51
      
        Secondary DNS Server
          Hostname: ns2.rxn.com
          IP Address: 65.41.114.52  
      
  • Notify RXN when you receive confirmation.
    • When you receive confirmation of domain registration from your accredited registrar contact support@rxn.com to setup your acccount.

$Id: 5,v 1.3 2007/11/09 05:30:51 rjd Exp $

^ Return to DNS FAQ Table of Contents
   
Q 6. How do I configure DNS to support Email Validation?
A The Studio of Arts and Sciences provides a good summary of Solving DNS & Email Server Validation Problems that is cached here:

Solving DNS & Email Server Validation Problems

Is my DNS a Mess ...?       Most Probably, Yes!

 

Surveys Show that 80% of DNS Domain Name Servers are Misconfigured.

Chances are high that many email messages are blocked... or possibly lost forever.... without mail administrators being any the wiser.

This article shows you how to analyse and solve most DNS related MTA configuration problems

Original source for this article is BIND8 for NT and other sites by Len Conrad... on how to build and configure, relay-only mail hubs for aggressive anti-spam defense with increased reliabiilty and throughput. This is just a re-hash of what you will find there.
 

How to stop DNS from Blocking Valid EMail Delivery



Until IP Version 6 becomes widely implemented, validation of email connection will (mostly) remain dependent on the current Domain Name Service (DNS).

Growing popularity of Mail Tranfser Agents (MTA) such as postfix, by Wietse Venema and IBM, qmail, and sendmail is partly due to their capacity to validate any other mail servers who wish to send them mail.

Validation helps reduce the volume of Unsolicited Bulk Email (UBM or SPAM) with enhanced security, efficiency and reliability for Internet mail services in general.

Using postfix as as example, just take a look at one set of such validation options:

"Postfix Configuration - UCE Controls"

... to see how these MTA's can really slam shut the mail door to any but the most trustworthy and identifiable mail servers.

How DNS Queries are used to Validate SMTP Clients

Take a moment to look at at this portion of an Ipswitch Imail SMTPD server log. The log shows what information is provided by the SMTP client that is trying to send email to our SMTPD server:



Figure 1:

[ Figure 1 ]

Armed with our log information, let's consider the validation procedures that various mail servers will run against our (and our hosted clients') attempts to send mail?


DNS Authentication Tests Run by Email Servers:

Validating the ip address of the SMTP client:

  1. Query DNS for the PTR record of ip address (reverse lookup)

  2. Does the PTR record for this ip exist?
    If NO: then reject the mail.

  3. Does the PTR record refer to the HELO/EHLO hostname?
    If NO: then reject the mail.

  4. Does the ip address's PTR hostname have an A record??
    If NO: then reject the mail.

  5. Does the ip address's PTR hostname have an MX record??
    If NO: then reject the mail.

  6. Is the ip address in Mail-Abuse.org's MAPS (or similar) databases of black-holes, open-relays, or dial-ups?
    If YES: then reject the mail.

  7. Is the DNS reverse delegation valid and/or correct?
    If NO: then reject the mail.


Validating the HELO/EHLO hostname information:
  1. Does the hostname resolve to an DNS A or MX record? [3]
    If NO: then reject the mail.

  2. Is the hostname a FQHN: Fully Qualified Host Name ?
    If NO: then reject the mail.

  3. If there is an A record, is that ip address in one of the MAPS databases for black-holes, open-relays, or dial-ups?
    If YES: then reject the mail.


Validating the MAIL FROM: @sender.domain information:
  1. Does sender.domain resolve to a DNS A or MX record?
    If NO: then reject the mail.

  2. Is sender.domain a FQHN: Fully Qualified Host Name ?
    If NO: then reject the mail.

  3. If there is an A record, is the ip address listed in databases of black-holes, open-relays, or dial-ups?
    If YES: then reject the mail.
If you want to be able to validate access to your own mail server, then check out the links above. No matter what brand of mail server you use, you can implement Postfix, IMGate or similar solutions suited to your preferred operating system: Increasing the availability, speed, reliability, and overall quality of your mail infrastructure.

How to configure DNS for correct email validation

From the above, it follows that well configured mail servers will use DNS database records to validate email transfers. Correct DNS based validation reduces spam and has some important security benefits.

So, being a responsible and enthusiastic administrator, you're asking How can I setup my DNS so that my own and my clients' mail is reliably delivered to mail servers that use DNS validation techniques?

Make sure your DNS has been delegated with reverse authority
If your DNS is delegated with reverse zone authority, make sure your reverse zone is setup perfectly, at least for the ip addresses of your mail servers... but don't stop there: It's a good idea to populate your entire reverse zone with real hostnames and/generic placeholder hostnames even if they are not used.

Check your reverse zone: Is it working? Use the ip block and Scan rDNS tools at SamSpade.org. Using the rDNS tool, if you get no results, or if the results are not what you put in your db. reverse zone file, then your reverse zone is broken!

  • For every domain in your DNS, make sure the zone files contain at least these records:

    $ORIGIN mydomain.com.
    @    A      ip.ad.re.ss
    @    MX     10  mailhost.domain.com.
    
  • For every mail host (real and virtual) in your DNS, make sure the zone files contain at least these records:
    $ORIGIN somedomain.com.
    mailhost   A   ip.ad.re.ss
    @          MX  10   mailhost.somedomain.com.
    mailhost   MX  10   mailhost.somedomain.com.
    
  • For every mail host (real and virtual) in your DNS, make sure you know how your mailserver(s) is announcing itself in the HELO/EHLO hostname field.

    Is your SMTP client sending mail by first announcing itself as:

    EHLO mail.mydomain.com

    or

    EHLO mydomain.com

    or

    EHLO smtp.mydomain.com

    or

    EHLO (nothing)

    or

    EHLO someotherdomain.com

    ? ? ? ? ?

    Make sure the hostname appearing as EHLO/HELO hostname (see log example above) is entered correctly in the DNS database using:

    1. A FQHN, Fully Qualified Host Name: in the format: 111.222.123.234 IN A host.domain.com.

    2. The FQHN has a DNS A record (as per above example).

    3. The FQHN has a DNS MX record... for example:

      111.222.123.234 IM MX 1 host.domain.com.


For further information, check your DNS settings using dnsreport web based DNS report service

For a better understanding of any of the above terms/values, refer to the various links and log snippet in Figure 1. above. Even if you do not intend to use Postfix as your own MTA, it is worth browsing the Postfix documentation as a good reference source for many of the issues introduced here.

When your configure your DNS to meet the guidelines set out above, your DNS definitely will NOT be a mess.

Consequently, you will be able to congratulate yourself on a job well done, and your clients and mail servers will have the best chance of avoiding rejection or black-listing by other mail servers.

$Id: 6,v 1.1 2004/07/17 04:33:32 rjd Exp $

^ Return to DNS FAQ Table of Contents
   

DISCLAIMER: This FAQ is provided as is without any expressed or implied warranties. While every effort has been taken to ensure the accuracy of the information contained in this FAQ, the maintainer assumes no responsibility for errors or omissions, or for damages resulting from the use, or misuse, of the information contained herein.
built by RXN FAQ Builder!

hits since 24 Jul 1997 - copyright (c) 1997-2012 RXN Communications - webmaster@rxn.com - Revised 5 Nov 2012