HDTenEightyP/NetNews huggingface dataset:
From: vixie@pa.dec.com (Paul A Vixie)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Why no MX records for .BITNET hosts?
Date: 27 Dec 92 12:26:27
Organization: DEC Network Software Lab
Distribution: world
	<VIXIE.92Dec26031209@cognition.pa.dec.com>
	<DWELLS.92Dec27141205@fits.cv.nrao.edu>
NNTP-Posting-Host: cognition.pa.dec.com
In-reply-to: dwells@fits.cv.nrao.edu's message of Sun, 27 Dec 1992 19:12:05 GMT

that's a good idea but any such domain needs to be run by the same people
who own the namespace.  for example, we have an "enet.dec.com" domain that
contains all the names of the "decnet phase iv" nodes on DEC's internal
network.  there is a single place to get the list of such nodes, and that
place happens to be inside of DEC.COM, and those people call their network
the "easynet", thus "node.ENET.DEC.COM".  

there's no domain under which we could put "uucp", other than perhaps
"UU.NET" and i don't think rick wants to do that since noone is paying
for it.  i could create a "uucp.dec.com" domain and tie it to a bunch of
MX RR's generated from the UUCP Map Database, but would i really want the
rest of the universe gating $-!$+ to $2<@$1.uucp.dec.com> ?  (NO!)  names
need to make sense in the context they appear in.  "uucp.dec.com"'s
innate meaning is "the uucp neighbors of dec.com".

likewise bitnet.  if the people who own the real bitnet name space are
willing to create a subdomain full of MX RR's, then the various bitnet-to-
internet gateways can rewrite into "user@node.BITNET.EDUCOM.EDU" rather
than "user@node.BITNET" or "user%node.BITNET@gateway" as they do now --
this would be absolutely ideal, since none of us outside of bitnet would
have to change our mailer configurations at all.

in the absense of that, the bitnet (or uucp) domains would have to be at
the top level.  i see no problem with this, but the people who own the
top level _do_ seem to have big problems with this.
--
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
Newsgroups: comp.protocols.tcp-ip.domains
From: dwells@fits.cv.nrao.edu (Don Wells)
Subject: Re: Why no MX records for .BITNET hosts?
Organization: nrao
	<DWELLS.92Dec27141205@fits.cv.nrao.edu>
	<VIXIE.92Dec27122627@cognition.pa.dec.com>
	<1992Dec28.045444.3467@news.arc.nasa.gov>
Date: Mon, 28 Dec 1992 19:05:00 GMT

In article <1992Dec28.045444.3467@news.arc.nasa.gov>
medin@dscs.arc.nasa.gov (Milo S. Medin) writes:

 MSM> The reason *.dnet.nasa.gov is convienent is obvious; the reason
 MSM> it's a kludge is because mail takes a suboptimal path for
 MSM> delivery to systems which are dual homed (IP and DECNET).  ..
 MSM> The right thing to do is to install individual MX records for
 MSM> the DECNET nodes that have native IP support, and maybe for all
 MSM> nodes at a site through a local mail relay.  

I suggest that, in addition to installing MX records for non-Internet
hosts, perhaps the right thing to do is to install individual CNAME
records for the DECNET nodes that have native IP support. Several
years ago I persuaded the NSI office to test this idea, and the
prototype resource record still exists. If you ask the DNS the
following question

;; QUESTIONS:
;;      nrao.span.nasa.gov, type = MX, class = IN

you get this answer:

;; ANSWERS:
nrao.span.nasa.gov.     3600    CNAME   cvax.cv.nrao.edu.

I used this CNAME resource record to show that SunOS sendmail would
deliver Email to CVAX (a 780 under VMS with TGV/Multinet IP support)
directly.  I am no longer able to verify this, as CVAX has gone to the
Valhalla of VAXen (and the MX records that once existed for CVAX in
the CV.NRAO.EDU nameserver have been deleted). I considered that first
experiment to be a success, but the technique would need to be tested
with other platforms and software implementations before it could be
generally adopted as a sufficient solution for dual-homed hosts.
--

Donald C. Wells             Associate Scientist        dwells@nrao.edu
National Radio Astronomy Observatory                   +1-804-296-0277
520 Edgemont Road                                 Fax= +1-804-296-0278
Charlottesville, Virginia 22903-2475 USA            78:31.1W, 38:02.2N
From: vixie@pa.dec.com (Paul A Vixie)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Why no MX records for .BITNET hosts?
Date: 26 Dec 92 03:12:09
Organization: DEC Network Software Lab
Distribution: world
NNTP-Posting-Host: cognition.pa.dec.com
In-reply-to: nelson@sun.soe.clarkson.edu's message of 25 Dec 92 05:24:33 GMT

> So why not have MX records whose preference value is based on the number
> of hops from the gateway machines?

Name service is not quite deterministic enough to create a fake domain
unless you have a screening IP router between you and the core and are
willing to run with a limited set of "forwarders".  Since the NIC has
been historically unwilling to create real domains for .BITNET (and .UUCP
for that matter), this would have to be done as a fake domain.

We do it here, of course :-).  uucp-gw-1.pa.dec.com's name server believes
that it is primary for .BITNET; the data is pulled over from BITSRV once
every second blue moon.  I bolt on a hack SOA and off it goes.  This
greatly simplifies connecting to .BITNET hosts since many of them are
dual-hosted (IP and BITNET) or have dual-hosted close neighbors -- it's
nice to use these hack MX's to force the mail to a host or its close
neighbor rather than gating all of it through a single relay.

If the new GSI NIC is willing to entertain a .BITNET domain, this could
be made a lot easier on everyone.  Likewise a .UUCP domain.  I will 
personally guarantee primary and secondary nameservers for each of them.
--
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
Newsgroups: comp.protocols.tcp-ip.domains
From: randy@psg.com (Randy Bush)
Subject: Re: Why not automatically do reverse domains?
Organization: Pacific Systems Group, Portland Oregon, US
Date: Fri, 1 Jan 1993 02:27:55 GMT

barrett@daisy.ee.und.ac.za (Alan P Barrett) writes:
> Note the illegal subnet mask.  You have only one bit for the subnet
> number, which means that you can have only two subnets, numbered 0 and 1.
> But subnet <all bits zero> and subnet <all bits one> are reserved
> [RFC1009, section 1.1.4] [RFC950, section 2.1].  So you don't have any
> non-reserved subnets.

Hi Alan.  We have an odder one here in RAINet.  We run a class B with a
netmask of ff.ff.ff.e0.  We have fund that some software breaks for subnets
where the high three bits of the last byte are zero, e.g. 147.28.42.0-31.

randy

-- 
randy@psg.com   ...!uunet!m2xenix!randy
Newsgroups: comp.protocols.tcp-ip.domains
From: medin@dscs.arc.nasa.gov (Milo S. Medin)
Subject: Re: Why no MX records for .BITNET hosts?
Organization: NASA Science Internet Office
Date: Mon, 28 Dec 1992 04:54:44 GMT

Well, we run the dnet.nasa.gov MX hack and associated forwarder.  We also
have a similar hack for span.nasa.gov that also works.  I agree that it's
a very convienent hack, but also agree that architecturally it's the wrong
thing.  Many if not most of the DECNET systems on the NSI-DECNET (what
SPAN was absorbed into) have IP connectivity as well as DECNET.  They
maintain DECNET access to talk to DECNET only sites and support
applications that depend on DECNET transport.

The reason *.dnet.nasa.gov is convienent is obvious; the reason it's 
a kludge is because mail takes a suboptimal path for delivery to systems
which are dual homed (IP and DECNET).  The mail relays for these fake
domains pull a fair amount of load.  And the DECNET users have to manually
route mail through the relays because DECNET mail doesn't support things
like MX records (of course, it also doesn't support multiple names per
node address or mail spooling as shipped either, so users aren't expecting
much I guess).   

The right thing to do is to install individual MX records for the DECNET 
nodes that have native IP support, and maybe for all nodes at a site
through a local mail relay.  This would reduce the load on the "default"
mail relays, and provide a more direct mail path as well.  This was the
initial plan in fact when we turned this service on, but it's a pain
to support since the MX records have to be manually configured, and 
the poor DECNET only users now have to know what locally specific syntax they
have to use for Internet relay.  This makes it difficult to write common
user services documentation, etc...

Anyways, it's proven so popular that it's just easier to try and harden
the mail relays so this works, and inform the users about the limits of
this approach.  It also winds up using more DECNET bandwidth than 
needed, but these days most if the DECNET rides over the same trunks 
that the IP traffic does via multiprotocol routers, so I guess it's
not that big a deal anyway.

The same may be true re: BITNET actually, since I gather most of the large
BITNET sites get their trunking via the Internet anyway, using this
RSCS over IP stuff.  I would expect the amount of BITNET traffic overall
to be dropping off, similar to what's been happening to DECNET, as
more hosts convert to native IP support (or the machines themselves are
scrapped and sent to surplus - anyone want a few 780's cheap?  :-))..

						Thanks,
						   Milo

PS The above of course is not the official position of anyone, much 
less the US Government, etc, etc...
From: lars@spectrum.CMC.COM (Lars Poulsen)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Why no MX records for .BITNET hosts?
Date: 30 Dec 92 06:35:02 GMT
Distribution: inet
Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA

In article <2320@hsdndev.UUCP> sob@hsdndev.UUCP (Scott Bradner) writes:
>From: sob@hsdndev.UUCP (Scott Bradner)
>Newsgroups: comp.protocols.tcp-ip.domains
>Subject: Re: Why no MX records for .BITNET hosts?
>Message-ID: <2320@hsdndev.UUCP>
>Date: 28 Dec 92 12:28:17 GMT
>
>Ok, lets see - here you have bitnet site HARVISR, you want this to be known
>as harvisr.bitnet and not harvisr.harvard.edu - tell me again where this is
>better.
> [... long tirade of politically correct stuff elided ...]
>in short, we have a naming structure (the DNS) to use anything else causes
>confusion today and even more confusion tomorrow as the connectivity
>changes.

Scott,
	The reason we install the fake .uucp and .bitnet domain is
because of people like yourself, who send out mail and news articles
that cannot be replied to, otherwise.

	I agree with your long list of reasons why we should not need
such things in the perfect world. But in the real world, software is
often buggy and misconfigured, and hardening the infrastructure so that
it still works, even in the presence of such errors, helps stave off
pressure to "replace this IP stuff with something based on REAL (tm)
standards, such as X.400".

	I agree that the host should be known as harvisr.harvard.edu;
but given that one may occasionally see mail emerge from such a host
labeled with a "From: xxx@HARVISR.BITNET" it is desirable that mail to
that (incorrect) address can be delivered.

	By now, everyone has seen the religious argument that comes up
everytime this can of worms is opened. Let me just conclude by
mentioning that my BIND, too, believes itself to be authoritative for
.BITNET and happily will supply a wildcard MX to anyone who asks for it.
Like Vixie, I would prefer if this were run centrally, but I understand
the problem.
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256
Newsgroups: comp.protocols.tcp-ip.domains
From: imp@boulder.parcplace.com (Warner Losh)
Subject: Re: Why not automatically do reverse domains?
Organization: ParcPlace Boulder
Distribution: inet
Date: Sat, 26 Dec 1992 19:00:03 GMT

In article <1992Dec21.195422.19764@eecs.nwu.edu> phil@pex.eecs.nwu.edu
(William LeFebvre) writes: 
>("delta.eecs.nwu.edu. IN CNAME eecs.nwu.edu.") since I do not
>want the domain name to be the machine's canonical name (that would
>screw up other things).

What does that screw up.  I'm curious....

Warner
-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.
From: nelson@crynwr.com (Russell Nelson)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: I asked the wrong question (Why no MX for .BITNET)
Distribution: world
Date: Tue, 29 Dec 92 04:16:29 GMT
Organization: Crynwr Software

I can see that I asked the wrong question.  Yes, .BITNET and .UUCP
are "wrong" in the sense that they dictate a particular transport,
and that is not what the DNS is for.  The question that I *really*
meant to ask was "How can a site that currently receives all its mail
over BITNET convert to receiving mail over the Internet"?  And of
course the answer to that is, "Well, if there were MX records for
.BITNET, then all you'd have to do is change that MX record".

Yes, and if pigs had wings they could fly.

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.
Newsgroups: comp.protocols.tcp-ip.domains
From: karl@ddsw1.mcs.com (Karl Denninger)
Subject: Re: Why not automatically do reverse domains?
Summary: Consider a few other cases
Date: Wed, 30 Dec 1992 18:10:56 GMT
Distribution: inet
Organization: MCSNet, Chicago, IL

In article <BzvrG3.6t4@boulder.parcplace.com> imp@boulder.parcplace.com (Warner Losh) writes:
>In article <1992Dec21.195422.19764@eecs.nwu.edu> phil@pex.eecs.nwu.edu
>(William LeFebvre) writes: 
>>("delta.eecs.nwu.edu. IN CNAME eecs.nwu.edu.") since I do not
>>want the domain name to be the machine's canonical name (that would
>>screw up other things).
>
>What does that screw up.  I'm curious....

Uh, I can think of a number of things (including possibly mail routing) and
the fact that its not generally a "good thing" to have a domain name be a
canonical host name.

The other pathological case in which this is bad news is where the subnet
mask is not a byte-boundary.  Consider the following (ACTUAL case from my
site):

192.160.127	- Class C address assigned to my domain (MCS.COM)

Subnet mask used here:	255.255.255.128		- Note the odd alignment!

However, 127.160.192.in-addr.arpa IS byte-aligned, and due to the way PTR
domains work (the in-addr.arpa botch) it HAS to be.  Therefore, if I were to
delegate control of the "high order" subnet of my class "C" to someone else,
how would they do the PTR records?

The answer is -- they couldn't.  

This is one of the problems with PTR records, by the way.  If you use a
non-byte subnet mask you have problems coordinating these records.  My
solution (since I give out the high order addresses to those persons who
want to SL/IP or PPP into my system and don't have their own address space)
is to require them to tell me what their reverse map >really< is, and I have
to maintain it here.  (I have to do >some< kind of bit-aligned mask for
"foreign" users as I want to filter packets from them to prevent them from
going places I don't want them to).

Note that I currently am not on the direct cable.  But I will be within a
couple of months with luck, and then the problem is "real" (right now I act
like it is having been indoctrinated into doing things this way ;-)

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Data Line: [+1 312 248-0900] Anon. arch. (nuucp) 00:00-06:00 C[SD]T
Request file: /u/public/sources/DIRECTORY/README for instructions
Newsgroups: comp.protocols.tcp-ip.domains
From: phil@pex.eecs.nwu.edu (William LeFebvre)
Subject: Re: Why not automatically do reverse domains?
Organization: EECS Department, Northwestern University
Distribution: inet
Date: Mon, 21 Dec 1992 19:54:22 GMT

In article <1gr3hjINNnjk@uniwa.uwa.edu.au> craig@ec.uwa.oz.au (Craig Richmond - division) writes:
>nelson@sun.soe.clarkson.edu (Russ Nelson) writes:
>
>>Why doesn't BIND automatically generate a PTR record for every A
>>record it sees?  All the nameserver tools I've seen perform that
>>function, why doesn't BIND?  Is there some subtlety that doesn't meet
>>my eye?
>
>Multiple names for IP numbers.  Which reverse name lookup should it use?
>(Mind you, not that many machines couldn't use an A and a CNAME record
>rather than 2 A addresses)

Actually, quite a few can't!  There is a very common situation which
can only be resolved by providing differently named A records for the
same address.

I have a machine whose canonical name is "delta.eecs.nwu.edu".  It is
also the main departmental computer, the mail hub, the news hub, and
a few other things.  For convenience sake, I want it to be known by
our domain name "eecs.nwu.edu".  I want people from across the world
to be able to type, say, "ftp eecs.nwu.edu" and connect to THIS machine.

But I do NOT want its canonical name to be eecs.nwu.edu.  I cannot
use "eecs.nwu.edu. IN CNAME delta.eecs.nwu.edu." because "eecs.nwu.edu."
also has an SOA record and NS and MX records associated with it.  The only
solution is "eecs.nwu.edu. IN A 129.105.5.103".  I can't go the other
way ("delta.eecs.nwu.edu. IN CNAME eecs.nwu.edu.") since I do not
want the domain name to be the machine's canonical name (that would
screw up other things).

		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: nelson@sun.soe.clarkson.edu (Russ Nelson)
Subject: Why no MX records for .BITNET hosts?
Organization: Clarkson University, Potsdam NY
Distribution: comp
Date: Fri, 25 Dec 1992 05:24:33 GMT

Yes, I realize that .BITNET is a fake domain.  But there aren't all
that many BITNET hosts, so technologically, a .BITNET domain is
doable.  As I understand BITNET, it is a store and forward network
operating at 9600 baud.  So, a message going from the Internet to
BITNET should be inserted as near its destination as possible.

There are also a lot of hosts that are dual-homed, on the Internet and
BITNET.

So why not have MX records whose preference value is based on the number
of hops from the gateway machines?

--
--russ <nelson@sun.soe.clarkson.edu> Businesses persuade; Governments force.
From: barrett@daisy.ee.und.ac.za (Alan P Barrett)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Why not automatically do reverse domains?
Date: 30 Dec 1992 22:32:59 +0200
Organization: Dept. Elec. Eng., Univ. Natal, Durban, S. Africa
Distribution: inet
NNTP-Posting-Host: daisy.ee.und.ac.za

In article <C033uA.7CB@ddsw1.mcs.com>,
karl@ddsw1.mcs.com (Karl Denninger) writes:
> The other pathological case in which this is bad news is where the subnet
> mask is not a byte-boundary.  Consider the following (ACTUAL case from my
> site):
>
> 192.160.127	- Class C address assigned to my domain (MCS.COM)
>
> Subnet mask used here:	255.255.255.128		- Note the odd alignment!

Note the illegal subnet mask.  You have only one bit for the subnet
number, which means that you can have only two subnets, numbered 0 and 1.
But subnet <all bits zero> and subnet <all bits one> are reserved
[RFC1009, section 1.1.4] [RFC950, section 2.1].  So you don't have any
non-reserved subnets.

> However, 127.160.192.in-addr.arpa IS byte-aligned, and due to the way PTR
> domains work (the in-addr.arpa botch) it HAS to be.  Therefore, if I were to
> delegate control of the "high order" subnet of my class "C" to someone else,
> how would they do the PTR records?
>
> The answer is -- they couldn't.  

It's very clumsy and inconvenient, but it is possible.

In a zone controlled by you, you say:

128.127.160.192.in-addr.arpa. CNAME 128.some-zone-controlled-by-them.
129.127.160.192.in-addr.arpa. CNAME 129.some-zone-controlled-by-them.
130.127.160.192.in-addr.arpa. CNAME 130.some-zone-controlled-by-them.
etc.

In a zone controlled by them, they say:

128.some-zone-controlled-by-them. PTR foo.some-other-zone.
129.some-zone-controlled-by-them. PTR bar.some-other-zone.
130.some-zone-controlled-by-them. PTR baz.some-other-zone.
etc.

Unfortunately, this method requires as many CNAME records as there are
delegated addresses.  There is no such thing as a wildcard CNAME record
(you can put a wildcard on the left hand side, but not on the right
hand side).

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za                    Bang: m2xenix!undeed!barrett
From: jbvb@vax.ftp.com (James B. VanBokkelen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: PCS WITH DUPLICATE TCP ADDRESSES
Keywords: bootp
Date: 28 Dec 92 17:39:08 GMT
Reply-To: jbvb@ftp.com
Organization: FTP Software, Inc., Wakefield, MA
Nntp-Software: PC/TCP NNTP

In article <1992Dec22.191907.23824@mmm.serc.3m.com> ccg@tcdsp1.mmm.com ("Charles Ganzhorn") writes:

    BOOTP is major bad idea.  You have to configure your routers to pass the
    silly stuff 'cuz you won't necessarily have a load host in all subnets.
    This means you lose the usual isolation that IP provides you between 
    subnets (BOOTP uses a global IP broadcast).

Depends on your perspective.  Setting up IP Routers to forward BOOTP packets
may well be easier than maintaining an RARP server on every LAN cable.  Doing
all IP address configuration on a small set of servers may be easier than
visiting each new system as it's installed (and each time it gets so broken
that you can't log in via Telnet).  The broadcast is only necessary on the
cable which the querying host is attached to - the routers can forward the
requests to the servers as unicasts.
    
    Also, if your BOOTP logs all requests, a station whose download doesn't
    get satisfied typically requests every five seconds and ends up filling
    up the logs on systems.
    
This sounds more like a server software issue than a problem with the
protocol.  I wouldn't turn off logging of failed 'su' attempts, for instance.

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488
Newsgroups: comp.protocols.tcp-ip
From: oldera@twg.com (Ed Alcoff -  Prod Mtg)
Subject: Re: RMON-Compliant Ethernet Monitors
Organization: The Wollongong Group, Palo Alto, CA
Date: Tue, 29 Dec 1992 17:44:29 GMT

In article <1hpkfvINN3aj@mercury.delmarva.com> scoggin@mercury.delmarva.com (John K. Scoggin) writes:
>Does anyone have a list of RMON-compliant ethernet monitors?  I am familiar
>with Hewlett-Packard, TTC, and Novell - are there others?
>
>Many thanks.  I will post a summary.
>

Axon Networks in Watertown, MA. has a RMON monitor and applications
to go with it for Sun.  They can be reached at (617) 923-2205.

Metrix has several tools, some of which use RMON, and theirs is
a 'software only' solution versus a standalone hardware box.  They
can be reached at (603) 888-7000.

Happy Holidays,

Ed Alcoff
Product Line Manager
The Wollongong Group, Inc.

#incl std.disc - I am not associated with either company mentioned
and these are my opinions and not those of my employer.

P.S.- I am a Beta test site for Metrix, however.

Newsgroups: comp.protocols.tcp-ip,comp.unix.bsd