home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!cis.ohio-state.edu!ucbvax!agate!garnet.berkeley.edu!cliff
- From: cliff@garnet.berkeley.edu (Cliff Frost)
- Newsgroups: comp.protocols.tcp-ip.domains
- Subject: Re: CNAME records and MX/NS records
- Message-ID: <1iv1no$8mb@agate.berkeley.edu>
- Date: 12 Jan 93 18:13:12 GMT
- References: <1993Jan11.192147.8578@maths.tcd.ie> <1993Jan11.203058.28778@mp.cs.niu.edu> <1isteb$nmc@agate.berkeley.edu> <fn51H7&8_b@atlantis.psu.edu>
- Organization: University of California, Berkeley
- Lines: 73
- 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
-