Introduction

The Mach2 DNS (Domain Name Services) Module lets you 
locally administer the host names under your domain without  
waiting for your service provider to make name changes for 
you.  Previously, this was possible only if you were willing to 
install and manage a full-blown UNIX TCP/IP implementation.

The Mach2 DNS Module provides a high performance domain 
name server that is easily configured for and integrated with 
either the Connect2SMTP or Mach2 TCP/IP Router 
environment.


Features
 
 -Tightly integrated within the Connect2SMTP or Mach2 
  TCP/IP Router operating environments.
 -Supports any number of unique zones (master files), 
  memory permitting.
 -Provides very fast style of name server lookups for local 
  nodes when queried for data outside of its authority.
 -Supports up to 20 concurrent zone transfers.
 -Complies with RFC's 1034 and 1035.
 -Allows interactive browsing of zone data.
 -Provides the same scroll-back capabilities as other 
  Connect2SMTP or Mach2 TCP/IP Router modules, allowing 
  you to easily view and monitor current or previous domain 
  server activities.
 -No need for special hardware or any knowledge of UNIX; 
  Connect2SMTP and the Mach2 TCP/IP Router run on a 
  standard PC.
 -Can be run in either real-mode, or as a native high-speed, 
  protected mode application with direct access to all 
  extended memory available.


Installation

Copy the DNS Module files into your Connect2 SMTP or Mach2 
directory.  The files to be copied are DNS.DLL and DNS.LIC 
(or DNSE.LIC for a 30-day evaluation  version).

The first step of the installation is to install your DNS Module 
serial number, or initialize its 30-day trial period.  This is done 
by running the REGISTER.EXE program that was shipped with 
your existing copy of Connect2SMTP or the Mach2 TCP/IP 
Router.

Follow these steps to complete this process:

1. Run REGISTER.EXE.
 
2. Select 'Product Registration' from the menu.
 
3. When prompted for a 'Directory Containing License Files', 
   enter "A:\" if the DNS.LIC file is located on a diskette in the 
   A: drive, or enter "." (a period character) if the file resides in 
   the current directory.
 
4. Select the entry with "Domain Name Server" in the 
   "Product" column, and press Enter.
 
5. If you are installing a 30-day evaluation version, leave 
   "EVALUATION" in the Serial Number field, and advance 
   to the Company Name field.  If you are installing a 
   purchased license, the serial number will be filled in 
   automatically, and you can advance to the Company Name 
   field.
 
6. Press Enter to complete the serialization process, and 
   continue with the configuration steps in the following 
   section.


Overview

Domain Name Service (DNS) is the dominant protocol used on 
the Internet to resolve host names to IP Addresses, and to 
determine how mail exchange (MX) for any particular host 
should be performed.  Before configuring Connect2 SMTP or 
the Mach2 TCP/IP Router for use with the DNS module, it could 
prove helpful, although not absolutely necessary, to stop and 
understand some of the technical issues and concepts involved.

Implementation

The DNS module was intended to be a robust and authoritative 
name server.  More importantly, it was designed to serve as the 
primary name server for your domain.

Previously, this function was typically performed by the 
NAMED daemon in the UNIX operating system.  This meant 
that you had to install and maintain a PC running UNIX if you 
wanted to manage your own name server.  The DNS module 
now provides this capability as an integrated module running in 
either Connect2SMTP or the Mach2 TCP/IP Router.

Generally, it is not desirable to have just one name server acting 
as the authority for a zone. To have multiple name servers act as 
authorities for a zone, additional name servers (normally your 
service provider's) must be explicitly configured to act as a 
Secondary name server for the zone.  Secondary name servers 
will act as an authoritative name server for the zone, but will get 
data for the zone from the primary name server instead of from 
a locally administered zone file.

When a name server is configured as a Secondary name server 
for a zone, it polls the primary name server (which will be your 
DNS module) on a configured interval that you specify in your 
zone data file(s) (the Refresh parameter in the SOA record).  
This "poll" generated by a secondary name server is actually a 
query for your current SOA record.  If the Serial Number field 
in your SOA record has changed, the secondary name server 
will then request a new copy of your zone using a special DNS 
function called AXFR (Zone Transfer).

If your service provider has been managing your DNS 
configuration, you should contact them and tell them you are 
now running the Primary name server for your domain. Request 
that they delete your zone data, and reconfigure their name 
servers to be a Secondary name server for your domain.  (You 
will need to give them the IP Address that your DNS module 
will be using, and the name of your zone.)  But don't do this 
until you've got the DNS module installed and configured!

Switching to this type of configuration does not lessen the 
ability of outside hosts to resolve names in your domain 
(provided you properly configure your master files); it transfers 
the maintenance of your zone data into your hands.  This lets 
you add or delete hosts immediately instead of having to contact 
your service provider to request the change.

Transport

DNS runs on top of TCP/IP using both the UDP and TCP 
protocols.  The majority of queries issued to find the IP Address 
of a hostname, or to determine Mail Exchange information, 
primarily use UDP.  TCP connections are used mainly for 
transferring the contents of a zone because zone data is lengthy 
and because a reliable transport is needed.

The UDP and TCP port numbers for DNS are both 53. Don't let 
this confuse you; UDP and TCP port space is unique.  That 
means that a TCP/IP application listening to UDP port 53 is 
separate and unique from a TCP application listening on port 
53.

A UDP application listens for packets without any sense of 
being connected and without any type of sequencing.  A TCP 
application is connection-based, and data exchange is both 
reliable and guaranteed to be in sequence.

The DNS module listens on port 53 of both UDP and TCP.  
Both types of listening are handled asynchronously.  However, 
only UDP queries are processed and replied to asynchronously.  
TCP connections are handled in a multi-threaded fashion similar 
to SMTP.  When a listening TCP connection is opened, the 
DNS module launches a separate process, one for each active 
connection, that listens and replies to TCP packets received.  
The difference in the response time between a UDP or a TCP 
type of connection is rarely noticeable because the kernels for 
both Connect2SMTP and the Mach2 TCP/IP Router are very 
efficient about distributing processing time.


Authoritative or Non-Authoritative

Zone data (the records in your master files), is either 
authoritative or non-authoritative.  The DNS module 
automatically makes this determination based on whether the 
domain name for each record is logically under the domain 
name used for the SOA record. Most of the records under the 
SOA will be authoritative, because that's the nature of what the 
zone file is all about.  It is helpful to understand the differences 
regarding how the DNS module treats authoritative vs. non-
authoritative records.  It's also helpful to understand whether a 
query received is a question for data (whether or not found) for 
which we are or are not authoritative.

Most of the functionality of the DNS module follows the 
standards described by RFC-1034 and 1035.  The biggest 
difference is that when it receives a query for a name for which 
it is not authoritative, it simply relays the query to the other 
name servers it has been configured to use.

Non-Authoritative UDP Queries

If the DNS module receives a UDP query for data that it is not 
authoritative for, and if the query requested recursion, the DNS 
module immediately repeats the query to all of the name servers 
defined under its section of the configuration file.  If one of 
those name servers then replies with no answers, but gives 
additional name servers, the DNS module repeats the query to 
those name servers as well.  If a positive reply is then received, 
the DNS module relays it back to the sender of the original 
query.  This is a very fast technique and provides the fastest 
overall name server capability possible for local nodes, even 
when the query is not for data for which the DNS module is 
authoritative.

Non-Authoritative TCP Queries

If the DNS module receives a TCP query for data that it is not 
authoritative for, it will not repeat the query to the list of name 
servers, but will return a non-authoritative reply with an answer 
count of zero.  If the DNS module knows of any name servers 
that appear to be authoritative for the query, it will list them as 
additional name servers in the reply (along with their IP 
Addresses if known).

Authoritative Queries

If the DNS module receives a UDP or TCP query for a name 
that it is authoritative for, it will return an authoritative answer, 
along with any data that matches the query.


Zone Master Files

A Zone Master File is used to define one or more zones (but 
typically only one zone is described per file).

A Zone is the portion of the domain name space that belongs to 
you.  It is sometimes referred to as "your domain".  Each zone 
starts with an SOA record, and continues until ended implicitly 
by the start of another SOA record, or by the end of file.

Formatting Syntax

The formatting of a zone master file follows these general rules:

-Each record that defines a new name must start in the first 
 column.  Records that are indented are considered to have 
 the same name as the line before, and parsing 
 automatically advances past the domain name.
-If either the Class or the TTL fields are left out, their 
 values will assume that of the previous record, if the record 
 is authoritative.  If the record is non-authoritative, the TTL 
 will default to zero unless specifically given for the record.
-A free-standing @ sign can be used to represent the current 
 Origin.
-If a domain name is not terminated with a trailing period, 
 the current Origin is automatically appended.

The current Origin can be changed on-the-fly using a 
$ORIGIN statement.


Syntax Differences

The syntax guidelines of a zone master file are described in 
RFC-1035.  Zone master files used by the DNS module closely 
follow this syntax, with a few exceptions:

- $INCLUDE statements are not supported within master 
  files, but you can use as many different master files as you 
  need with separate Primary= statements in C2SMTP.INI 
  (or MACH2R.INI for the Mach2 TCP/IP Router).
- Parentheses used to indicate line breaks within a record are 
  handled implicitly rather than explicitly.  That is, if the 
  data for a record is incomplete, the DNS module will 
  automatically span multiple lines when parsing the record 
  without the need for parentheses.  Parentheses can be used, 
  but they are not essential.  (The only record type that 
  usually spans more than one line is an SOA record.)
- A pound sign (#) can be used as a comment in addition to a 
  semi-colon.
- The only Class supported is "IN" (Internet), which is the 
  default.  If some other Class is encountered, an 
  "unsupported class error" will be generated at startup.
- All of the defined Types are supported except WKS 
  records.

All other master file syntax options are supported.


Time Formats

Four of the Seven fields in an SOA record are time related, and 
so is the optional TTL field for each individual record.  The 
syntax defined by RFC-1035 requires that units of time be 
expressed as a value in total seconds.  This means that if you 
wanted to express the time value for 1 day, you would use a 
value of 86400 because (60 seconds*60 minutes) * 24 hours = 
86400 seconds.

Even though you have to express time as a value of the total 
number of seconds, the DNS module always displays time 
values formatted as ddd:hh:mm:ss.  This lets you easily 
determine whether you used the right number, and it makes 
understanding incoming values considerably easier.

Time to Live

Each record in a zone master file has its own unique Time to 
Live (TTL) value.  It is normal for a zone file to make no 
reference to TTL values however, and just let the Minimum 
TTL value for the SOA dictate the TTL of each record.  If a 
TTL value is expressed for an authoritative record, that value 
will become the default TTL for all subsequent authoritative 
records until another TTL value is expressed.  A value 
expressed for the TTL of an authoritative record must be equal 
to or greater than the Minimum TTL value in the SOA record.  
If it is not, the DNS module will automatically raise it to that 
value.

TTL values for non-authoritative records automatically default 
to zero unless specifically expressed for a particular record.  
There is no automatic carry-over of a default TTL for non-
authoritative records.

The TTL field in each record is used to determine how long a 
record can reside in the cache of other name servers before it is 
considered obsolete.  This is why non-authoritative records that 
we produce should default to zero (i.e., don't cache them 
because we're not the authoritative source for their values).

Absolute and Relative Domain Names

When you edit a zone master file, it is important to understand 
that any domain name that does not end with a trailing period (.) 
is considered a relative domain name and the current Origin 
(described next) is automatically appended to it.  A domain 
name that ends with a trailing period is considered an absolute 
name, and is used exactly as it is expressed.

The Current Origin

When a master file is initially loaded, the current Origin is the 
value that was passed on the Primary= statement in the 
configuration file.  The value of the current Origin is normally 
the same as the name of the domain being configured, but 
doesn't have to be (it's rare to do otherwise, however).

The current Origin can be changed at any point in a zone master 
file by using a $ORIGIN command (although this is also rare).

The current Origin is used whenever a free-standing @ sign is 
encountered; but more importantly, the current Origin is 
automatically appended to relative domain names (names not 
anchored with a trailing period).

Note:   The current Origin is not actually appended to each relative 
domain name internally; rather, the name is ended with a 
pointer that is aimed at the current Origin.  This saves 
considerable memory by not having to repeat the current 
Origin for each relative entry.  The DNS module also 
automatically checks whether an absolute domain name is 
ended by the same text as the current Origin.  If so, it converts 
the entry to also use a pointer to the current Origin.

So let's use some examples to help make this a little clearer.  
Consider the following C2SMTP.INI (or MACH2R.INI) 
configuration files:

[DNS]
  NameServer=198.41.0.4       ;Configure a name server
  NameServer=164.109.1.3      ;Configure a name server
  Primary=acme.com, acme.dns  ;Load the acme.com zone

And the following zone file for acme.com, which we called 
ACME.DNS:

@                 SOA   C2SMTP              ;Zone's Primary NS
			POSTMASTER          ;Responsible mailbox
			5                   ;Serial number
			1800                ;Refresh interval
			300                 ;Retry interval
			432000              ;Expiration
			86400               ;Minimum TTL
		  NS    C2SMTP              ;1st NS record
		  NS    NS.DIGEX.NET.       ;2nd NS record
		  MX    0 C2SMTP            ;1st MX record
		  MX    10 MAIL1.DIGEX.NET. ;2nd MX record
C2SMTP            A     198.24.1.2          ;Our IP Address
JOE               A     198.24.1.5          ;Joe's IP Address
NS.DIGEX.NET.     A     164.109.1.3         ;IP Address
MAIL1.DIGEX.NET.  A     204.91.197.224      ;IP Address

When the configuration file described this zone, it said:

Primary=acme.com, acme.dns

The first parameter for Primary= sets the starting current Origin 
(acme.com), and the second parameter has the filename that 
contains the zone.

Remember that we said a free-standing @ sign turns into the 
current Origin?  So the result for the first SOA record is this:

ACME.COM        SOA  C2SMTP.ACME.COM           ;Zone's Primary NS
		     POSTMASTER.ACME.COM       ;Responsible mailbox
		     5                         ;Serial number
		     1800                      ;Refresh interval
		     300                       ;Retry interval
		     432000                    ;Expiration
		     86400                     ;Minimum TTL

The first character in the ACME.DNS file was a free-standing 
"@" sign, so it was translated to "ACME.COM".  Since the first 
two parameters of the SOA record weren't anchored with 
trailing periods, the current Origin was appended to them as 
well.

This sample also uses another feature that you can use in zone 
files where an indented record assumes the same name as the 
previous record.  Since we need to describe name server (NS) 
and mail exchange (MX) records for ACME.COM; and, since 
that is the same name we effectively just used for the SOA 
record, we went ahead and did that in the example above using 
indented NS and MX records.

Note:   If you're using the DNS module with the Mach2 TCP/IP 
Router, you probably won't want to call your name server 
C2SMTP.ACME.COM.  It would be more appropriate to call 
your host name something like NS.ACME.COM instead.


Record Types

A zone is configured with at least one SOA record, followed by 
any number of additional records needed to completely describe 
the zone.  Each record has a unique Type.  There are 
approximately fifteen record types supported by DNS.  The 
most frequently used are the following:

Type     Means               Purpose
SOA      Start of Authority  Begins a domain and defines zone 
			     information.

A        Address             Describes an IP Address.

MX       Mail Exchange       Designates a host that accepts mail 
			     for a domain name.

NS       Name Server         Designates an authoritative name 
			     server for a domain name.


SOA - Start of Authority

An "SOA" record is used to mark the start of a new (zone) 
authority, and to describe some of the characteristics about the 
zone which are used by Secondary name servers when caching 
the zone.

An "SOA" record has seven parameters.  Only the Minimum 
TTL parameter is used by the DNS module directly - the 
remaining parameters are used by Secondary name servers.


A - IP Address

An "A" record describes the IP Address of a particular host.

MX - Mail Exchange

"MX" records are used to describe hosts that will accept mail 
for a domain name.  More appropriately put, these are hosts to 
which mail should be delivered.

An MX record has two parameters, the first is the preference, 
and the second is the host name to which mail should be 
delivered.  More than one MX record can be used for a 
particular domain name; and, when this is the case, they are 
used in order of lowest preference to highest preference.

NS - Authoritative Name Server

"NS" records are used to describe the name servers that are 
authoritative for the domain.  More than one NS record can (and 
should) be used for a particular domain name, which should 
include all Primary and Secondary name servers.

Each NS entry listed for a domain is expected to have an 
authoritative copy of the zone data for the domain at all times!  
Don't list NS entries for your domain if you're not absolutely 
sure that the host is caching your zone!  (Which can easily result 
in confusing problems with remote users sometimes getting 
authoritative name errors when sending mail to your domain.)


Configuration

Configuring the DNS module involves both the [KERNEL] and 
the [DNS] sections of either the C2SMTP.INI file (for 
Connect2SMTP) or the MACH2R.INI file (for the Mach2 
TCP/IP Router).  These are flat text files that you can edit with 
any text editor.

The only statement involved under [KERNEL] is a Load= 
statement, which is needed to tell the Kernel to load the 
DNS.DLL file.  For example:

[KERNEL]
  Load=MHS              ;Load the MHS Module
  Load=SMTP             ;Load the SMTP Module
  Load=DNS              ;Load the DNS Module

When the DNS module is loaded, it uses these statements under 
its section of the configuration file that involve its 
configuration:

  NameServer=
  Primary=
  Scrollback=

A minimum configuration typically defines two primary zones, 
and at least one name server.  For example:

[KERNEL]
 
Load=DNS                                   ;Load the DNS module

[DNS]
NameServer=198.41.0.4                      ;Configure an external name server
NameServer=164.109.1.3                     ;Configure an external name server
Primary=acme.com, acme.dns                 ;Load the acme.com zone
Primary=1.24.198.in-addr.arpa, in-addr.dns ;Load in-addr zone

The first Load= statement causes the Kernel to load the DNS 
module.

But why are two Primary= statements used?  The first is for the 
"acme.com" domain, which is probably obvious, but what about 
the "1.24.198.in-addr.arpa"?  This appears because you will 
most likely need to manage your portion of the 
"IN-ADDR.ARPA" domain when managing your domain.  This 
is a special domain used for reverse name lookups (described in 
a following section).


[DNS] Section Statements

NameServer=     <IP Address>

This statement defines an external name server to field queries 
from the DNS module when the DNS module has received a 
name server query for data for which it is not an authority or 
doesn't know the answer.

This statement can occur more than once to define up to 10 
external name servers.

When a query is relayed to external name servers defined with 
this statement, it is not done sequentially, but is sent 
simultaneously to all name servers.  Typically using two or three 
name servers is sufficient.  Defining more than two or three 
could induce a momentary deluge of network traffic.

Do not list a local IP Address in a NameServer= statement.  
This would result in an indefinite loop where the DNS module 
would continually query itself for names for which it has no 
answer.  This activity will almost immediately overrun an 
internal stack.  The DNS module checks for this condition at 
startup and stops with a configuration error if a local IP Address 
was configured as one of the DNS Module's external name 
servers.

Primary=        <domain>,<master_file>

This statement sets the current Origin to the <domain> name 
given, and then loads the zone data for that domain from the 
master file specified in the second parameter.

Do not use path names in the <master_file> parameter.  The DNS 
module will automatically look for the master file in the directory 
that Connect2SMTP or Mach2 TCP/IP Router was run from.

The <Z>one Data command on the DNS module's console can be 
used to browse information loaded (and parsed) from the zone master 
files.

This command can be repeated as often as is necessary to load 
separate zones.


Scrollback=     <buffer_size >

This statement sets the scrollback buffer size used by the DNS 
module when allocated from conventional memory.

This statement follows the same rules for Scrollback= used in 
other sections of C2SMTP.INI or MACH2R.INI.

If Connect2SMTP or the Mach2 TCP/IP Router is running in 
protected mode, or if sufficient expanded memory (EMS) is 
present, this statement is not used and a 64K buffer is allocated.



Master File Configuration

Typically only one zone (domain) is described per master file.  
More than one zone can be defined in a master file by using 
multiple SOA records, but such practice is not recommended.

A master file normally starts with an SOA record, which is then 
followed by as many other record types as are needed to 
describe the domain.

Master files are flat text files that closely follow the same syntax 
used by other name servers in the UNIX world, as defined by 
RFC-1035.

Sample Master File
@                  SOA     C2SMTP              ;Zone's Primary NS
			   POSTMASTER          ;Responsible mailbox
			   5                   ;Serial number
			   1800                ;Refresh interval
			   300                 ;Retry interval
			   432000              ;Expiration
			   86400               ;Minimum TTL
		   NS      C2SMTP              ;1st NS record
		   NS      NS.DIGEX.NET.       ;2nd NS record
		   MX      0 C2SMTP            ;1st MX record
		   MX      10 MAIL1.DIGEX.NET. ;2nd MX record
C2SMTP             A       198.24.1.2          ;Our IP Address
JOE                A       198.24.1.5          ;Joe's IP Address
NS.DIGEX.NET.      A       164.109.1.3         ;IP Address
MAIL1.DIGEX.NET.   A       204.91.197.224      ;IP Address

In this example, there is only one record that spans multiple 
lines, the first SOA record.  All other lines each define a 
separate record.

Remember that a free-standing @ sign turns into the current 
Origin, and that a name without a trailing period is 
automatically appended with the current Origin.  That means the 
first SOA record is really being defined as this:

ACME.COM      SOA     C2SMTP.ACME.COM       ;Zone's Primary NS
		      POSTMASTER.ACME.COM   ;Responsible mailbox
		      5                     ;Serial number
		      1800                  ;Refresh interval
		      300                   ;Retry interval
		      432000                ;Expiration
		      86400                 ;Minimum TTL

The second record defined in the example is the first NS record 
for C2SMTP.  It might appear to be part of the SOA record, but 
it is not!  Since the NS records are defining the authoritative 
name servers for the zone, and since the zone has the same 
name as the current Origin, we can assume the default domain 
name that carries over from the previous record by indenting the 
record.  In this example, we don't need to explicitly specify a 
domain name different than the current Origin until we reach 
the first "A"ddress record for C2SMTP (198.24.1.2 in the 
example).

Notice that domain names that are not part of our zone are 
expressed as absolute names with a trailing period.  We don't 
have to fully qualify domain names that are under our zone (i.e. 
the "A"ddress records for C2SMTP and JOE) because the 
current Origin will do that automatically if we don't use a 
trailing period.


Additional Considerations

When you configure the zone data for your domain, remember 
that what you are describing is the entire information for your 
domain.  It's not just information that other mail servers will 
use, and not just information that other name servers will use, 
it's the whole "shooting-match".

One thing to remember is to always use as many NS records as 
there are authoritative name servers.  If your service provider 
configures one of its name servers as a secondary cache of your 
domain, and they have another name server that acts as a 
secondary to the first one, then list both name servers as NS 
records for your domain (because either one can be queried by 
outside hosts to obtain authoritative data).  And, don't forget to 
list the DNS module itself as another NS record.

MX records are another important aspect of your zone data.  
Always list the desired destination host with the lowest 
preference.  However, it's a good idea to use one or two 
additional MX records with higher preferences to define nearby 
hosts that will hold mail for you in the event of transport 
problems.  A service provider will typically run a host just for 
mail exchange.

Whenever you update a master file, always be sure to change 
the Serial Number field in the SOA record.  The Serial Number 
field is what your service provider's name servers use to 
determine whether the copy of your zone needs to be refreshed.  
If you forget to change the Serial Number, your service 
provider's name servers won't know anything has changed, and 
will continue to server obsolete data until they are restarted for 
local reasons.


General Format

The general format of records in a master file is:

[domain_name][TTL]      [Class] Type    RData

Per RFC-1035, this can optionally be reversed like this:
[domain_name][Class][TTL]       Type    RData

However, the DNS module only recognizes and defaults to a 
Class of "IN" (Internet).  Other Classes (such as "CH" for 
CHAOS, or "HS" for Hesiod) are not supported and will 
generate an error.

If a record is indented, the domain_name is assumed to be the 
same as that of the last record that explicitly gave one.

TTL's for authoritative records automatically carry-over from 
the last value used if not specified.  An attempt to use a TTL 
explicitly lower than the minimum TTL expressed in the SOA 
record is ignored.

TTLs for non-authoritative records default to zero unless 
specifically expressed otherwise on a per-record basis.  
Responses that the DNS module gives that might include non-
authoritative data should not be cached.

The Type value can be any of those defined by RFC-1035 
except for type WKS, which is not currently supported.

The RData (resource data) field is specific to the record Type.

If an error occurs during zone master file parsing, a message is 
displayed at startup that indicates the offending line number and 
filename involved



Master File Record Types

This section describes the syntax and purpose of the common 
record types.

Some of the record types defined by RFC-1035 are not listed 
here (which are mainly experimental or obsolete), but are still 
recognized and supported by the DNS module except for the 
type of WKS.

SOA     <orig_NS>
	<responsible_mailbox>
	<serial_number>
	<refresh>
	<expiration>
	<minimum_TTL>

The SOA record type contains seven parameters.  The first two 
parameters are domain names, and the last four parameters are 
time values expressed as total in seconds.

orig_NS

This is the domain name of the name server that is the original 
or primary source of data for this zone.  This is normally the 
domain name of the machine on which the DNS module is 
running.

responsible_mailbox

A domain name of the person responsible for this zone.  The 
first atom of the domain is the mailbox name, followed by the 
mail domain.  For example, "postmaster.acme.com" would be 
interpreted as "postmaster@acme.com".  If you are using 
C2SMTP and it shares the same domain, a value of 
"postmaster" is normal because C2SMTP will map mail 
addressed to postmaster to the MHS administrator.

serial_number

This is the serial number that reflects the current version of the 
data in the zone.  Whenever a master file is modified, the serial 
number should be incremented.  A common practice is to use a 
number that looks like a date, for example "950317", to reflect 
the last date the zone information was changed.

refresh

This parameter tells a caching Secondary name server how often 
to check if the zone has been changed.  (Setting this value too 
small might upset your service provider.)  This number should 
be kept to a value higher than 1800 (30 Minutes).

retry

This parameter tells a caching Secondary name server how often 
to retry the poll for whether zone information has changed, if 
the initial scheduled poll fails.

expiration

This parameter tells a caching Secondary name server how long 
it should hold your zone's data in the event that polling is 
unsuccessful for an extended period of time.

minimum_TTL

This parameter is used by the DNS module to enforce a 
minimum TTL stamp for responses that are authoritative.

A       n.n.n.n

Defines an IP "A"ddress record.

In addition to defining IP Addresses for local hosts, these 
records should be used to define the IP Addresses for any 
domain names that are referenced by parameters in an NS or 
MX record.

NS      <domain_name>

Designates an authoritative name server.

The domain name specified as the parameter is the name server 
that is authoritative for the domain name preceding the Type 
(NS).

Don't forget to list all NS records that apply to your domain, 
such as your service provider's name servers.

MX      <preference> <domain_name>

Designates a host that mail should be delivered to when 
addressed to the domain name that precedes the Type (MX).

More than one MX is often used (and is desirable in the event 
that a host is unavailable or unreachable).  When more than 
one MX record is present, they are used in order of lowest 
preference to highest preference.

A "wildcard" MX can be expressed by using an asterisk ("*") 
for the host name portion of the domain name being defined.  A 
wildcard is only returned as a response to a query if no other 
names qualify.  The order in which records are defined has no 
effect on whether a wildcard entry is returned by a query before 
a domain name that directly matches.  The entire zone data is 
searched for an exact match before searching for wildcards.

For example:

ACME.COM.               MX      0  C2SMTP.ACME.COM.
ACME.COM.               MX      10 MAIL1.DIGEX.NET.
*.ACME.COM.             MX      0  C2SMTP.ACME.COM.
*.ACME.COM.             MX      10 MAIL1.DIGEX.NET.
HOST1.ACME.COM.         MX      0  HOST1.ACME.COM.

An MX query for anything.ACME.COM is not the same as a 
query for just ACME.COM, so two sets of MX records are 
defined to handle both cases.  (This is not necessarily normal 
unless you are using Connect2SMTP's InverseHubSyntax 
option.)

If a query is received for "HOST1.ACME.COM", a specific 
match is found (even though it's after the wildcard MX records) 
so the MX information returned will be just 
"HOST2.ACME.COM".  Wildcard MX's are not used unless no 
other match is found after a scan of all existing information.

CNAME   <domain_name>

Defines the canonical name for an alias.

PTR     <domain_name>

Defines a domain name pointer.

PTR records usually are used only in the zone definition of a 
IN-ADDR.ARPA domain for reverse name lookups.

HINFO   <cpu> <os>

Defines host information for a domain name.

This record type is normally just for cosmetics.  The cpu 
parameter should describe the type of computer, and the os 
parameter should describe the operating system.  If either one 
contains a space or comma, they must be enclosed in double 
quotation marks.


The IN-ADDR.ARPA Domain

There is a special domain called IN-ADDR.ARPA that is used 
for reverse name lookups (translating an IP Address into a host 
name instead of vice-versa).  It works by using the same 
structure as domain names, only backwards.

To ensure that reverse name lookups for hosts under your 
domain work successfully, you should also manage the IN-
ADDR.ARPA domain for addresses under your IP subnet.  This 
can be important in SMTP mail exchanges because some SMTP 
mailers do a reverse name lookup to see if you are who you said 
you were; and, some FTP sites will deny access if they cannot 
verify your IP Address with a reverse name lookup.

Managing the IN-ADDR.ARPA domain is not difficult, but you 
must remember to tell your service provider that it needs to be 
cached as well when they configure their name servers as 
Secondary name servers for your zone.

Your portion of the IN-ADDR.ARPA domain is whatever your 
IP Subnet is, in reverse order.  For example, if your IP Subnet 
is:

198.24.1.nnn

Then your IN-ADDR.ARPA domain is:

1.24.198.in-addr.arpa

And, this is what you should use for the Origin portion of the 
Primary= command in the [DNS] section of the configuration 
file.

For example:

[DNS]
  NameServer=198.41.0.4       ;Configure an external name server
  NameServer=164.109.1.3      ;Configure an external name server
  Primary=acme.com, acme.dns  ;Load the acme.com zone
  Primary=1.24.198.in-addr.arpa, in-addr.dns ;Load in-addr zone

And the zone master file (IN-ADDR.DNS) might then look like 
this:

@       SOA     C2SMTP.ACME.COM.        ;Zone's Primary NS
		POSTMASTER.ACME.COM.    ;Responsible mailbox
		5                       ;Serial number
		1800                    ;Refresh interval
		300                     ;Retry interval
		432000                  ;Expiration
		86400                   ;Minimum TTL
	NS      C2SMTP.ACME.COM.        ;1st NS record
	NS      NS.DIGEX.NET.           ;2nd NS record
2       PTR     C2SMTP.ACME.COM.        ;Our IP Address
5       PTR     JOE.ACME.COM.           ;Joe's IP Address

There are several things to make note of here.  One is that the 
current Origin is "1.24.198.in-addr.arpa", which means we have 
to be careful to use fully qualified domain names.  Another is 
that the only types of records in an IN-ADDR.ARPA zone file 
are normally just PTR and NS records



Product Support

Support for Connect2SMTP is available directly from Infinite 
Technologies.  You may send mail to us at the following addresses:

MHS:            SUPPORT@INFINITE
CompuServe:     >MHS:SUPPORT@INFINITE
Internet:       SUPPORT@INFINITE.IHUB.COM
Phone:          (800) 678-1097

- or -

Infinite Technologies
11433 Cronridge Drive
Owings Mills, Maryland  21117


Discussion Lists

A variety of discussion lists are hosted by Infinite Technologies.  
Joining a discussion list can keep you updated on your areas of 
interest.  Available list names and descriptions can be requested 
by sending a message to Library @ Infinite.ihub.com with a 
subject line of INDEX.  A complete list of available discussion 
lists will be returned to you as an attachment to your e-mail 
message




