Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!ucbvax!agate!riacs!nsipo.arc.nasa.gov!medin
From: medin@nsipo.arc.nasa.gov (Milo S. Medin)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: PTR records of gateways on the Internet
Message-ID: <1991Jan13.054040.21009@riacs.edu>
Date: 13 Jan 91 05:40:40 GMT
Sender: news@riacs.edu
Reply-To: medin@cincsac.arc.nasa.gov (Milo S. Medin)
Organization: NASA Science Internet Project Office
Lines: 74

In article <1991Jan11.004226.24988@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:

>>
>>TRACEROUTE is unable to resolve the name:
>>
>>    princeton.nj.nss.nsf.net	13265 IN	A	128.121.54.1
>>
>>There is code in (at least Sun's) "gethostbyaddr()" to trap this type
>>of data inconsistency and produce a syslog message:
>
> Just because Sun's 'gethostbyaddr()' is broken, there is no reason to
>complain about the way domains are set up.
>
>>Obviously the implementors of gethostbyname() believed this to be
>>illegal.
>>
> The public BSD sources do not have this defect.
>
> The DNS is a directory service, not an authentication service.  The

This is not broken, nor is it a defect, and nor is it limited to SUN's.  We
at Ames came up with this mod to the resolver code after having been burned 
by internet DNS spoofing.  If your resolver doesn't have this capability,
your site is open to a lot of security problems.  We have BSD systems here
which had the mod made to the resolver and had network utilities rebuilt.  


We turned this bug into Sun, and posted it on comp.bugs.4bsd.  Many sites use
this since they consider security marginally important.  If you don't, that's
fine, and more power to you, but don't berate the efforts of a vendor who is
concerned with improving the state of security.  If you don't like it, 
then rebuild the resolver library from BSD source (available from a
number of places), and install a new shared library.  You can convienently 
rewrite some of the other troublesome features (like wasting time doing a 
gethostbyaddr on inbound login connections, maybe get rid of all utmp 
host information) at the same time!  How about just having gethostbyname 
return a hardwired answer like not-me.yourdomain.edu. ?  This way you
wouldn't have to wait for that pesky DNS to figure out where you are logging
in from to timeout when you botch the DNS configuration!  What a plus!
After all, not all sites require knowing where people log in from.  Why should
everyone have to put up with these silly delays because a few paranoids out
there worry all the time!

>extra checking you describe in Sun gethostbyname() is an attempt to use
>it as an authentication service.  This is WRONG behavior for
>gethostbyaddr().  It may make sense to add this type of authentication
>to some specific uses (say in rlogind, when checking hosts.equiv).  But
>it does not make sense in general.
>

Bull.  The DNS system is a distributed database.  Are you saying that you
don't care how valid the information is as long as it tells you something??
If you can tell someone has misconfigured things or is trying to spoof your 
system, that's pretty useful info for me.  

As for using it in only things that require .rhosts type of files, well, I'm
sure you'd be rather annoyed when someone breaks into your machine from the
Internet and spoofs the PTR information so that when you try and contact
the system admin. of the host that connected to you, you get nowhere.  Ah, but
then you don't care about security!  I'm sorry I forgot...  If the info is
wrong, it shouldn't be shoved into utmp.  

I can't believe all this garbage blaming the resolver code!!!  If you
have a problem with the NSS's not doing this, call MERIT and complain.  I notice
most other people seem to get this right.  Don't blame the resolver for doing
the right thing.  If this REALLY annoys you, why not just relink traceroute
with the straight BSD resolver?  Sigh...


							Thanks,
							   Milo


PS Usual disclaimers apply...