Multiple PTR reverse lookup problem (BIND9 resolver broken?)

[Simon Waters]

David wrote:
>
> BIND9 appears to resolve the multiple PTRs in a roundrobin fashion,
> which seriously breaks proper reverse DNS resolution. 

As far as I know, no RFC says any of the old fashioned
(RFC103[3,4,5]) DNS RR types have to to be returned in any
particular order.

I don't see why this breaks reverse resolution, there are a list
of records, BIND 9 retrieves them, order is irrelevant.

> It is my
> understanding that normal DNS resolvers are suppsed to ignore any PTR
> after the first one it encounters. 

Resolvers return record sets, clients can do what they like with
the record set.

> For example, resolve 206.26.15.70
> on a non-BIND9 server and it should return two PTR records (sigh) the
> first and correct being thick.haze.net.  Every resolution should
> return thick.haze.net as the primary PTR.  However, if you do this
> resolution on or through a BIND9-based server/resolver, it will
> roundrobin the responses (try at least 5 or 6 times to see).  To
> observe this behavior, feel free to resolve 206.26.15.70 by pointing
> host/dig at 160.79.126.10 which is a nameserver currently running BIND
> 9.2.0.  It seems to me BIND9 is quite broken.  Is this a bug?

Not as far as I know, why do you think it is?
 
> Finally, should I inform my ISP that the fine experts here do not
> recommend multiple PTR records for the same address due to the
> pontential problems and complications to proper reverse DNS
> resolution?  It seems to me a very unnecessary and improper way to
> handle a reverse zone (what is so hard about deleting the 'default'
> entry after adding a new PTR anyway?)  Please let me know if more info
> is needed, thanks.

It's been discussed in depth before see the archives. The most
you can say is some of the experts here think it is unnecessary
waste of bandwidth, but the RFC's are unambigous 2181 states
multiple PTR's are allowed.

What are you trying do do with reverse resolution data that is
breaking, as it is usually inappropriate security algorithmns
that get fouled up by multiple PTR records.