Xref: utzoo comp.protocols.tcp-ip:14164 comp.protocols.tcp-ip.domains:537
Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uwm.edu!bionet!agate!riacs!nsipo.arc.nasa.gov!medin
From: medin@nsipo.arc.nasa.gov (Milo S. Medin)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject: Re: gethostbyaddr() failing
Message-ID: <1990Dec18.085041.18652@riacs.edu>
Date: 18 Dec 90 08:50:41 GMT
References: <1990Dec16.191345.22482@engin.umich.edu> <9012170259.AA06606@nsipo.arc.nasa.gov> <1990Dec17.182114.14182@cs.umn.edu>
Sender: news@riacs.edu (James A. Woods)
Reply-To: medin@nsipo.arc.nasa.gov (Milo S. Medin)
Organization: NASA Science Internet Project Office
Lines: 48

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