On Thu, 19 Nov 2009, stan wrote:

quoted text
>On Wed, Nov 18, 2009 at 11:03:27PM -0500, Dave Anderson wrote:
>> On Wed, 18 Nov 2009, stan wrote:
>>
>> >On Wed, Nov 18, 2009 at 05:00:02PM -0500, Dave Anderson wrote:
>> >> On Wed, 18 Nov 2009, stan wrote:
>> >>
>> >> >Can anyone xplain this behavior to me?
>> >>
>> >> Without access to your nameservers it's not possible to be sure, but see
>> >> below -- this looks normal to me.
>> >>
>> >> >Given the following resolv.conf file:
>> >> >
>> >> >root@pm3fw:root# cat /etc/resolv.conf
>> >> >lookup file bind
>> >> >search mcn.chs kapstonepaper.com pm3.charleston.meadwestvaco.com
>> >> >nameserver 127.0.0.1
>> >> >nameserver 10.209.128.20
>> >> >nameserver 10.209.128.26
>> >> >nameserver 10.209.142.158
>> >> >
>> >> >And:
>> >> >
>> >> >root@pm3fw:root# nslookup
>> >> >> cvsup
>> >> >Server:         127.0.0.1
>> >> >Address:        127.0.0.1#53
>> >> >
>> >> >Non-authoritative answer:
>> >> >Name:   cvsup.mcn.chs
>> >> >Address: 10.209.142.151
>> >> >> 10.209.142.151
>> >> >Server:         127.0.0.1
>> >> >Address:        127.0.0.1#53
>> >> >
>> >> >151.142.209.10.in-addr.arpa     name = cvsup.meadwestvaco.com.
>> >> >> exit
>> >> >
>> >> >Why does this happen ? And how?
>> >>
>> >> You apparently have a system with multiple names and a single IP
>> >> address.  Both cvsup.mch.chs and cvsup.meadwestvaco.com are assigned
>> >> address 10.209.142.151, but the reverse-lookup entry can't return both
>> >> names.  Given the order of domains in your 'search' directive,
>> >> cvsup.mcn.chs is looked up first and so is the name that nslookup
>> >> reports, but cvsup.meadwestvaco.com was chosen as the 'official' name
>> >> for the reverse lookup by whoever set up your DNS.
>> >>
>> >Your analysis is correct, in that thier are multiple names (don't ask :-().
>> >I have control of some of the nameservers. They are bind 9 on OpenBSD, can
>> >you clarify what you mean by "offical name" are you talking about a A
>> >entry, as oposed to a CNAME entry?
>>
>> Sorry I wasn't clear.  I was referring to the *.in-addr.arpa 'PTR' DNS
>> entry which provides the translation from IPv4 address to host name.
>
>K, I am starting to understand this now, thequestion is how to fix it. I do
>have a PTR record in my 10.in-addr.arpa db. If I wan this NOT to be the
>authortative entry for this IP -> name tarnsaltion, so that an authortative
>eoll 'pass on by" this Bind instnace and go on to one further down, how can
>I acomplis htis?

If I'm understanding you correctly, you can't.  The only control which I
recall offhand that you have over whether a nameserver responds with
data from its cache is to set the 'authoritative' flag in your request,
which will cause a nameserver with only cached data to pass the request
on -- but you don't want to do this routinely since it defeats the
distributed nature of DNS and so results in overloading the
authoritative servers.

All that the 'authoritative' flag tells you is whether the response came
from a server with the entry in its cache (not authoritative) or from
one which has that information manually configured on it
(authoritative) -- so I'm not at all sure what you mean by 'fix it'.

What exactly is the behavior that you want?

	Dave

-- 
Dave Anderson
<dave@daveanderson.com>