Problems with Name Resolution - Itanium Only

[Craig Johnson_1]

HP-UX 11.23, brand new rx6660's.

/etc/hosts contains names and IP's of EVERY host in our network

/etc/nsswitch.conf contains ONLY: hosts: files [NOTFOUND=continue] dns

And /etc/resolv.conf has four lines, a search order that is valid, and four nameserver entries. Unknown to us, the last two of those nameservers were recently retired.

So, what we saw was this. Outbound connections using ssh or rsh from Itanium boxes using this configuration hung up for about 30 seconds before completing normally. PA-RISC boxes running 11.11 with the same setup exhibited NO problems.

Removing the last two retired nameservers from /etc/resolv.conf fixed the issue.

So why are the Itaniums being so picky about the contents of /etc/resolv.conf? Why do just use one of the first two (good) nameserver entries and ignore the rest?

This seems like a bug to me.

[Craig Johnson_1]

I need to clarify - that the bad behaviour only occurred if we used hostnames. If we used IP's, there was no issue.

[Tim Nelson]

Typically pauses like this are due to reverse IP/name lookups. All your new servers may not have both entries in DNS hence a reverse lookup is timing out through all four nameservers and causing you the delay espcecially once it hits those last two that are non existant.

Also, noted in the man pages for resolv.conf the max number / default nameserver listings is three.

[Craig Johnson_1]

Even if the max is three specifying more shouldn't cause a problem like that.

Why don't the PA-RISC boxes care?

Maybe because they behave more "normally"? :D

[Robert-Jan Goossens]

Craig,

Have a look at this doc.

Title: NameResolution delays if IPv6 installed..telnet, ftp,sendmail etc
Document ID: emr_na-c00929231-2

http://www12.itrc.hp.com/service/cki/search.do?prevQueryString=&mode=id&searchString=KBRC00016111&submit1=Search+%C2%BB&docTypeAll=yesX&docType=Advisories&docType=WhitePapers&docType=EngineerNotes&docType=SecurityBulletins&docType=Manuals&docType=Patch&dateSearchType=lastXdays&dateRange=all&startDateYear=1999&startDateMonth=0&startDateDay=1&endDateYear=1999&endDateMonth=2&endDateDay=3&resPerPage=2...

Regards,
Robert-Jan

[rick jones]

My guess would be that between 11.11 and 11.23 something changed that changed the order in which the nameservers were queried. One way to look into that would be to tusc (system call trace) the ssh or rsh from the Itanium and PA-RISC boxes to see which of the nameserver's each queries first.

I suspect that had the processes been long-lived - ie made other name lookups, the resolver library would have remembered that some of the nameservers were unreachable and not tried them (first) later-on.

If indeed 11.23 does the order slightly differently, it would be 11.23 and not Itanium that is the difference - had your PA-RISC systems been running 11.23 one would expect the same issue.

[Bill Hassell]

Check the name resolution using nsquery as in:

nsquery hosts www.hp.com
and
nsquery hosts 15.200.30.22

This tool gives a bit more detail than nslookup. 30 second delays almost always indicate a forward or reverse (IP) lookup failure in one of the DNS servers. DNS servers are considered to be a part of a good network security policy and thus, these servers cannot disappear without widespread consequences. While it is possible to change the timeout value using resolv.conf, DNS lookups can be so pervasive that overall system performance (especially with commercial backup programs such as DataProtector) will be seriously impacted. To avoid this critical dependence on DNS servers for production programs, use files (/etc/hosts) first and leave the occasional hosts to DNS (man nsswitch.conf).

[Craig Johnson_1]

I am very familiar with DNS outages causing problems, but in this case, the first two DNS servers specified in /etc/resolv.conf were working perfectly, with no forward/reverse lookup issues for any of the servers we were trying to work with.

Note also I posted the contents of our /etc/nsswitch.conf file above, AND, our /etc/hosts file contains the names and IP's of every server in our managed environment.

Imagine this. We have a script that queries the VG's for a package on every node in a cluster. Over the weekend, we had a package die with 11 VG's that lived on a six-node cluster. The command took over 1/2 hour to complete, instead of a minute or two. So you see the impact this can have.