HP gethostbyaddr errors

[Mark.Andrews at nominum.com]

> > -----Original Message-----
> > From: Mark.Andrews at nominum.com [mailto:Mark.Andrews at nominum.com]
> > Sent: Monday, 17 April 2000 15:45
> > To: James Hall-Kenney
> > Cc: bind-users at isc.org
> > Subject: Re: HP gethostbyaddr errors 
> > 
> > 
> > 
> > > All,
> > > 
> > > We have a customer who is having trouble with BIND 8.2.2-P5 
> > on HP-UX 11.
> > > 
> > > They use router management software (Spectrum on Solaris) 
> > that maps the
> > > network topology and uses reverse resolution to determine 
> > the device name of
> > > the router.  Because they are monitoring multiple 
> > interfaces on the router,
> > > the name in the management software will change regularly.  
> > To circumvent
> > > this, we have created the reverse resolution entries to all 
> > resolve to the
> > > same name ie:
> > >      
> > >      Forward Resolution entries:
> > >       
> > >      interfacea        129600  IN      A       10.13.255.5 
> > >      interfaceb        129600  IN      A       10.13.128.1 
> > >      interfacea        129600  IN      A       10.13.130.1 
> > >      
> > >      Reverse Resolution entries:  (13.10.in-addr.arpa) 
> > >       
> > >      5.255       129600  IN      PTR     interfacea.ssi.govt.nz. 
> > >      1.128       129600  IN      PTR     interfacea.ssi.govt.nz. 
> > >      1.130       129600  IN      PTR     interfacea.ssi.govt.nz.
> > > 
> > > They have a different management product - HP Network Node 
> > Manager running
> > > on HP-UX 11.  For some reason, this host seems to want to 
> > verify that the A
> > > record matches the PTR.  We get a message in syslog: 
> > >   gethostbyaddr : timcr100.ssi.govt.nz != 10.213.130.1
> > 
> > 	This message indicates that when gethostbyaddr did a reverse
> > 	lookup on 10.213.130.1 it found the name was 
> > timcr100.ssi.govt.nz.
> > 	It then performed a forward lookup on timcr100.ssi.govt.nz
> > 	and didn't find 10.213.130.1 as a valid address for
> > 	timcr100.ssi.govt.nz.
> > 
> > 	This could be due to a error in the DNS 
> 
>    So you would consider the configuration discussed to be invalid as 
>    the A records do not match the reverse records, even intentionally?
> 
>    James

	If the PTR points to a name that does not have corresponding A
	record the library routine assumes you are attempting to reverse
	spoof the server.

	Anyone who controls the reverse DNS for their address space can
	say there machine (via reverse lookup) has any given name.  It
	is only by performing a forward lookup on the name and checking
	that the address is listed is there some level of trust in the
	answer.

	I could simple arrange for my PTR records to say that all my machines
	were "sytec.co.nz".  Applications / libraries that just trust the
	PTR record would think I was "sytec.co.nz" if I connect to them.
	Those that perform the consistancy check would log the mismatch
	and treat me as unnamed or, if truly paranoid, someone with hostile
	intent.

	Depending upon the vendor, this consistancy check is built into
	the application or into the C library.

	Mark
> 
> >     or to a limitation in
> > 	gethostbyname (called by gethostbyaddr) which limits the number
> > 	of addresses to 35.
> > 
> > 	Mark
> > 
> > > 
> > > As this box is managing over 2,000 addresses, it is doing a 
> > lot of name
> > > resolution and filling up the syslog on the host very 
> > quickly.  Note that
> > > the management works OK.  The customer called HP to get 
> > them to resolve the
> > > problem and HP are saying that the DNS configuration of 
> > mismatched A and PTR
> > > records is "broken".  The engineer has quoted from page 64 
> > of O'Reilly DNS &
> > > BIND:
> > > 
> > >      "To state as a general rule: if a host is multihomed 
> > create an address 
> > >      record for each alias unique to one address. Create a 
> > CNAME record for 
> > >      each alias common to all the addresses"
> > >      
> > > Of course, this method doesn't provide for a single name 
> > per device on the
> > > Spectrum management server.
> > > 
> > > My questions:
> > > 1.  Is the described method considered to be a broken 
> > implementation?  I
> > > haven't seen any explicit statements in the RFC's that 
> > state that the PTR
> > > MUST match the A record.
> > > 2.  Any suggestions on how to work around this other than 
> > force a change
> > > with HP?
> > > 
> > > TIA
> > > 
> > > J.
> > > 
> > > James Hall-Kenney
> > > Sytec Resources Limited
> > > 	
> > > 
> > > 
> > > 
> > > 
> > --
> > Mark Andrews, Nominum Inc. / Internet Software Consortium
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: 
> > Mark.Andrews at nominum.com
> > 
--
Mark Andrews, Nominum Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com