North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: lame delegations

  • From: Greg A. Woods
  • Date: Mon Aug 21 13:36:06 2000

[ On Monday, August 21, 2000 at 09:16:53 (-0700), Karyn Ulriksen wrote: ]
> Subject: RE: lame delegations
> > Unless I misunderstand what you mean, my version of BIND (8.2.2p3)
> > doesn't do that.
> > 
> > 	$ host -a 
> >       PTR
> >       PTR
> Interesting.  I actually haven't tried this since BIND 4.  It made sense
> that it wouldn't so I assumed it shouldn't and further assumed that in BIND
> 8 that it didn't as well.  (Sorry about that last sentence!)  Anyways, I
> think you catch up with me in your next paragraph here ...

I don't remember ever having trouble with multiple PTRs in later
versions of BIND-4 either (I do remember that 4.9.7 in particular works
OK....)  I doubt I ever tried it on 4.8.3 though.....

> So does the reverse resolve work correctly with the two PTR responses for
> most resolvers?

I found this tidbit in my archive of the bind-workers mailing list from
back in June of 1996:

	As it stands, BIND allows an IP address to have multiple PTR
	records, but gethostbyaddr() only returns the first.

and this "reply" to a proposal to "fix" this issue:

	have you looked at the 4.9.3 or 4.9.4 version of the
	res/gethnamadr.c file, paying special attention to the
	MULTI_PTRS_ARE_ALIASES preprocessor symbol and its default

That setting is of course:

	#define MULTI_PTRS_ARE_ALIASES 1        /* XXX - experimental */

And according to my CVS repository that code's been in BIND's resolver
since before 28-Sep-94, i.e. BIND-4.9.3-BETA-9 has it but it was not in

I.e. Yes, most existing resolvers based on the BIND code will correctly
return multiple PTRs in responses as aliases in the returned "struct
hostent".  I have no knowledge of the behaviour of any "third party"
resolvers in this scenario though.  Obviously it's not too hard for
anyone with such a resolver, and a tool such as "host" or "nslookup"
that can be linked against that resolver, to test it though....

							Greg A. Woods

+1 416 218-0098      VE3TCP      <[email protected]>      <robohack!woods>
Planix, Inc. <[email protected]>; Secrets of the Weird <[email protected]>