stealth@engin.umich.edu (Mike Pelletier) (12/17/90)
I'm running a daemon on a Sparcstation here, and it's running into problems when people connect to it from dial-in ports on the Merit network. The person connects, but the connection is immediately closed, after the program logs: Dec 16 13:47:19 arrakis irciid[5321]: gethostbyaddr: ccb3.merit.edu != 35.1.48.130 However: 130.48.1.35.in-addr.arpa host name = ccb3.merit.edu but, Non-authoritative answer: Host name: ccb3.merit.edu Address: 35.1.48.129 The program is a modified telnetd, I gather. Any suggestions on how to get around this difficulty? -- Mike Pelletier - Usenet News Admin & Programmer "Wind, waves, etc. are breakdowns in the face of the commitment to getting from here to there. But they are the conditions for sailing -- not something to be gotten rid of, but something to be danced with."
medin@NSIPO.ARC.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) (12/17/90)
That's not a bug but a feature! Late model BIND resolver code has a security feature in it which causes this behavior. Basically, if your code does a gethostbyaddr call to the DNS, the resolver will query the DNS system for a PTR record for the address passed to it. The old code would then return the reply, without verification. The new code goes one step farther by then additionally doing a gethostbyname call on the returned name, and verifying the name has the original address as one of the A records associated with it. This makes DNS spoofing significantly harder, and thus things that make use of .rhosts and such less of a security problem. The problem in your case is that whoever runs your DNS configuration accidentally left out the address in question, or used the wrong name in the PTR record. Have nslookup check out the A records associated with ccb3.merit.edu, and I think you'll see the error. The syslog message basically says that ccb3.merit.edu does not have 35.1.48.130 as one of it's interface addresses. If you don't like seeing this message, just change your syslog configuration to ignore it. Otherwise, it's telling you about a configuration error in the DNS... Thanks, Milo
john@mintaka.mlb.semi.harris.com (John M. Blasik) (12/18/90)
medin@NSIPO.ARC.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) writes: > >That's not a bug but a feature! Late model BIND resolver code has a security >feature in it which causes this behavior. Basically, if your code does >a gethostbyaddr call to the DNS, the resolver will query the DNS system for >a PTR record for the address passed to it. The old code would then return >the reply, without verification. The new code goes one step farther by >then additionally doing a gethostbyname call on the returned name, and verifying >the name has the original address as one of the A records associated with it. I believe this is a SUNism and would dare call it a bug. What's wrong with doing the extra gethostbyname only when necessary (in rsh and friends)? The way it works now, things like traceroute and netstat break (no "A" for FOO.ST.NSF.NET, PTR's returned for host-0 names ala rfc 1101) -- john
peiffer@cs.umn.edu (Tim Peiffer "The Net Guy") (12/18/90)
Milo Medin <9012170259.AA06606@nsipo.arc.nasa.gov> writes: >The problem in your case is that whoever runs your DNS configuration accidentally >left out the address in question, or used the wrong name in the PTR record. Merit misconfigured ccb4.merit.edu as ccb3.merit.edu. This misadventure within the DNS did actually point out a few possible problem areas that I would like to ask about. 1) What is the correct use of wildcarding within named zone files? 2) What is the most effective (and correct) method of showing hosts with dynamic addresses within the .rev zone files? Consider the following: 1) Fastpath Appletalk to TCP/IP gateway. 2) Kstar 8.0+ and PhaseII Appletalk. 3) Base address of 128.101.147.221 4) dynamic addressing from 147.222 to 147.240 $ORIGIN ee.umn.edu. eecsk4f2 IN A 128.101.147.221 ; glue records like any other gateway ( multiple A records) IN A 128.101.147.222 [....] IN A 128.101.147.240 IN HINFO KFPS-4 Native $ORIGIN 147.101.128.IN-ADDR.ARPA. 221 IN PTR eecsk4f2.ee.umn.edu. 222 IN PTR eecsk4f2.ee.umn.edu. [...] 241 IN PTR eecsk4f2.ee.umn.edu. %nslookup -qt=ptr 128.101.147.240 240.147.101.128.in-addr.arpa host name = eecsk4f2.ee.umn.edu %nslookup eecsk4f2.ee.umn.edu Name: eecsk4f2.ee.umn.edu Address: 128.101.147.221 In this case the feature that Milo Medin mentioned would cause a lot of problems. With the example shown, the resolver would also complain of nres_gethostbyaddr(): eecsk4f2.ee.umn.edu != 128.101.147.240 Tim Peiffer -- ----------- Tim Peiffer peiffer@cs.umn.edu or Computer Science Dept ..!rutgers!umn-cs!peiffer University of Minnesota
medin@nsipo.arc.nasa.gov (Milo S. Medin) (12/18/90)
What we do here at Ames is that the K-box base address PTR points back to the K-box, and then each dynamic address has it's own name, and a PTR record that points back it it. For example, you have: n233-edc-gw IN A 128.102.18.112 IN HINFO "Kinetics AppleTalk Gateway" "N/A" n233-edc-1 IN A 128.102.18.113 IN HINFO "AppleTalk Host" N/A n233-edc-2 IN A 128.102.18.114 IN HINFO "AppleTalk Host" N/A n233-edc-3 IN A 128.102.18.115 IN HINFO "AppleTalk Host" N/A n233-edc-4 IN A 128.102.18.116 IN HINFO "AppleTalk Host" N/A n233-edc-5 IN A 128.102.18.117 IN HINFO "AppleTalk Host" N/A n233-edc-6 IN A 128.102.18.118 IN HINFO "AppleTalk Host" N/A n233-edc-7 IN A 128.102.18.119 IN HINFO "AppleTalk Host" N/A n233-edc-8 IN A 128.102.18.120 IN HINFO "AppleTalk Host" N/A n233-edc-9 IN A 128.102.18.121 IN HINFO "AppleTalk Host" N/A n233-edc-10 IN A 128.102.18.122 IN HINFO "AppleTalk Host" N/A n233-edc-11 IN A 128.102.18.123 IN HINFO "AppleTalk Host" N/A n233-edc-12 IN A 128.102.18.124 IN HINFO "AppleTalk Host" N/A n233-edc-13 IN A 128.102.18.125 IN HINFO "AppleTalk Host" N/A n233-edc-14 IN A 128.102.18.126 IN HINFO "AppleTalk Host" N/A n233-edc-15 IN A 128.102.18.127 IN HINFO "AppleTalk Host" N/A The PTR records all point back to the proper names, which are different for each dynamically assigned address. It's not that hard to build this with a shell script or an awk script. And even if you didn't do this, all that would happen is the gethostbyaddr would fail. No big deal, as people shouldn't be sticking things with dynamically assigned addresses in their .rhosts and the like. No big deal, or perhaps I'm missing something here? In any case, it's a big payoff for the security advantages this provides. Thanks, Milo
medin@nsipo.arc.nasa.gov (Milo S. Medin) (12/18/90)
In article <1990Dec17.182114.14182@cs.umn.edu> peiffer@cs.umn.edu (Tim Peiffer "The Net Guy") writes: ... >eecsk4f2 IN A 128.101.147.221 >; glue records like any other gateway ( multiple A records) > IN A 128.101.147.222 > [....] > IN A 128.101.147.240 > IN HINFO KFPS-4 Native > >$ORIGIN 147.101.128.IN-ADDR.ARPA. >221 IN PTR eecsk4f2.ee.umn.edu. >222 IN PTR eecsk4f2.ee.umn.edu. >[...] >241 IN PTR eecsk4f2.ee.umn.edu. > >%nslookup -qt=ptr 128.101.147.240 > 240.147.101.128.in-addr.arpa host name = eecsk4f2.ee.umn.edu >%nslookup eecsk4f2.ee.umn.edu > Name: eecsk4f2.ee.umn.edu > Address: 128.101.147.221 > >In this case the feature that Milo Medin mentioned would cause a lot >of problems. With the example shown, the resolver would also >complain of nres_gethostbyaddr(): eecsk4f2.ee.umn.edu != 128.101.147.240 > BTW, I forgot to point out in this case, you should still be OK, because unlike your nslookup output, gethostbyname will return a struct with a list of all the addresses inside. The resolver code acting the way I described will still specify a match provided that ONE of the returned A records matches the original address. In the situation you describe, 128.101.147.240 would be one of the A records associated with eecskff2.ee.umn.edu, and the call would return sucessfully. We at Ames prefer to do it in the way I described in my earlier posting, but both ways are valid, and both work with this resolver behavior. Now, I'll contend our way is a bit more robust, as the last BIND code I looked at had had some absurdly low maximum number of A records per hostname, and thus you might not get all 32 of your A record entries back in response to the query, but in theory, this should be doable. You can however discover a whole pile of DNS misconfigurations or oversights in this way, and that's always a good thing. Thanks, Milo
medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) (12/19/90)
>I believe this is a SUNism and would dare call it a bug. > >What's wrong with doing the extra gethostbyname only when necessary (in rsh > and friends)? >The way it works now, things like traceroute and netstat break >(no "A" for FOO.ST.NSF.NET, PTR's returned for host-0 names ala rfc 1101) It's not a SUN'ism. We had implemented this at NASA Ames a long time before it showed up in SunOS. In fact, we may have well turned in a bug report on this to SUN. I know went sent the diffs to UCB. You can't do the extra gethostbyname only when necessary, since the library routine can't know this for sure. You could modify everything that would benefit from it, but the most natural place for it seems to be in the library routine itself. And in a system with shared library support, you can deploy this without having all the system applications which would benefit from it be modified, much less applications written by users and software vendors. There is no reason that the DNS configurations, if done thoroughly, break netstat and traceroute. Again, if you configure the DNS information to be completely consistent, things work fine. thanks, Milo
stewart@XYPLEX.COM (Bob Stewart) (12/19/90)
>There is no reason that the DNS configurations, if done thoroughly, break >netstat and traceroute. Again, if you configure the DNS information to >be completely consistent, things work fine. Although I admit I haven't been following this thread with full attention, the idea that to operate reasonably DNS information must be "completely consistent" sounds pretty scarey to me. Sounds less than robust. Bob ----------- Bob Stewart (rlstewart@eng.xyplex.com) Xyplex, Boxborough, Massachusetts (508) 264-9900
ckd@cs.bu.edu (Christopher Davis) (12/20/90)
Milo> "Milo" == medin@NSIPO.NASA.GOV
Milo> ("Milo S. Medin", NASA ARC NSI Project Office) writes:
Milo> There is no reason that the DNS configurations, if done
Milo> thoroughly, break netstat and traceroute. Again, if you configure
Milo> the DNS information to be completely consistent, things work fine.
Care to suggest how I can do this for the NSFNET backbone? I don't have
authority for *.NSS.NSF.NET, you know.
I suggest that "regular" gethostbyaddr() default to the authentication
behavior (the "SUN/NASA" mode) and that a separate library function
"ugethostbyaddr()" or the like be added for "unauthenticated" PTR
lookups.
--Chris
--
[ Christopher Davis - <ckd@cs.bu.edu> - <..!bu.edu!cs.bu.edu!ckd> ]
A message destined for delivery in *your* domain is fair game for
anything you may want to do, up to and including translating the entire
message, header and all, into Swahili. -- chip@tct.uucp (Chip Salzenberg)libes@cme.nist.gov (Don Libes) (06/08/91)
In article <895@bcstec.boeing.com> ced@bcstec.uucp (Charles Derykus) writes:
[about telneting to the smtp port to get a host's FQDN]
I wrote a script to automate this. 'gethostbyaddr' works as follows:
1) It runs nslookup and does a PTR query.
2) If that fails, it does a telnet to the SMTP port.
3) If that fails, it telnets to the SMTP port of every host on that
network (class D is assumed) looking for one that identifies itself
with a FQ network name. This is appended to a non-FQ host name if one
was found in step 2. Otherwise it is returned, as is.
As each name is generated, it is translated back to an address (with
nslookup) for verification. If a name is successfully translated back
to an address, the process stops.
You may smirk at step 3, but it is quite effective. Many hosts use
mail software "as delivered" from the factory. Similarly, some hosts
are non-responsive (X terminals, PCs, etc). However, there is almost
always one host per net (such as the official mail gateway) that is
configured to do the SMTP greeting with its FQDN.
I'm not particularly proud of the idea, but it works and is very handy
for network debugging. We've recorded 2200 different hosts in our ftp
log this year. Only 4 of them failed to be mapped back this way.
For those 4 hosts, there is actually a step 2.5 - since step 3 can take
a while, the script telnets to the NIC and looks up various forms of the
network address. (This virtually always works though it can be fairly
inaccurate if it has to go all the way back to, say, a class B address.)
The script has various options to control how much effort it uses.
(It does not load the network, however while writing it I was greatly
concerned that it would.)
As an example, 137.204.57.34 does not have an in-addr.arpa entry. It
responds by smtp as "deis34.noname". nslookup is used to verify that
this is meaningless. The script then finds that 137.204.57.33 is
"deis33.cineca.it" so it posits that the original host is
"deis34.cineca.it". Again, nslookup is used to verify, this time
successfully.
"gethostbyaddr" has various forms of verbosity, ranging from saying
only a FQDN to a complete description of how it figured it out. The
script is included with the expect distribution. (email "send
pub/expect.shar.Z" to library@cme.nist.gov or anonymous ftp same from
durer.cme.nist.gov)
Don Libes libes@cme.nist.gov ...!uunet!cme-durer!libes