/etc/hosts still doesn't resolve the IP ?

[Andrew_4]

I'm getting the following error in my mail log:

sendmail[19627]: gethostbyaddr(10.114.197.171) failed: 2

Upon searching forums, it seems just adding an entry into /etc/hosts, which allows the IP to resolve will stop sendmail reporting this problem. So, with an entry in /etc/hosts, why is nslookup still failing, as shown below ?

# /etc/nsswitch.files:
hosts: dns [NOTFOUND=continue UNAVAIL=continue TRYAGAIN=return] files [NOTFOUND=return UNAVAIL=continue TRYAGAIN=return]

#nslookup 10.114.197.171
Name Server:
Address: 10.112.200.201

Trying DNS
looking up FILES
*** No hostname information is available for "10.114.197.171"

#cat /etc/hosts | grep 10.114.197.171
10.114.197.171 hostname_hb hostname_hb #Heartbeat for cluster


This looks a little strange to me...

Any ideas ?

[Bill Hassell]

If there is no file called /etc/nsswitch.conf, then only DNS will be used if /etc/resolv.conf exists. Unfortunately, HP supplies several sample files in the /etc directory but they do not have any effect.

[John Poff]

Hi,

You listed the contents of your nsswitch.files file. Is that a typo? If not, what does your nsswitch.conf file look like?

JP

[Andrew_4]

Thanks for the suggestions...but I believe my nsswitch.conf is setup correctly:

# cat /etc/nsswitch.conf
...
hosts: dns [NOTFOUND=continue UNAVAIL=continue TRYAGAIN=continue] files [NOTFOUND=return UNAVAIL=continue TRYAGA
IN=return]
...


hmmmmmm.... It seems quite strange that I've clearly got the address listed in /etc/hosts, and the nslookup 'tries' files... but still doesn't find it!

Andrew

[John Poff]

Hi,

Ok. Have you tried commenting out the hosts: line in nsswitch.conf temporarily, and adding a hosts: line that just looks at files, and then trying the nslookup? I'd try to get nslookup working correctly just with your hosts file, without using DNS, so you can eliminate a big variable for debugging the problem.

Also, your hosts entry for 10.114.197.171 looks like it has the same alias entry twice. Have you tried it with just one of the entries, or with making one of the alias entries have the fully qualified domain name?

JP

P.S. Your profile says your are in Australia, and I thought about making some lame joke about the nslookup working backwards down there, but you probably hear enough of that anyway. :)

[Andrew_4]

We're not backwards down here !... we work the same as the US... hence the recent events in Bali.

Anyway... let's not get political!

Yes... it resolves as soon as I change it to look at 'files' first...

But, when using resolving to DNS first, as you can tell from the nslookup output, it states that it IS checking files:

Trying DNS
looking up FILES
*** No hostname information is available for "10.114.197.171"


So, for some reason, if it's looked at the DNS first and can't find it there... then it looks at /etc/hosts - but still doesn't find it!

Very strange. I'm trying this across three systems, all with the same results. I've even tried adding after the SUCCESS=return option after the 'files' section in nsswitch.conf !

Thanks for the suggestions though!

Andrew

[John Poff]

Andrew,

The only other post I could find with the same error message as yours (No hostname information is available) was an example where the /etc/hosts entry was just like yours, with the same alias twice. Can you try it with one of the aliases removed? Instead of:

10.114.197.171 hostname_hb hostname_hb #Heartbeat for cluster

Try this?:

10.114.197.171 hostname_hb #Heartbeat for cluster


JP

P.S. We won't get political. All our prayers are with you after Bali.

[Patrick Wallek]

In /etc/hosts, you might also try:

10.114.197.171 hostname_hb.domainname.com hostname_hb

and see if that helps you any.

[John Poff]

What does your /etc/resolv.conf file look like?

JP

[Andrew_4]

yep... tried both of those options.

I've tried the following combinations:

10.114.197.171 hostname_hb
10.114.197.171 hostname_hb.domain.com hostname_hb
10.114.197.171 hostname_hb hostname_hb


None of which seem to get picked up...

I've also checked for any leading spaces, which may muck up the interpretation, but it all looks okay.

I've also tried this:

Added this to /etc/hosts:
15.15.15.15 test test
# nslookup 15.15.15.15
Name Server:
Address: 10.112.200.201

Trying DNS
looking up FILES
*** No hostname information is available for "15.15.15.15"

# nslookup test
Name Server:
Address: 10.112.200.201

Trying DNS
looking up FILES
*** No address information is available for "test"


Very strange isn't it !

I'm starting to think it might be resolved via some newer patches... What patch set contains updates to the gethostbyname/gethostbyaddr functions ?

Andrew

[John Poff]

I was just looking at patches too. Do you have PHNE_23274 installed? It patches the nslookup command.

JP

[John Poff]

I got curious. I dialed into work and setup one of our test boxes to have the nsswitch.conf file set for hosts: just like yours, and I added the 10.114.197.171 entry to /etc/hosts like yours. My nslookup resolves the hostname and IP just fine. I have that patch PHNE_23274 installed on this box (I'm running 11.00 and assuming you are too?).

JP

[Andrew_4]

hmmmm.... we could be getting somewhere now.

I don't have that latest BIND patch...(PHNE_23274)... I'm on two revisions previous (PHNE_14618).

The latest patch states : "nslookup" cannot resolve hostnames properly when there is wild card entry in DNS data files and a search list having multiple entries in resolv.conf.

So I commented out my secondary DNS in /etc/resolv.conf... but that didn't fix it either.

But there were a few other SRs & JAG which may fix the problem I'm experiencing.

Looks like I might have to push forward my patch analysis. I don't want to apply this patch just yet though, as I want to roll it through as a part of a total patching process, from test through to production.

Thanks very much for your help - it certainly looking like a patch solution will be required. Which I'm sort of glad about - because I didn't think I would be making obvious mistakes with basic names resolution settings !

Have some points just for being so helpful!

Andrew

[John Poff]

Cool! Glad I could be of some help. That patch doesn't require a reboot, so you could probably test it pretty easily on a test system if you get a chance.

Good luck!

JP

[John Bolene]

The lookup probably works if you remove the underscore.

Most DNS versions cannot handle names with special characters.

[rick jones]

in the past i have been told that nslookup does not strictly honour the /etc/nsswitch.conf file in all cases - that may be related tosome of the patches mentioned thusfar.

it has also been suggested to me, quite often, that switching to dig instead of nslookup would be goodness. i'm not _certian_, but I think a copy of dig comes with the named that ships from www.software.hp.com if not with the base OS itself these days - of course, there is always www.isc.org for sources or the porting centre for possible binaries

[Hai Nguyen_1]

Andrew,

I guess that you are using DNS version 4.X. There is a bug in DNS 4.X which is resolved in BIND 8.1.2.

Below are some of the fixes described in BIND 8.1.2 which addresses your issue:
.....
- "nslookup" does not work fine in the following case:
If the file /etc/nsswitch.conf is configured as :-
hosts: dns [NOTFOUND=continue] files
and host name is not registered in DNS but is present in the file
/etc/hosts, "nslookup" on that host returned error.

-If the switch policy for host lookup was as below:
hosts: dns [NOTFOUND=continue] files
"nslookup" was failing to find hosts that were in files only.
.............
I ran into the SAME sendmail problem as you and my BIND upgrade fixed the issue. Read this link below for more info:
http://www.software.hp.com/products/DNS_BIND/index.html

Hai

[Hai Nguyen_1]

Andrew,

I would try to change:

# /etc/nsswitch.files:
hosts: dns [NOTFOUND=continue UNAVAIL=continue TRYAGAIN=return] files [NOTFOUND=return UNAVAIL=continue TRYAGAIN=return]

to:
# /etc/nsswitch.files:
hosts: dns [NOTFOUND=continue UNAVAIL=continue TRYAGAIN=continue] files [NOTFOUND=return UNAVAIL=continue TRYAGAIN=return]

and see if this will resolve the issue.

Hai