DNS problem with delay in answering to a missing reverse zone nslookup ip address

[Fabio_60]

We are facing a new issue...
It seems that DNS has changed its behavior after installing BIND 9 version.
If you tried to nslookup an address which has not a reverse zone x.y.z.t in previous BIND 8, you receive a fast answer:
Trying DNS
Trying NIS
Looking up FILES
*** No hostname information is available for "x.y.z.t"

Now in BIND 9, for the same address, you receive the same messages but the system is hanged a lot of time in:
Trying DNS
.....
then it goes on quickly.
This is impacting to some security scripts that our customer is launching and they are failing for this behavior.
Maybe these scripts try to contact these ip-addresses and these time-out make them fail the scripts.
Thank you for your support
Fabio

[Keith Bryson]

Hi Fabio

Try changing your /etc/resolv.conf file to something like this:

domain mydomain.com
retrans 2000
retry 1
nameserver a.b.c.d # Your 1st nameserver
nameserver e.f.g.h # Your 2nd nameserver
#etc

The retrans and retry option should be used together to improve timeout response.

Keith

[Fabio_60]

Hi and thank you Keith.
We already have the retry and retrans parameters set to:
retry 2
retrans 300
Anyway, I changed them to your values and It did't help..:-(
Fabio

[Keith Bryson]

Fabio

What have you got for /etc/resolv.conf and /etc/nsswitch.conf? You may want to post them on this thread.

Keith

[Fabio_60]

Hi these are the files:
I inserted named.conf, too.
Fabio

[Fabio_60]

These are the other:
named.conf

And resolv.conf:
search r13.netact.vodafoneomnitel.it r11.netact.vodafoneomnitel.it netact.vodafoneomnitel.it w2k.r13.netact.vodafoneomnitel.it g99.netact.vodafoneomnitel.it omnitel.it
nameserver 10.192.34.203
nameserver 10.192.34.204
nameserver 10.192.34.205
retry 2
retrans 300


Fabio
Thank you again

[Fabio_60]

hi...
nsswhitch.conf...
FAbio

[Keith Bryson]

Fabio

Try entering this:

nslookup
server 10.192.34.204
set type=a
x.y.z.t # (ENTER your reverse IP to lookup)

Does this differ in resolution response?

Keith

[Fabio_60]

hi Keith.
Unluckely, the resolution is exactly the same...:-(: we have to wait almost 1 minute to have the command finished...

Fabio

[Keith Bryson]

Fabio - 2 questions

Are the 3 nameservers up and can you ping them?

The server you are running the nslookup on, is this one of the nameservers itself?

Keith

[Geoff Wild]

I think your issue is the search statement in resolv.conf - this is for actual domain names - it looks like you have machine names...

What is your Top Level Domain for your site?

netact.vodafoneomnitel.it?

or

vodafoneomnitel.it?


You might want to try changing to just:

domain vodafoneomnitel.it

From man resolv.conf:

he search list
can be changed by listing the desired domain
search path following the search keyword with
spaces or tabs separating the names. Most
resolver queries will be attempted using each
component of the search path in turn until a match
is found. Note that this process may be slow and
generates a lot of network traffic if the servers
for the listed domains are not local, and that
queries time out if no server is available for one
of the domains.

The search list is currently limited to six
domains with a total of 256 characters.

The first domain in the search list must be the
local domain for short names to work properly in
various files


To me, the reason it is slow is you are searching all of these every time:
r13.netact.vodafoneomnitel.it
r11.netact.vodafoneomnitel.it
netact.vodafoneomnitel.it
w2k.r13.netact.vodafoneomnitel.it
g99.netact.vodafoneomnitel.it
omnitel.it

Rgds...Geoff

[Fabio_60]

In the meanwhile, we found a 'solution' by finding out that DNS was looking for the root in its resolving those ip-address whose reverse zone was missing, and it wasn't finding it.
During normal BIND8 use, the db.cache lines into named.conf had been commented. This solution had been implemented because db.cache was pointing to a remote DNS MAster, which has been chosen as master DNS in this environment. In case of global cluster unavailability, VF had had serious problem with all 3G management.
Now,in BIND9,we commented out the db.cache lines and nslookup started working in its standard way. In the same moment we put a local server into db.cache file so that any problem would arise for future remote server unavailability.

Is our 'solution' reasonable?
Is this related to some improvement of Bind8 versus Bind9?
Thank you for information you will provide me.
Fabio