RXN Communications FAQ



\| \| \| \| \| \| \| \| \| \|

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. Visit the web site of one of the accredited registrars and use their lookup feature to find an available domain name. One of the accredited registrars we have worked with in the past is Network Solutions. 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: 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: Query DNS for the PTR record of ip address (reverse lookup) Does the PTR record for this ip exist? If NO: then reject the mail. Does the PTR record refer to the HELO/EHLO hostname? If NO: then reject the mail. Does the ip address's PTR hostname have an A record?? If NO: then reject the mail. Does the ip address's PTR hostname have an MX record?? If NO: then reject the mail. 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. Is the DNS reverse delegation valid and/or correct? If NO: then reject the mail. Validating the `HELO/EHLO hostname` information: Does the hostname resolve to an DNS A or MX record? [3] If NO: then reject the mail. Is the hostname a FQHN: Fully Qualified Host Name ? If NO: then reject the mail. 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: Does `sender.domain` resolve to a DNS A or MX record? If NO: then reject the mail. Is `sender.domain` a FQHN: Fully Qualified Host Name ? If NO: then reject the mail. 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? Keep your server addresses out of relay databases: Assuming you are not a spammer, the most common foul-up is running your mail server as an open-relay. What's that? Blocking databases such as Mail-Abuse.org and ORBS are designed to reduce spam. If you don't know what anti-spam databases are about, then spend some time studying the pages at Mail-Abuse.org. To run your mail server through an an open relay test: From the server console of the machine you wish to test, telnet to `relay-check.mail-abuse.org` and watch the automated test messages roll by! RFC 2505: Anti-Spam Recommendations for SMTP MTAs RFC 1912 Common DNS Operational and Configuration Errors RFC-Ignorant.Org registration centre Some more notes about standards here: Note 1 Note 2 Note 3 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: A FQHN, Fully Qualified Host Name: in the format: `111.222.123.234 IN A host.domain.com.` The FQHN has a DNS A record (as per above example). 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

Solving DNS & Email Server Validation Problems

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

How to stop DNS from Blocking Valid EMail Delivery

How DNS Queries are used to Validate SMTP Clients

How to configure DNS for correct email validation