auth-nxdomain

[Jim Reid]

>>>>> "Nikos" == Nikos Voutsinas <nvoutsin at noc.uoa.gr> writes:

    Nikos> I have an OpenView asking me for PTR records, for the most
    Nikos> of the router devices there in not a PTR records . So I
    Nikos> want to avoid asking authoritative servers and get each
    Nikos> time the same response [Error: 3(Name Error)]

Why don't you just do the Right Thing and put PTR records for these
IP addresses in your reverse zone files?

    Nikos> I also want
    Nikos> to convince the resolrver on the machine ,where the
    Nikos> OpenView is running not to asking me again and again for
    Nikos> not existent PTR records.  That's why I need negative
    Nikos> cache. 

Resolvers are stupid. All the do is make queries and wait for an
answer which they return to the application. The don't cache
anything. Or negatively cache anything. Name servers have
caches. Resolvers and applications don't. (As a general rule.)

    Nikos> I' ve also read that I should check for the
    Nikos> auth-nxdomain option to flag cashed negative responses as
    Nikos> authoritative.  How can I enable or disable this feature?

This option doesn't do what you think/hope, even if it applied to
resolvers, which it doesn't. Whether an answer or negative answer is
authoritative or not has no significant bearing on what another name
server or resolver does with that answer. At least as far as this
problem is concerned.

    Nikos> Do you have any other solution ?

Add the missing PTR records that should have been present from the
outset. This will stop Openview getting NXDOMAIN answers when it does
a reverse lookup of the addresses of your routers.

    >>  > Also Is there any way to increase the >"TTL" of negative
    >> cashed responses?
    >> 
    >> The MinTTL field of the SOA record specifies the negative cache
    >> TTL.

    Nikos> So there isn't any option like Solaris's nscd for negative
    Nikos> time to live time

There is and it was already explained to you. I quote: "The MinTTL
field of the SOA record specifies the negative cache TTL". If that's
not clear enough for you, please read RFC2308. And as I've explained
playing with that TTL isn't going to make any difference to your
resolver and therefore the lookups made by Openview. Unless Openview
has its own cache, which I suppose is possible but improbable.