Resolving DNS hosts with default nsswitch.conf

ChrisS

unread,

Apr 14, 2010, 8:53:44 AM4/14/10

to

Am I missing something here? I'm sure I must be.

For the past few years I've noticed when using the default
nsswitch.dns sample file for /etc/nsswitch.conf that some command line
tools don't resolve host names correctly, (ping & wget)

For example, I'll have on the hosts and ipnotes lines "files dns".
And the man page for nsswitch.conf indicates the default criteria for
all other sources is "SUCCESS=return NOTFOUND=continue".

The only way to get some of these tools to resolve a DNS host
correctly is to manually place the "NOTFOUND=continue" between the
"files dns" entry on both lines, hosts & ipnodes. Then the universe
is whole again.

I don't remember it being like that in years past. Has something
changed?

The nslookup command works just fine without the NOTFOUND=continue
entry manually placed in the nsswitch.conf file. I can resolve DNS
hosts until the cows come home.

Using Solaris 10 (tried many different releases and patch levels). I
also think Solaris 9 behaves in a similar fashion now.

Thanks, just curios.

Chris

Oscar del Rio

unread,

Apr 14, 2010, 11:04:43 AM4/14/10

to

On 04/14/10 08:53 AM, ChrisS wrote:
> For the past few years I've noticed when using the default
> nsswitch.dns sample file for /etc/nsswitch.conf that some command line

> tools don't resolve host names correctly, (ping& wget)

>
> For example, I'll have on the hosts and ipnotes lines "files dns".
> And the man page for nsswitch.conf indicates the default criteria for
> all other sources is "SUCCESS=return NOTFOUND=continue".
>
> The only way to get some of these tools to resolve a DNS host
> correctly is to manually place the "NOTFOUND=continue" between the

> "files dns" entry on both lines, hosts& ipnodes. Then the universe

> is whole again.
>
> I don't remember it being like that in years past. Has something
> changed?
>
> The nslookup command works just fine without the NOTFOUND=continue
> entry manually placed in the nsswitch.conf file. I can resolve DNS
> hosts until the cows come home.
>
> Using Solaris 10 (tried many different releases and patch levels). I
> also think Solaris 9 behaves in a similar fashion now.

I'm running several versions of solaris, from Solaris 2.5 to opensolaris
snv_134, default nsswitch.dns copied to nsswitch.conf, without any name
resolution problems.

Check if you have any problems in your "files" name resolution
(/etc/hosts, etc) or maybe with nscd.

"nslookup" never uses nsswitch.conf. To test name resolution use
"getent" instead

$ getent hosts www.sun.com
72.5.124.61 www.sun.com

$ getent hosts www.oracle.com
72.246.43.96 a398.g.akamai.net www.oracle.com www.oracle.com.edgesuite.net
72.246.43.56 a398.g.akamai.net www.oracle.com www.oracle.com.edgesuite.net

"truss" might help you debug it.

ChrisS

unread,

Apr 14, 2010, 12:34:24 PM4/14/10

to

Ah, that's a good reminder, thanks. Files "appears" to be okay.

After resolving the address successfully, I then took out the
"RETURN=continue" from between "files" and "dns" on both ipnodes and
hosts lines in nsswitch.conf. I was still able to resolve the address
now with wget.

I then restarted name-service-cache, (and eventually disabled for
testing) and I was still able to resolve the address. The address is
an internal DNS host for my opencsw repository.

I even rebooted the host in question with name-service-cache svc
disabled and once again was still able to resolve (ARP tables maybe?)

Could it have anything do with the fact that I had disable the NIS/
client service and made the host a NON-NIS client altogether? It
installed from my jump server with NIS/client active (oops).

Beats me.

Thanks,

Bernd Senf

unread,

Apr 15, 2010, 5:18:02 AM4/15/10

to

from germany:

getent hosts www.sun.com
72.5.124.61 www.sun.com

getent hosts www.oracle.com
212.201.100.179 a398.g.akamai.net www.oracle.com www.oracle.com.edgesuite.net
212.201.100.184 a398.g.akamai.net www.oracle.com www.oracle.com.edgesuite.net

mfg