deke@ee.rochester.edu (Dikran Kassabian) (08/10/90)
I see an increasing number of ftp connections to a UNIX box in our domain
that provides anonymous ftp, and a fair number of telnet connections
from colleagues of the faculty members here. What's disturbing is that
my log files show a goodly 1/4 of the non-local entries to have no inverse
mappings... that is to say I see an IP address in the log file rather than
a FQDN. I see about 45 such entries from about 20 addresses over the last
month.
A brief investigation this morning via nslookup and whois 'net xxx.yyy' tells
me a bit more; some small percentage of the requests to reverse resolve the
address are timing out or failing to locate the proper server, but the
vast majority are reported as a "Non-existent domain" by nslookup, even though
whois 'net xxx[.yyy[.zzz]]' shows that the non-subnetted network number is
in fact assigned. In other words, I see lots of what appears to be improperly
handled class C subnets of class B networks -- no inverse mappings, and
perhaps no domain name server at all.
Are others seeing this? What do you do about it? Ignore it? Send mail
to the hostmaster or postmaster of the parent registered net? How about
refusing such connections altogether when the address doesn't inverse map?
I'm willing to continue ignoring this for now, but I'd like to hear from
others... what is the Right Thing To DO? I guess I'm hoping someone more
knowledgeable than I will quote an RFC and make it all better :-\
^Deke Kassabian, deke@ee.rochester.edu or ur-valhalla!deke
Univ of Rochester, Dept of EE, Rochester, NY 14627 (+1 716-275-3106)paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO) (08/10/90)
deke@ee.rochester.edu (Dikran Kassabian) writes: >[Re: non-existent in-addr.arpa entries] > >Are others seeing this? What do you do about it? Ignore it? Send mail >to the hostmaster or postmaster of the parent registered net? How about >refusing such connections altogether when the address doesn't inverse map? >I'm willing to continue ignoring this for now, but I'd like to hear from >others... what is the Right Thing To DO? I guess I'm hoping someone more >knowledgeable than I will quote an RFC and make it all better :-\ On the machines I administer, ftp/telnet/rsh/etc have been modified to reject connections from IP addresses that can't be inverse mapped. An informative message is printed in some cases (ftp) that says why and what to do about it: 421 Cannot map IP address into host name. We only accept FTP connections from recognized sites. Get your system administrator to fix your domain servers or try again in a few minutes when the DNS has the translation. Uunet does about the same thing. /pbp -- Paul Pomes UUCP: {att,iuvax,uunet}!uiucuxc!paul Internet, BITNET: paul@uxc.cso.uiuc.edu US Mail: UofIllinois, CSO, 1304 W Springfield Ave, Urbana, IL 61801-2987
paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO) (08/11/90)
Here are my changes to ftpd.c (V5.28 from uunet) that implements command logging, enhanced local access, and restricted use if the IP inverse mapping doesn't exist. /pbp ======== *** ftpd.c- Fri Aug 10 16:33:09 1990 --- ftpd.c Fri Aug 10 16:39:05 1990 *************** *** 47,52 **** --- 47,53 ---- #include <stdio.h> #include <signal.h> #include <pwd.h> + #include <grp.h> #include <setjmp.h> #include <netdb.h> #include <errno.h> *************** *** 53,58 **** --- 54,60 ---- #include <strings.h> #include <syslog.h> #include <varargs.h> + #include <nlist.h> #include "pathnames.h" #ifndef MAXHOSTNAMELEN *************** *** 64,74 **** typedef int uid_t; typedef int gid_t; #endif ! /* ! * File containing login names ! * NOT to be used on this machine. ! * Commonly used to disallow uucp. ! */ extern int errno; extern char *sys_errlist[]; extern int sys_nerr; --- 66,72 ---- typedef int uid_t; typedef int gid_t; #endif ! extern int errno; extern char *sys_errlist[]; extern int sys_nerr; *************** *** 445,451 **** --- 443,471 ---- } } login_attempts = 0; /* this time successful */ + #if defined(UICSO) && defined(LOCAL_GROUP) + # ifndef MYDOMAIN + # define MYDOMAIN ".uiuc.edu" + # endif /* MYDOMAIN */ + if (guest) { + struct group *grp; + int rlen = strlen (remotehost); + int mlen = strlen (MYDOMAIN); + + if (rlen > mlen && + strcasecmp(remotehost + (rlen-mlen), MYDOMAIN) == 0) { + if ((grp = getgrnam(LOCAL_GROUP)) == NULL) + syslog(LOG_ERR, "Group %s: %m", LOCAL_GROUP); + else if (setegid(grp->gr_gid) == -1) + syslog(LOG_ERR, "Setegid failed: %m"); + } + else + (void) setegid((gid_t)pw->pw_gid); + } + else + #else /* !UICSO || !LOCAL_GROUP */ (void) setegid((gid_t)pw->pw_gid); + #endif /* UICSO && LOCAL_GROUP */ (void) initgroups(pw->pw_name, pw->pw_gid); /* open wtmp before chroot */ *************** *** 559,564 **** --- 579,585 ---- data = -1; pdata = -1; done: + syslog(LOG_INFO, "Retrieve %s %ld", name, st.st_size); (*closefunc)(fin); } *************** *** 626,631 **** --- 647,655 ---- pdata = -1; done: (*closefunc)(fout); + if (stat(name, &st) != 0) + st.st_size = -1; + syslog(LOG_INFO, "Stored %s %ld", name, st.st_size); } FILE * *************** *** 1059,1064 **** --- 1083,1089 ---- return; } done: + syslog(LOG_INFO, "Delete %s", name); ack("DELE"); } *************** *** 1069,1074 **** --- 1094,1100 ---- perror_reply(550, path); else ack("CWD"); + syslog(LOG_INFO, "Chdir %s", path); } makedir(name) *************** *** 1078,1083 **** --- 1104,1110 ---- perror_reply(550, name); else reply(257, "MKD command successful."); + syslog(LOG_INFO, "Mkdir %s", name); } removedir(name) *************** *** 1087,1092 **** --- 1114,1120 ---- perror_reply(550, name); else ack("RMD"); + syslog(LOG_INFO, "Rmdir %s", name); } pwd() *************** *** 1121,1126 **** --- 1149,1155 ---- perror_reply(550, "rename"); else ack("RNTO"); + syslog(LOG_INFO, "Rename from %s to %s", from, to); } dolog(sin) *************** *** 1128,1151 **** { struct hostent *hp = gethostbyaddr((char *)&sin->sin_addr, sizeof (struct in_addr), AF_INET); - time_t t, time(); - extern char *ctime(); if (hp) (void) strncpy(remotehost, hp->h_name, sizeof (remotehost)); ! else (void) strncpy(remotehost, inet_ntoa(sin->sin_addr), sizeof (remotehost)); #ifdef SETPROCTITLE sprintf(proctitle, "%s: connected", remotehost); setproctitle(proctitle); #endif /* SETPROCTITLE */ ! if (logging) { ! t = time((time_t *) 0); ! syslog(LOG_INFO, "connection from %s at %s", ! remotehost, ctime(&t)); ! } } /* --- 1157,1182 ---- { struct hostent *hp = gethostbyaddr((char *)&sin->sin_addr, sizeof (struct in_addr), AF_INET); if (hp) (void) strncpy(remotehost, hp->h_name, sizeof (remotehost)); ! else { (void) strncpy(remotehost, inet_ntoa(sin->sin_addr), sizeof (remotehost)); + { + lreply(421, "Cannot map IP address into host name. We only accept FTP connections\n from recognized sites. Get your system administrator to fix your domain\n servers or try again in a few minutes when the DNS has the translation."); + reply(421, "FTP connection refused, closing connection."); + syslog(LOG_INFO,"connection refused (Internet un-registered) from %s", remotehost); + } + exit(1); + } #ifdef SETPROCTITLE sprintf(proctitle, "%s: connected", remotehost); setproctitle(proctitle); #endif /* SETPROCTITLE */ ! if (logging) ! syslog(LOG_INFO,"connection from %s", remotehost); } /* -- Paul Pomes UUCP: {att,iuvax,uunet}!uiucuxc!paul Internet, BITNET: paul@uxc.cso.uiuc.edu US Mail: UofIllinois, CSO, 1304 W Springfield Ave, Urbana, IL 61801-2987
merlyn@iwarp.intel.com (Randal Schwartz) (08/11/90)
In article <1990Aug10.162416.22650@ux1.cso.uiuc.edu>, paul@uxc (Paul Pomes - UofIllinois CSO) writes: | On the machines I administer, ftp/telnet/rsh/etc have been modified to reject | connections from IP addresses that can't be inverse mapped. An informative | message is printed in some cases (ftp) that says why and what to do about it: | | 421 Cannot map IP address into host name. We only accept FTP connections | from recognized sites. Get your system administrator to fix your domain | servers or try again in a few minutes when the DNS has the translation. | | Uunet does about the same thing. Yeah, and they both piss me off, because they don't take into consideration real-world politics and staffing. Before iWarp got our own class B, we were a range of addresses (pseudo class C) under Intel's class B, which was administered by one overworked guy (hi Jeff). Jeff had not gotten around to asking CSNET (yet another level of indirection and administration to deal with) to provide in-addr.arpa service for us, so I was stuck out in the cold. I could get out on the net (because the routes were right), but uunet and a few others kept bumping me. And there wasn't anything I could do about it. Course, now, I got my own class B, and in-addr seems to be working fine (although CSNET is still handling it for me, and I'm pretty close to taking it over myself). I can imagine *very* similar circumstances in most of the big companies (company gets class B for "everyone" because of politics, but doesn't support it). So, once again... *don't* kick us off because of things we cannot control! (And yeah, I *am* the friggin admin, so telling me to see my admin doesn't help!) Just another disgruntled admin playing "technically feasible" against "politically correct", -- /=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\ | on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn | \=Cute Quote: "Welcome to Portland, Oregon, home of the California Raisins!"=/
kannan@osc.edu (Kannan Varadhan) (08/11/90)
Thus spake merlyn@iwarp.intel.com (Randal Schwartz) >In article <1990Aug10.162416.22650@ux1.cso.uiuc.edu>, paul@uxc (Paul Pomes - UofIllinois CSO) writes: >| On the machines I administer, ftp/telnet/rsh/etc have been modified to reject >| connections from IP addresses that can't be inverse mapped. An informative >| message is printed in some cases (ftp) that says why and what to do about it: > >Yeah, and they both piss me off, because they don't take into consideration >real-world politics and staffing. And, somehow, it seems to go against our grain of "be conservative in what you do, be liberal in what you accept from others"[%] policy. I have come across a lot of people who try very hard, but don't always succeed in getting things right, or have a lot of trouble understanding the concept. Penalising them in this rather harsh manner seems somewhat rude to me, and may not be quite the way to coerce people to use the DNS, or to get them to straighten out their end of things. Kannan [%] Quote from RFC793, by Jon Postel. -- Kannan Varadhan, Internet Engineer, OARNet Ohio Supercomputer Center, Columbus, OH 43212 +1 (614) 292-4137 email: kannan@oar.net | osu-cis!malgudi.oar.net!kannan
nipper@iramu1.ira.uka.de (Arnold Nipper) (08/11/90)
In article <1990Aug10.152144.17260@ee.rochester.edu> deke@ee.rochester.edu (Dikran Kassabian) writes: >I see an increasing number of ftp connections to a UNIX box in our domain >that provides anonymous ftp, and a fair number of telnet connections why so much cry about it?? You can patch the ftpd to ignore connections not to be able to give an inverse mapping, or am I wrong? As far as I know it's an option given via the Makefile. Arnold ******************************************************************************** Arnold Nipper *** Universitaet Karlsruhe, Am Fasanengarten 5 * nipper@ira.uka.de XLINK, Inst. fuer Betr.- und Dialogsysteme, D-7500 Karlsruhe * +49 721 608 4331 ******************************************************************************** PS: Where are the proper hacks for ULRTIX 4.1 (security ....) well I just thouhgt to cc it ,but I forgot the security options.
emv@math.lsa.umich.edu (Edward Vielmetti) (08/11/90)
In article <1990Aug10.222515.12542@iwarp.intel.com> merlyn@iwarp.intel.com (Randal Schwartz) writes:
I could get out on the net (because the routes were right), but uunet
and a few others kept bumping me. And there wasn't anything I could
do about it....
So, once again... *don't* kick us off because of things we cannot
control! (And yeah, I *am* the friggin admin, so telling me to see my
admin doesn't help!)
I see anonymous FTP servers that bounce connections from people
without functioning .in-addr.arpa pointer records as the rough moral
equivalent of the Rabid Rerouters (and Domain Absolutist Rabid
Rerouters etc) discussed not so long ago in comp.mail.uucp. It's not
appropriate for everyone in the world to run them, but the presence of
a few of them in the world calls attention to the problem and are
a good thing On The Whole even though in some cases some people are
inconvenienced.
Besides it provides a real easy touchstone on whether your in-addr
stuff is working ok, just FTP to uunet and see if you get in....
--Ed
Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
Da ich in der naeheren Umgebung nicht gefunden habe,
habe ich ihn aus USA geftp't.bob@MorningStar.Com (Bob Sutterfield) (08/13/90)
I'd rather see a few sites with misconfigured inverse mappings becoming temporarily inconvenienced, than the entire world thrown into a tailspin because some yahoo laid UUNET low via a security hole that could have been avoided by disallowing non-inverse-mapped access.
dan@SCI.CCNY.CUNY.EDU (Dan Schlitt) (08/14/90)
Bob Sutterfield writes, I'd rather see a few sites with misconfigured inverse mappings becoming temporarily inconvenienced, than the entire world thrown into a tailspin because some yahoo laid UUNET low via a security hole that could have been avoided by disallowing non-inverse-mapped access. Amen. The "liberal ..... conservative ..." bit quoted by others applies to datagrams and messages. Certainly no one intends for it to apply to authentication. Otherwise we would see telnets that do soundex matching of loginnames and hosts treated as trusted by default by rlogin. /dan
Makey@Logicon.COM (Jeff Makey) (08/14/90)
In article <BOB.90Aug13093801@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes: >I'd rather see a few sites with misconfigured inverse mappings >becoming temporarily inconvenienced, than the entire world thrown into >a tailspin because some yahoo laid UUNET low via a security hole that >could have been avoided by disallowing non-inverse-mapped access. Bob, I hope you aren't really so naive as to believe that inverse mappings are somehow secure, that the mere existence in some resolver's cache of an .IN-ADDR.ARPA record for an internet address means that activity apparently emanating from such an address can always be traced to the person responsible. The idea that "the entire world" depends upon uunet is pretty amusing. It bothers me that I didn't see any smileys nor any hint that they were implied. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
deke@EE.ROCHESTER.EDU (Dikran Kassabian) (08/14/90)
In <1990Aug10.152144.17260@ee.rochester.edu> I asked about handling connection requests from addresses that my nameserver can't inverse map to a hostname. We've seen quote a lot of responses to my original post. Its an old subject, I know, but I wanted to hear some new perspectives on it. I thank everyone for sharing their point of view. There seems not to be an objective Right or Wrong, but rather many opinions expressed. I quote several here -- although edited, I have attempted to take nothing out of context. ------------ In email message <9008102044.AA22223@uunet.uu.net> Andrew Partan writes: > > We refuse connections from sites without an in-addr.arpa domain by > replying: > Can't map <addr> to a valid hostname. > We only allow ftp from recognized sites. > Get your system administrator to fix your domain servers. > > and then send them attached mail if they complain. > > [ form letter deleted ] Andrew, I hope you don't mind my quoting your mail here. It seems directly relevant. I mentioned this sort of thing in my original post. Not surprisingly, I got the idea from uunet in the first place. ------------ In <789@malgudi.osc.edu> Kannan Varadhan writes: > > somehow, it seems to go against our grain of "be conservative in > what you do, be liberal in what you accept from others"[%] policy. > > I have come across a lot of people who try very hard, but don't always > succeed in getting things right, or have a lot of trouble understanding > the concept. Penalising them in this rather harsh manner seems > somewhat rude to me, and may not be quite the way to coerce people to > use the DNS, or to get them to straighten out their end of things. > >[%] Quote from RFC793, by Jon Postel. ------------ In <BOB.90Aug13093801@volitans.MorningStar.Com> Bob Sutterfield writes: > > I'd rather see a few sites with misconfigured inverse mappings > becoming temporarily inconvenienced, than the entire world thrown into > a tailspin because some yahoo laid UUNET low via a security hole that > could have been avoided by disallowing non-inverse-mapped access. ------------ In <739@logicon.com> Jeff Makey writes: > > Bob, I hope you aren't really so naive as to believe that inverse > mappings are somehow secure, that the mere existence in some > resolver's cache of an .IN-ADDR.ARPA record for an internet address > means that activity apparently emanating from such an address can > always be traced to the person responsible. I dunno. It depends on your intentions. I'm not looking for strict authentication, I just want to know for the most part who is on the other end of the line. When some sales critter calls me up and says it's representing Yoyodyne International, I (perhaps foolishly :-) believe it. It's at least tried to identify itself. If it called me and asked me all sorts of questions, and yet *refused* to identify itself (or wasn't able), I'd be less inclined to stay on the line. > The idea that "the entire world" depends upon uunet is pretty amusing. > It bothers me that I didn't see any smileys nor any hint that they > were implied. :-) You just couldn't see my face from where you were sitting. I was smiling. I have no idea whether Bob was, too. But a swamped or comatose uunet would certainly affect lots of people, although I agree it would be far from the entire world. ------------ In <9008131945.AA03144@sci.ccny.cuny.edu> Dan Schlitt writes: > > The "liberal ..... conservative ..." bit quoted by others > applies to datagrams and messages. Certainly no one intends for it to > apply to authentication. Agreed. The quote is from RFC793, which is for TCP. Its application to this situation is questionable, in my opinion. ------------ In <3675.650616417@cs.nott.ac.uk> Julian Onions writes: > > insisting on reverse lookup gives you two things. > > 1) It forces maintainers to put more effort into getting their DNS > system setup correctly. If they can't talk to you, and your important > enough it is a good impetus. If people can survive with the status > quo, there is no incentive to put effort into fixing broken things. > > 2) It is not solid, but it does give you an idea where to look when > trouble happens. If you can't reverse lookup an address, then you are > really stuck. If you can reverse lookup an address, you at least have > a starting point and it means if someone is trying to mess you about, > they have to work that much harder. > > You can't force people to register themselves, but you can make it > dammed awkward for them. From my limited experience of Internet DNS > usage, it appears to be getting more robust. Now is probably the time > to turn the screws down tighter and make people put more effort into > getting all their records straight. ------------ In <90.223.03:51:07@ira.uka.de> Arnold Nipper writes: > > why so much cry about it?? You can patch the ftpd to ignore connections > not to be able to give an inverse mapping, or am I wrong? As far as I know > it's an option given via the Makefile. Sorry, I didn't mean to cry.. )-; ------------ In <EMV.90Aug11005844@urania.math.lsa.umich.edu> Edward Vielmetti writes: > > I see anonymous FTP servers that bounce connections from people > without functioning .in-addr.arpa pointer records as the rough moral > equivalent of the Rabid Rerouters (and Domain Absolutist Rabid > Rerouters etc) discussed not so long ago in comp.mail.uucp. It's not > appropriate for everyone in the world to run them, but the presence of > a few of them in the world calls attention to the problem and are > a good thing On The Whole even though in some cases some people are > inconvenienced. My site isn't some wonderful archive server. If I don't allow connections under certain circumstances, nothing monumental is lost. > > Besides it provides a real easy touchstone on whether your in-addr > stuff is working ok, just FTP to uunet and see if you get in.... So you mean I'd actually be *helping* folks out! I think I've been persuaded :-) ------------ In <1990Aug10.214533.18331@ux1.cso.uiuc.edu> Paul Pomes includes ftpd.c diffs: > > Here are my changes to ftpd.c (V5.28 from uunet) that implements command > logging, enhanced local access, and restricted use if the IP inverse mapping > doesn't exist. > > [diffs deleted] This may be just the thing. I've not decided for sure, but its likely I'll use this scheme. No one has said that it would be a violation of the specifications for telnet or ftp... that was what my ear was particularly tuned for. Thanks, ^Deke Kassabian, deke@ee.rochester.edu or ur-valhalla!deke Univ of Rochester, Dept of EE, Rochester, NY 14627 (+1 716-275-3106)
Makey@Logicon.COM (Jeff Makey) (08/16/90)
In article <9008141419.AA03517@socrates.ee.rochester.edu> deke@EE.ROCHESTER.EDU (Dikran Kassabian) writes: >I'm not looking for strict >authentication, I just want to know for the most part who is on the other >end of the line. Considering that internet numbers are much more difficult to forge than .IN-ADDR.ARPA entries, you would be better off sticking with the IP address as a form of identification. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
lindberg@cs.chalmers.se (Gunnar Lindberg) (08/28/90)
Now, I came late into this, so it's probably mentioned already. Anyway: In article <3675.650616417@cs.nott.ac.uk> j.onions@computer-science.nottingham.ac.uk (Julian Onions) writes: > However, insisting on reverse lookup gives you two things. >1) It forces maintainers to put more effort into getting their DNS >system setup correctly. If they can't talk to you, and your important >enough it is a good impetus. If people can survive with the status >quo, there is no incentive to put effort into fixing broken things. Unfortunately, not everybody can get registered in the .IN-ADDR.ARPA domain, at least not today. To get a NS(.IN-ADDR.ARPA) registered you need to have "Connected Status", which in turn implies that you're allowed to access the Internet - the US Internet! Exactly what the requirements for "Connected Status" are I don't know, but I don't think you get it just by asking. On the Swedish IP network there are quite a few organizations that will never get "Connected Status" - some of them probably don't care, since all they need is access to their cooperating universities. If we were to enforce DNS lookups, all such cooperation would be impossible! Of course, there is the other way to solve the problem, i.e. to drop the requirement for "Connected Status" to register a NS(.IN-ADDR.ARPA) (the actual NS host will need to have "Connected Status", but that's another story). I would be surprised if this suggestion is in any way new, but I wanted to mention it anyway. Gunnar Lindberg Chalmers University of Technology Gothenburg, SWEDEN
postel@VENERA.ISI.EDU (08/29/90)
Gunnar Lindberg: See RFC-1174 for new policy on "connected status". --jon.
asp@UUNET.UU.NET (Andrew Partan) (08/29/90)
> See RFC-1174 for new policy on "connected status".
I have seen this - but the NIC is still using their old policies. Does
any one known when the NIC is going to change their policies to fall in
line with RFC 1174?
I have networks that do not have connected status (connected status no
longer being required) that are being routed on the NSFNET. I also
have networks that are not being routed on the NSFNET. In both cases,
the NIC will not register their IN-ADDR.ARPA domains nor change their
name servers to hosts not on networks with connected status.
Thanks,
--asp@uunet.uu.net (Andrew Partan)postel@VENERA.ISI.EDU (08/30/90)
Andrew Partan: I'll investigate with the NIC. It may take them a bit of time to work out new procedures and put them in place. --jon.
morgan@jessica.stanford.edu (RL "Bob" Morgan) (08/30/90)
Re: insisting on inverse mappings:
Hmm, I'm interested in this discussion, having just been involved in
an argument with a site that refuses connections to sites that won't
inverse map. Can someone quote chapter and verse from an RFC that
says that a host's IP address should inverse map via DNS before it can
make a connection? All I can find that seems relevant is from Host
Requirements II, RFC 1123:
2.2 Using Domain Name Service
Host domain names MUST be translated to IP addresses as described
in Section 6.1.
Applications using domain name services MUST be able to cope with
soft error conditions. Applications MUST wait a reasonable
interval between successive retries due to a soft error, and MUST
allow for the possibility that network problems may deny service
for hours or even days.
Do these systems that reject connections based on no inverse mapping
allow for this sort of error?
I guess the philosophy puzzles me. I've always thought of DNS as a
way of making it easier for clients to connect to services, not as any
sort of authentication system.
At this site we have 2000 machines on LocalTalk networks using dynamic
IP address assignment and supporting no IP services. Is it really
necessary for security for us to give them all names (actually, give
the addresses names) and put them in our domain database? Surely if
intrusive activity is coming from one of these machines it's easy to
determine where it's at by looking at the network part of its IP
address?
- RL "Bob" Morgan
Networking Systems
Stanford