From: cliff@garnet.berkeley.edu (Cliff Frost)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: CNAME records and MX/NS records
Date: 12 Jan 93 18:13:12 GMT
Organization: University of California, Berkeley
NNTP-Posting-Host: garnet.berkeley.edu

|> In article <1isteb$nmc@agate.berkeley.edu> I wrote:
|>
|> >It appears reasonable (to me) if you think of providing these services on
|> >multiple hosts, so that if one host goes down hard the other one is still
|> >providing the function.  Eg:
|> >
|> >; sam and mary are identically configured for processing email:
|> >
|> >	sam.foo.bar.	A	1.2.3.4
|> >	mary.foo.bar.	A	1.2.4.4
|> >	mail.foo.bar.	A	1.2.3.4
|> >			A	1.2.4.4

This has given some folks headaches or gas or something because it looks
like an attempt to duplicate the function of MX records.  If that were
what we were trying to do it would be gross.  Maybe it's gross anyway,
but at least you should get sick for the right reasons.  ;-)

One reason for the A record is that you might want to use the name "mail"
or "mailhost" as the target of some other programs than simply mail.  In
that case you need the A record because you can't have the CNAME record
because you already have the MX record.  You need the MX record rather 
than a CNAME record because if you use a CNAME the sending mailer rewrites
the header to the canonical name rather than the name used.  Why might you
want to preserve the name "mail" or "mailhost" in email headers (rather
than names like "mary" and "sam")?  Think about how long email messages
are preserved and how long names that are programmed into gateway configs
stay around.

Another reason is to provide machines which are configured with the
ability to handle a lot of difficult email routing decisions.  This
enables the administrators of several thousand local machines to punt
on the difficult forms of email addresses and send them off to one central
place for handling.  In most cases this could also be handled by MX'ing
the name, but not all (for just one simple example, there are still mail
programs out there which do not support MX records at all--including the
default sendmail from a major Unix vendor).

|> >; fred and betsy are running identical authoritative nameservers:
|> >
|> >	fred.foo.bar.	A	1.2.3.5
|> >	betsy.foo.bar.	A	1.2.4.5
|> >	ns.foo.bar.	A	1.2.3.5
|> >			A	1.2.4.5
|> 
|> 	Why???  How often do you change your glue records?  Also, your
|> parent domain is going to have to change his IP addresses for the glue
|> records anyway, why confuse things like this?
|> 
|> >From experience we can say it works well for mail and less wonderfully (but
|> >still useful) for nameservice.  The reason it is less useful for nameservice
|> >is the slew of software out there which is configurable for one and only one
|> >nameserver IP address.
|> 
|> 	This may be true for stub resolvers, but how many nameservers
|> only look at the first NS record?

Ok, I asked for trouble with the incoherencies here.  Sorry, I'll try again...

What works less than wonderfully is trying to provide extra reliability to
client resolvers by providing redundant nameservers.  This issue has nothing
to do with what the machines are named, of course.

So, why do we find it useful to split out the nameservers' names like this?

Well, we did it the second time we found ourselves faced with changing both
the names and addresses of our nameservers.  It turns out that the process
becomes much easier if all you have to do is change or add addresses.  Names
have a greater tendency to get hard configured into nooks and crannies than
IP addresses (although both do).

	Cliff Frost
	UC Berkeley