HP gethostbyaddr errors

[Barry Margolin]

In article <61B6688756F7D011B70100805F06BEDC770F97 at palliser.sytec.co.nz>,
James Hall-Kenney  <James.Hall-Kenney at sytec.co.nz> wrote:
>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.

We do the same thing for all the routers in our backbone.  Their PTR
records all point to <interface>.<router>.bbnplanet.net, and there are
corresponding forward records.  In addition, we have a CNAME record for
<router>.bbnplanet.net that points to the primary interface.

>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

That error doesn't seem to match what you claim to have done.  Is
"timcr100" an interface name?  If not, where is that PTR record coming
from?  Do you have multiple PTR records for the same address?  If so, make
sure that there are corresponding A records for all of them.

>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.

The described method is a recommdation, not a requirement.  It allows you
to connect to a device by either a generic name or a name specific to a
particular interface.

However, the rule that PTR records must point to the A record does exist.