In /etc/resolv.conf if we have specified 2 nameservers i.e.
nameserver x.x.x.x
nameserver y.y.y.y
If the first one fails, are lookups immediately performed to the
second one (my thinking is yes)
In normal operation are lookups performed to each one in round robin
fashion?
I have read that some people disable nscd as it caused performance
issues with lookups, is this true?
> nameserver x.x.x.x
> nameserver y.y.y.y
>
> If the first one fails, are lookups immediately performed to the
> second one (my thinking is yes)
Yes, it will try them in order by default
>
> In normal operation are lookups performed to each one in round robin
> fashion?
No, they are tried in order. Depending on your resolver library you
may be able to set "options rotate" to cause the resolver to
round-robin the nameservers. This is supported in Solaris 10 not sure
about earlier releases.
>In /etc/resolv.conf if we have specified 2 nameservers i.e.
>nameserver x.x.x.x
>nameserver y.y.y.y
>If the first one fails, are lookups immediately performed to the
>second one (my thinking is yes)
I wouldn't say immediately, but after the proper timeout for the
failure of the first one, the second server will be tried. This
nameserver timeout is perhaps a bit too long on some systems, you may
notice it in interactive environments, but there's really no good way
to get around timeing out waiting for it to answer.
>I have read that some people disable nscd as it caused performance
>issues with lookups, is this true?
The main problem we had with nscd was long long ago, with huge number
of lookups (ie. on a mailserver), it sometimes corrupted its own
internal data structures and returned bogus data. We didn't have any
problems with it on normal nameserver load servers, nor with it
caching data too long unless we wanted to push a change through
quicker than normal TTL timeouts.
I wouldn't worry about what nscd is doing unless you are doing heavy
nameserver laods which most people aren't.
What do you mean by "immediately"? The only way the client suspects
failure is if no answer is returned. So take a look at the resolv.conf
man page and the timeout/retrans and attempts/retry parameters.
> In normal operation are lookups performed to each one in round robin
> fashion?
No. Most setups expect that the first one is used except in case of
failures. However, this can be changed. See the rotate keyword in the
same man page.
> I have read that some people disable nscd as it caused performance
> issues with lookups, is this true?
I don't know that performace is the usual reason, but some do disable
nscd (or at least set it to not cache hostnames) for various reasons.
(Caching can make troubleshooting more difficult, nscd does not honor
DNS TTL)
--
Darren
It's important to understand that this failure is when no reply is
received from the first nameserver. This involves a timeout waiting
for the reply that is typically about 30 seconds.
If the first nameserver returns a reply that says the requested
information does not exist, that is not a failure and no query
is sent to the second nameserver.
That can be a subtle distinction. Receiving a reply that says
"no such name" is a successful lookup. It received a reply, even
if the reply wasn't what you hoped to get. It's when no reply
is received that the other nameserver is tried.
>
>In normal operation are lookups performed to each one in round robin
>fashion?
>
Unless it has been changed in Solaris 10, the querys are sent to the
nameservers in the order which they are listed in the /etc/resolv.conf
file. The one listed first will get all the querys unless it doesn't
respond.
>
>I have read that some people disable nscd as it caused performance
>issues with lookups, is this true?
>
Yes and no. Nscd was designed to *increase* performance by caching
the answers on the local machine, so later querys can be answered
quickly from nscd's cache rather than sending the request through
the network to another machine and waiting for a reply.
This generally works well. The answer that comes back from the DNS
server includes a TTL (time-to-live) indication, so nscd knows when
to not answer the query from its cache, but instead ask the DNS
servers for the most current info.
However, there's a problem with negative answers. I.e., answers that
mean "there's no such hostname in DNS". There is no TTL indication on
that kind of answer, and for many years nscd would cache these negative
answers forever. Even after the DNS server was updated with the missing
info, nscd would intercept the query and return the "doesn't exist"
answer from its cache. This may have been fixed since I last worked
with Solaris (a few years).
That was the main reason I used to disable nscd on my Solaris machines.
In the earlier days of Solaris 2.6, nscd could often consume large
amounts of ram (a patch fixed this). That was another reason I used to
disable nscd.
-Greg
--
Do NOT reply via e-mail.
Reply in the newsgroup.
> What do you mean by "immediately"? The only way the client suspects
> failure is if no answer is returned. So take a look at the resolv.conf
> man page and the timeout/retrans and attempts/retry parameters.
It can also get SERVFAIL and possibly other responses which indicate
that the server is there but somehow broken.
Sometime around '93 or so I was told that nscd was written because Sun
had some very large customers that were running with /etc/passwd files
(no NIS or anything similar) in the multi-10000 line range. They didn't
want to use NIS, and they wanted things to be faster. (Don't do
'ls -l /var/spool/mail' on one of those machines unless you want to wait
a long time)
In that context, nscd probably works extremely well. Caching DNS just
isn't as useful.
--
Darren
That *some* server(s) is/are "somehow broken", perhaps. Certainly not
necessarily the one you were immediately querying. SERVFAIL is a general
"something went wrong which I don't have any other way to classify"
return code. (Common example: lame delegations.)
--
Chris Thompson
Email: ce...@cam.ac.uk