Bug 656014 - nscd host caching does not respect DNS TTLs
Summary: nscd host caching does not respect DNS TTLs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glibc
Version: 6.0
Hardware: x86_64
OS: Unspecified
low
medium
Target Milestone: rc
: ---
Assignee: Andreas Schwab
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On:
Blocks: 929035 962903
TreeView+ depends on / blocked
 
Reported: 2010-11-22 21:07 UTC by Matt Savona
Modified: 2016-11-24 15:37 UTC (History)
6 users (show)

Fixed In Version: glibc-2.12-1.15.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 929035 (view as bug list)
Environment:
Last Closed: 2011-05-19 13:16:13 UTC
Target Upstream Version:


Attachments (Terms of Use)
nscd.log - debug 9 (9.14 KB, text/plain)
2010-11-23 13:12 UTC, Matt Savona
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0584 0 normal SHIPPED_LIVE glibc bug fix and enhancement update 2011-05-18 17:56:51 UTC

Description Matt Savona 2010-11-22 21:07:58 UTC
Description of problem:
---------------------------------------------------------------------
When nscd is enabled and a lookup is performed for a DNS record with a TTL of 0, nscd proceeds to cache the result when it should not. This behavior is seen via lookups initiated by getaddrinfo when it should not.

Version-Release number of selected component (if applicable):
---------------------------------------------------------------------
Tested against RHEL5 and RHEL6, up to versions:
glibc-2.12-1.7.el6.x86_64
nscd-2.12-1.7.el6.x86_64

How reproducible:
---------------------------------------------------------------------
100%

Steps to Reproduce (hostnames and IPs masked):
---------------------------------------------------------------------

# DNS RECORD IS:
;; ANSWER SECTION:
nfs.appliance.company.com. 0     IN      A       1.1.1.55

(where the returned IP may vary based on specific conditions determined by the NFS appliance)

# WITH NSCD ENABLED:
/etc/init.d/nscd start
/etc/init.d/nscd reload
ltrace -f getent ahosts nfs.appliance.company.com 2>&1 | egrep "getaddrinfo|STREAM" | grep -v printf
getaddrinfo("nfs.appliance.company.com", NULL, 0x7fff65794a90, 0x7fff65794b08) = 0
1.1.1.56    STREAM nfs.appliance.company.com
# [ run this as many times as you want, same result ]

# WITH NSCD DISABLED:
/etc/init.d/nscd stop
ltrace -f getent ahosts nfs.appliance.company.com 2>&1 | egrep "getaddrinfo|STREAM" | grep -v printf
getaddrinfo("nfs.appliance.company.com", NULL, 0x7ffff521eb80, 0x7ffff521ebf8) = 0
1.1.1.56    STREAM nfs.appliance.company.com
ltrace -f getent ahosts nfs.appliance.company.com 2>&1 | egrep "getaddrinfo|STREAM" | grep -v printf
getaddrinfo("nfs.appliance.company.com", NULL, 0x7fffb80836b0, 0x7fffb8083728) = 0
1.1.1.53    STREAM nfs.appliance.company.com
ltrace -f getent ahosts nfs.appliance.company.com 2>&1 | egrep "getaddrinfo|STREAM" | grep -v printf
getaddrinfo("nfs.appliance.company.com", NULL, 0x7fff9d6aa5e0, 0x7fff9d6aa658) = 0
1.1.1.57    STREAM nfs.appliance.company.com
# [ run this as many times as you want, different results ]
  
Expected results:
---------------------------------------------------------------------
For DNS records with a TTL of 0, the results with NSCD enabled should be identical to the results seen with NSCD disabled.

Additional info:
---------------------------------------------------------------------

References regarding expected nscd and getaddrinfo behavior here:
http://udrepper.livejournal.com/16362.html
http://sourceware.org/bugzilla/show_bug.cgi?id=4428

Comment 2 Andreas Schwab 2010-11-23 10:38:12 UTC
Please enable full debug level and attach the nscd log.

Comment 3 Matt Savona 2010-11-23 13:12:26 UTC
Created attachment 462322 [details]
nscd.log - debug 9

Comment 5 Matt Savona 2011-01-13 15:11:57 UTC
Will the fix referenced here in glibc-2.12-1.15.el6 for RHEL6 be backported for RHEL5 as well?

Comment 8 errata-xmlrpc 2011-05-19 13:16:13 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0584.html


Note You need to log in before you can comment on or make changes to this bug.