/dev/rob0 wrote the following on 10/17/2013 12:17 PM:
On Thu, Oct 17, 2013 at 12:01:39PM -0500, Blake Hudson wrote:
Peter wrote the following on 10/16/2013 5:32 PM:
On 10/16/2013 04:03 AM, Blake Hudson wrote:
Thanks for the reminder about where to locate the test programs
Wietse. I confirmed this appears to be an issue with RHEL5 (all
patches applied today). The issue is resolved in RHEL6. I am
running a local instance of BIND (bind-9.3.6-20.P1.el5_8.6) on
the affected server(s).
el5 also has bind97 packages, try upgrading to that and see if
it fixes your issue.
BIND seems to be working fine as far as I can tell... All the
normal tools: dig, host, nslookup are working when querying either
the local BIND 9.3 instance or a remote 9.8 instance. The problem
Yes, that sounds correct. When dig returns what you expect, DNS is
working.
seems limited to applications that rely on the kernel function
getnameinfo. How would updating to bind 9.7 resolve that?
FWIW that is a libc function, not a kernel function. And yes, you're
right again; changing BIND won't help.
Did you look at Red Hat's bug database? Perhaps they fixed this for
RHEL5 also?
Thanks for the confirmation Rob. I had gotten a couple suggestions (on
and off list) to switch to different DNS software and was honestly
curious if that would have any impact.
Based on your suggestion, I did find the following bug report for glibc
from 2008 (that looks like Wietse had an indirect hand in):
http://sourceware.org/bugzilla/show_bug.cgi?id=5790
It appears that the issue was resolved in glibc due to Leonardo's
diligence. Unfortunately, although the issue was reported to RH via
their Fedora bugzilla it doesn't appear RH ever took any action. Based
on my results, I don't believe RH ever backported this fix to any
version of RHEL. I'm not too worried about it since we've migrated most
of our servers to RHEL 6 and the issue is resolved in the version of
glibc used in there. However, I will see if I can file a bug report and
have RHEL take action to prevent others from running into the same issue.
Thank you for your and Weitse's comments and suggestions which helped
confirm where this issue was so I can address the problem directly and
mitigate any additional customer impact.
--Blake
