HDTenEightyP/NetNews huggingface dataset:
From: iglesias@draco.acs.uci.edu (Mike Iglesias)
Subject: Help needed setting up hesiod domains
Newsgroups: comp.protocols.tcp-ip.domains
Organization: University of California, Irvine
Date: 5 Jan 93 19:12:09 GMT

We'd like to start using hesiod to distribute amd mount maps, and I'd like
some input on how to setup the nameservers we have around campus to be able
to find the hesiod domain we have setup on a server.  Queries do not work
now because there are no root servers for hesiod, so caching-only nameds can't
figure out how to get to the name server on campus with the hesiod
information. 

Two ideas we have (but have not tried yet) are to put lines in the
root cache file (the one with the Internet root nameservers) to have a line 
that says the root nameserver for hesiod is our hesiod server, or to
make each nameserver a primary for . in the hesiod class and put information
in the domain file that points to our server.

Any suggestions/ideas/whatever?


Thanks,

Mike Iglesias                        Internet:    iglesias@draco.acs.uci.edu
University of California, Irvine     BITNET:      iglesias@uci
Office of Academic Computing         uucp:        ...!ucbvax!ucivax!iglesias
Distributed Computing Support        phone:       (714) 856-6926
From: vixie@pa.dec.com (Paul A Vixie)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: What's a TXT NS record mean?
Date: 11 Jan 93 05:09:45 GMT
Distribution: inet
Organization: DEC Network Software Lab
NNTP-Posting-Host: cognition.pa.dec.com
In-reply-to: mbl900@anusf.anu.edu.au's message of 11 Jan 1993 02:24:24 GMT

A TXT RR is unformatted text, subject to interpretation by the client
(if by anything).  They are used by some early versions of Hesiod, which
is an MIT package that puts /etc/passwd, /etc/group, et al into the DNS.
They have been used at odd times by others as continuations of HINFO or
for client-layer implementations of what later turned into RP or MA.  The
particular thing you are looking at seems to be a Lotus Notes datum of
some kind.
--
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Don't be a rebel, or a conformist;
<vixie@pa.dec.com> decwrl!vixie		they're the same thing, anyway.  Find
<paul@vix.com>     vixie!paul		your own path, and stay on it."  -me
From: vixie@pa.dec.com (Paul A Vixie)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Negative caching
Date: 12 Jan 93 11:48:13
Organization: DEC Network Software Lab
Distribution: inet
	<#gb1Hfjgyb@atlantis.psu.edu> <1ii2nsINNnsj@daisy.ee.und.ac.za>
	<C0IB0C.B6u@uunet.ca> <VIXIE.93Jan10123547@cognition.pa.dec.com>
	<C0pwD7.L9s@world.std.com>
NNTP-Posting-Host: cognition.pa.dec.com
In-reply-to: geoff@world.std.com's message of Tue, 12 Jan 1993 01:34:19 GMT

[Geoff Collyer]
>I think everybody at U of T who worked on BIND is too battle-fatigued to
>even consider another round of BIND testing.

Just the same, if the latest UT bind (including whatever you're using
that you might not have frozen into a .tar.Z file) could be put up for
ftp, I will _strongly consider_ intgerating it for 4.9.1.  I actually
ran UTBIND up until UCB 4.8.3 came out.  I would like 4.9.* to have in
it all the best stuff from everywhere.
--
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Don't be a rebel, or a conformist;
<vixie@pa.dec.com> decwrl!vixie		they're the same thing, anyway.  Find
<paul@vix.com>     vixie!paul		your own path, and stay on it."  -me
From: vixie@pa.dec.com (Paul A Vixie)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: DNS name servers
Followup-To: comp.protocols.tcp-ip.domains
Date: 6 Jan 93 12:38:51
Organization: DEC Network Software Lab
Distribution: inet
	<C0ECnq.MLy@news.rn.com> <1ie19cINNsuh@daisy.ee.und.ac.za>
NNTP-Posting-Host: cognition.pa.dec.com
In-reply-to: barrett@daisy.ee.und.ac.za's message of 6 Jan 1993 09:21:16 +0200

>Not with existing versions of bind -- you can dump the cache but you
>can't reload it.  This might be a good new feature for 4.9.1, if anybody
>wants to code it and if Paul agrees to take it.
>
>--apb (Alan Barrett)

Art Harkin has done some of the work.  I would like to see this for 4.9.1
but I will be depending on others to code and test it.
--
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Don't be a rebel, or a conformist;
<vixie@pa.dec.com> decwrl!vixie		they're the same thing, anyway.  Find
<paul@vix.com>     vixie!paul		your own path, and stay on it."  -me
From: barrett@daisy.ee.und.ac.za (Alan P Barrett)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Negative caching
Date: 7 Jan 1993 18:21:43 +0200
Organization: Dept. Elec. Eng., Univ. Natal, Durban, S. Africa
Distribution: inet
NNTP-Posting-Host: daisy.ee.und.ac.za

In article <by91Hibayb@atlantis.psu.edu>,
barr@pop.psu.edu (David Barr) writes:
> 3. The nameserver contacts a root nameserver to find out who "foo.UUCP"
>    is.  In the NXDOMAIN response is "how far" the root nameserver got
>    down the tree before it hit the invalid domain.  (For example if you
>    query "foo.UUCP" you get ".".  If you query "bogus.us" you get
>    ".US".  For "bogus.pa.us" you get "pa.us") Thus the local nameserver
>    knows that there is not a ".UUCP" domain, and can therefore cache that
>    information.

The authority records in the NXDOMAIN response tell you the position of
the nearest zone cut above the nonexistent domain.  This is different
from the nearest valid domain above the nonexistent domain.

For example, if you query for "bogus.in-addr.arpa", you will get an
NXDOMAIN response with "arpa" in the authority section.  You cannot
conclude that "in-addr.arpa" doesn't exist, but you can conclude that
there is not a zone cut at "in-addr.arpa".

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za                    Bang: m2xenix!undeed!barrett
Newsgroups: comp.protocols.tcp-ip.domains
From: barr@pop.psu.edu (David Barr)
Subject: Re: CNAME records and MX/NS records
Organization: Penn State Population Research Institute
Date: Tue, 12 Jan 93 18:49:09 GMT

In article <1iv1no$8mb@agate.berkeley.edu> cliff@garnet.berkeley.edu (Cliff Frost) writes:
>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).

	Okay, I can sympathize with this.  IMHO you'd be better off doing
something like:

	fred.foo.bar.	A	1.2.3.5
	betsy.foo.bar.	A	1.2.4.5
	ns1.foo.bar.	A	1.2.3.5
	ns2.foo.bar.	A	1.2.4.5

rather than:
	
	ns.foo.bar.	A	1.2.3.5
			A	1.2.4.5

Then you have the best of both worlds.  Easy to reconfigure to a
different name, as well as a different IP address.  Also, you have an
clearer distinction that the two addresses are indeed separate
machines, not different interfaces on one machine.

--Dave
-- 
System Administrator, Population Research Institute    barr@pop.psu.edu
	What if there was no such thing as a hypothetical question?
Newsgroups: comp.protocols.tcp-ip.domains
From: ajudge@maths.tcd.ie (Alan Judge)
Subject: CNAME records and MX/NS records
Organization: Dept. of Maths, Trinity College, Dublin, Ireland.
Date: Mon, 11 Jan 1993 19:21:47 GMT

Am I correct in saying that the data in an MX or NS record may not
be a CNAME, so that
	foo.bar.		MX	mail.foo.bar.
	mail.foo.bar.		CNAME	realhost.foo.bar.
	(and similarly for ns.foo.bar.)
is incorrect?

(We have been doing this for a while, apparently without problems.
Now it appears that this is bad.  What gives?


If so, what do people do when they want a nice logical separation
between services and hosts.  Is it permissible/reasonable to have
multiple A records for a single IP address?  Will anything get
upset that a reverse lookup does not return the same name?

Specifically, is something like
	foo.bar.	MX	mail.foo.bar.
	foo.bar.	NS	ns.foo.bar.

	mail.foo.bar.		A	1.2.3.4
	realname.foo.bar.	A	1.2.3.4

	ns.foo.bar.		A	1.2.3.5
	fred.foo.bar.		A	1.2.3.5

a reasonable and sane thing to do.

I know that parent domains will still have to be told if an NS
moves (to update glue), but this arrangement seems nicer.

Comments?
-- 
Alan Judge   ajudge@maths.tcd.ie  a.k.a. amjudge@dsg.cs.tcd.ie +353-1-7021782

"The path of my life is strewn with cowpats from the devils' own herd."
                                          -- Edmund Blackadder II
Newsgroups: comp.protocols.tcp-ip.domains
From: barr@pop.psu.edu (David Barr)
Subject: Re: Negative caching
Organization: Penn State Population Research Institute
Distribution: inet
Date: Thu, 07 Jan 93 18:20:46 GMT

In article <1ihlanINNlj9@daisy.ee.und.ac.za> barrett@daisy.ee.und.ac.za (Alan P Barrett) writes:
>The authority records in the NXDOMAIN response tell you the position of
>the nearest zone cut above the nonexistent domain.  This is different
>from the nearest valid domain above the nonexistent domain.
>
>For example, if you query for "bogus.in-addr.arpa", you will get an
>NXDOMAIN response with "arpa" in the authority section.  You cannot
>conclude that "in-addr.arpa" doesn't exist, but you can conclude that
>there is not a zone cut at "in-addr.arpa".

Aha!  Thanks!  I was mulling over my previous post at lunch today and I
realized that I forgot about this case.  This isn't much of a concern,
actually, and could be handled as follows:

(all responses are NXDOMAIN, with authority records below, first line
reads: "Query for bogus.org resulted in NXDOMAIN and authority record
returned was 'org.'  As a result, cache the fact that there is no
'bogus.org' domain.")

Query			Authority Record	Negative cache result
bogus.org		org.			!bogus.org.
bogus.bogus.org		org.			!bogus.bogus.org.
bogus.bogus		.			!bogus.
[or, using analogous in-addr examples]
bogus.arpa.		arpa.			!bogus.arpa.
bogus.in-addr.arpa.	arpa.			!bogus.in-addr.arpa.

In other words:
levels in address	levels in auth record	levels in cache result
N			N-1			N-1
N			<N-1			N

Hmm.  Does this work?

--Dave
-- 
System Administrator, Population Research Institute    barr@pop.psu.edu
A .sig quote is like a summer job, okay for a few months but not much more.
Newsgroups: comp.protocols.tcp-ip.domains
From: spcsup@solomon.technet.sg (Wong Fay Yu)
Subject: WinQVT/Net with NDIS drivers
X-Newsreader: TIN [version 1.1 PL8]
Date: Fri, 8 Jan 1993 08:54:36 GMT

I was trying to use WINQVT/NET with NDIS driver and dis_pkt.gup as the converter. 
It seems that WINQVT/NET needs to talk directly with the packet drivers.
Is there a packet driver to NDIS converter as well? I am also trying to configure it to work under Windows for Workgroup.

Thanks
Newsgroups: comp.protocols.tcp-ip.domains
From: grunert@jupiter.rz.Uni-Osnabrueck.DE (Joerg Grunert)
Subject: TCP/IP with XINU
Reply-To: grunert@jupiter.rz.uni-osnabrueck.de
Organization: University of Osnabrueck, FRG
Date: Thu, 7 Jan 1993 11:35:52 GMT

I want to use TCP/IP with the XINU system and a WD8003 Ethernet card.
If you have a source code in C please mail it to me.
It will help me also, when you mail me the Internetaddress of a FTP Server
where I can find the Programms.



Regards
     grunert@jupiter.rz.uni-osnabrueck.de
Newsgroups: comp.protocols.tcp-ip.domains
From: barr@pop.psu.edu (David Barr)
Subject: Re: CNAME records and MX/NS records
Organization: Penn State Population Research Institute
Date: Tue, 12 Jan 93 02:05:12 GMT

In article <1isteb$nmc@agate.berkeley.edu> cliff@garnet.berkeley.edu (Cliff Frost) writes:
>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

Ack!  I feel faint!!

How is this different than:

	sam.foo.bar.	A	1.2.3.4
	mary.foo.bar.	A	1.2.4.4
	client.foo.bar.	A	1.2.3.5
			MX	5 sam.foo.bar.
			MX	10 mary.foo.bar.

	or even:

	client.foo.bar.	MX	5 sam.foo.bar.
	client.foo.bar.	MX	5 mary.foo.bar.
	
>; 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?

--Dave
-- 
System Administrator, Population Research Institute    barr@pop.psu.edu
	What if there was no such thing as a hypothetical question?
Newsgroups: comp.protocols.tcp-ip.domains
From: phil@pex.eecs.nwu.edu (William LeFebvre)
Subject: does anyone want to do secondary service for us?
Organization: EECS Department, Northwestern University
Distribution: usa
Date: Tue, 5 Jan 1993 18:56:58 GMT

I'm looking for off-site secondary name service for the following
domains: eecs.nwu.edu, 5.105.129.in-addr.arpa, (other subnet domains
if we ever need to acquire them).  Any takers?  Please respond by
electronic mail.  Thanks.

		William LeFebvre
		Computing Facilities Manager and Analyst
		Department of Electrical Engineering and Computer Science
		Northwestern University
		<phil@eecs.nwu.edu>
Newsgroups: comp.protocols.tcp-ip.domains
From: rayan@gpu.utcs.utoronto.ca (Rayan Zachariassen)
Subject: Re: Negative caching
Organization: UTCS Public Access
Distribution: inet
Date: Wed, 13 Jan 1993 04:14:47 GMT

In <VIXIE.93Jan12114813@cognition.pa.dec.com> vixie@pa.dec.com (Paul A Vixie) writes:
>I actually
>ran UTBIND up until UCB 4.8.3 came out.  I would like 4.9.* to have in
>it all the best stuff from everywhere.

If you're volunteering, I'll give you the entire source tree, RCS files
and all.  You see the problem with integrating UTBIND mods is not so much
the big new features, its the half zillion bugfixes made to 4.8.1&2.  To
my dismay, most of those were explicitly rejected for 4.8.2&3 -- I remember
discussing it with Jim Bloom who was lead with Mike Karels at the time.
When .3 came out I strongly advised the locals to use it.  Unfortunately
it broke in the same ways .2 had. :-(  The locals fled back to UTBIND.
Point being that a major value in UTBIND is in the incremental fixes from
the base distributions.

rayan

ps: where's Jim Bloom these days?

Newsgroups: comp.protocols.tcp-ip.domains
From: rayan@gpu.utcs.utoronto.ca (Rayan Zachariassen)
Subject: Re: Negative caching
Organization: UTCS Public Access
Distribution: inet
Date: Tue, 12 Jan 1993 21:57:16 GMT

In <VIXIE.93Jan10123547@cognition.pa.dec.com> vixie@pa.dec.com (Paul A Vixie) writes:

>yikes.  negative cachine was in utbind, and yet nobody from ut answered
>my request for 4.9 alpha testers?

What Geoff said.  I'd have liked to poke at 4.9, I even went looking for it
one evening, but doing justice to an alpha or beta or even later on integrating
negative caching requires a serious time commitment (like, a dozen hours
or so) where time is already too scarce.

Besides, BIND and the DNS don't work too well.  I'd rather spend that time
telling someone how to do it better :-).  If only a sugardaddy would fund it.

Perhaps we should hold a bind-bash.... err, namedroppers lunch at Usenix.

rayan
Newsgroups: comp.protocols.tcp-ip.domains
From: smd@uunet.ca (Sean Doran)
Subject: Re: Negative caching
Organization: UUNET Canada
Date: Thu, 7 Jan 1993 23:09:47 GMT
Distribution: inet

Negative caching has been implemented and used in the real world for
quite some time.  One implementation can be found at
ftp.cs.toronto.edu in pub/utbind.tar.Z.  The CHANGES.UT file in the
utbind package is a bit dated, but worth reading as it discusses the
implementation details of various things like negative caching and
error caching.

	Sean.
Xref: sparky comp.protocols.tcp-ip.domains:808 comp.mail.uucp:2524 comp.mail.sendmail:3107 comp.unix.sys5.r4:1134 comp.unix.questions:15199
From: barrett@daisy.ee.und.ac.za (Alan P Barrett)
Newsgroups: comp.protocols.tcp-ip.domains,comp.mail.uucp,comp.mail.sendmail,comp.unix.sys5.r4,comp.unix.questions
Subject: Re: DNS name servers
Followup-To: comp.protocols.tcp-ip.domains
Date: 6 Jan 1993 09:21:16 +0200
Organization: Dept. Elec. Eng., Univ. Natal, Durban, S. Africa
Distribution: inet
NNTP-Posting-Host: daisy.ee.und.ac.za

[redirecting to comp.protocols.tcp-ip.domains --apb]

In article <C0ECnq.MLy@news.rn.com>,
larry@news.rn.com (Larry Snyder) writes:
> Since I am running a cached namesever, this data is lost when the
> machine is booted.  I guess I am asking is there anyway to keep a
> file on disk which is the result of continuous operation of uptime
> thus not requiring "so many lookups from other servers" after the
> machine has been rebooted.

Not with existing versions of bind -- you can dump the cache but you
can't reload it.  This might be a good new feature for 4.9.1, if anybody
wants to code it and if Paul agrees to take it.

--apb (Alan Barrett)
Newsgroups: comp.protocols.tcp-ip.domains
From: rickert@mp.cs.niu.edu (Neil Rickert)
Subject: Re: CNAME records and MX/NS records
Organization: Northern Illinois University
Date: Mon, 11 Jan 1993 20:30:58 GMT

In article <1993Jan11.192147.8578@maths.tcd.ie> ajudge@maths.tcd.ie (Alan Judge) writes:
>Am I correct in saying that the data in an MX or NS record may not
>be a CNAME, so that
>	foo.bar.		MX	mail.foo.bar.
>	mail.foo.bar.		CNAME	realhost.foo.bar.
>	(and similarly for ns.foo.bar.)
>is incorrect?

Yes.  This is incorrect.

>If so, what do people do when they want a nice logical separation
>between services and hosts.

The MX record should give you all the separation you need.  A user mails
to 'user@foo.bar' and the mail gets to 'realhost.foo.bar'.  Why do you
need any more separation than that?  Why is it easier to change a CNAME
record in your DNS than to change an MX record?  The change is still
the same in that it takes place in your local DNS data.  If you want
more levels of separation you should be able to use M4 macros to generate
all of your DNS data, and then hide whatever you want behind the M4
macros.

>                             Is it permissible/reasonable to have
>multiple A records for a single IP address?

It is permissible, and often done.  But this is unwise for dealing with
MX records.  At certain stages of processing, your mail software needs
to know if the MX record is pointing to itself.  It typically determines
this by a case-insensitive string comparison of its own hostname and
the hostname on the MX record.  You are apparently trying to defeat this
mechanism, possibly resulting in mishandling of mail.

>                                             Will anything get
>upset that a reverse lookup does not return the same name?

Probably not.  There is some software which follows a reverse lookup with
a forward lookup and cross checks.  But there is little if any which uses
the reverse lookup as a cross check on the forward lookup.

>Specifically, is something like
>	foo.bar.	MX	mail.foo.bar.
>	foo.bar.	NS	ns.foo.bar.
>
>	mail.foo.bar.		A	1.2.3.4
>	realname.foo.bar.	A	1.2.3.4
>
>	ns.foo.bar.		A	1.2.3.5
>	fred.foo.bar.		A	1.2.3.5
>
>a reasonable and sane thing to do.

This is permissible.  I won't comment on whether it is sane, but it
surely does not seem reasonable.  It sometimes makes sense to "hide"
the real name of a host from human users, so that configuration changes
can be done with a minimum of effort.  But you are "hiding" real names
from software which still needs to know those real names, so that if
you ever change the names you need to the do appropriate configuration
updates anyway.  I fail to see the purpose.
From: pstevens@Metaphor.COM (Paul Stevens)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Why can't my nslookup find any servers?
Date: 6 Jan 93 00:41:07 GMT
Reply-To: pstevens@Metaphor.COM (Paul Stevens)
Organization: m4

I must be missing something simple.  I have no problems translating
addresses via ftp or telnet but whenever I run nslookup I cat the error:

*** Can't find initialize address for server : Timed out

If I try to use the "root" command I get the error:

*** Can't find address for server sri-nic.arpa.: Timed out

However, I can ftp to sri-nic.arpa.  Can someone suggest what it is
that I am forgetting?  Thanks for your help!
+------------------------------------------------------------------------+

   Paul Stevens                        {apple|decwrl}!metaphor!pstevens
   Metaphor Computer Systems           pstevens@metaphor.com
   Mountain View, CA
From: barrett@daisy.ee.und.ac.za (Alan P Barrett)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Negative caching
Date: 7 Jan 1993 22:10:36 +0200
Organization: Dept. Elec. Eng., Univ. Natal, Durban, S. Africa
Distribution: inet
NNTP-Posting-Host: daisy.ee.und.ac.za

In article <#gb1Hfjgyb@atlantis.psu.edu>,
barr@pop.psu.edu (David Barr) writes:
> Hmm.  Does this work?

No.  You can make no assumptions about the validity of the domains
between the one you asked about and the one reported in the SOA record in
the NXDOMAIN error reply.  You know that the intermediate domains don't
have SOA records but you don't know if they exist.  If you asked for the
SOA record for one of these intermediate domains you might get either
NOERROR or NXDOMAIN, and until you try it you don't know which it will be.

--apb (Alan Barrett)
From: vixie@pa.dec.com (Paul A Vixie)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: does anyone want to do secondary service for us?
Date: 6 Jan 93 12:37:51
Organization: DEC Network Software Lab
Distribution: usa
NNTP-Posting-Host: cognition.pa.dec.com
In-reply-to: phil@pex.eecs.nwu.edu's message of Tue, 5 Jan 1993 18:56:58 GMT

phil,

uucp-gw-{1,2}.pa.dec.com are available for offsite secondaries.
to set it up, send mail to gw-dns@pa.dec.com before you tell the nic.

paul
--
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Don't be a rebel, or a conformist;
<vixie@pa.dec.com> decwrl!vixie		they're the same thing, anyway.  Find
<paul@vix.com>     vixie!paul		your own path, and stay on it."  -me
From: cliff@garnet.berkeley.edu (Cliff Frost)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: CNAME records and MX/NS records
Date: 11 Jan 1993 22:47:39 GMT
Organization: University of California, Berkeley
Distribution: world
NNTP-Posting-Host: garnet.berkeley.edu

|> >Specifically, is something like
|> >	foo.bar.	MX	mail.foo.bar.
|> >	foo.bar.	NS	ns.foo.bar.
|> >
|> >	mail.foo.bar.		A	1.2.3.4
|> >	realname.foo.bar.	A	1.2.3.4
|> >
|> >	ns.foo.bar.		A	1.2.3.5
|> >	fred.foo.bar.		A	1.2.3.5
|> >
|> >a reasonable and sane thing to do.
|> 
|> This is permissible.  I won't comment on whether it is sane, but it
|> surely does not seem reasonable.

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
	
; 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


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.

	Cliff Frost
	UC Berkeley