[Bug 613662] Re: nscd doesn't cache host entries

[Adam Conrad]

** Description changed:

+ [Impact / Justification]
+ For nscd users, the performance difference between a cached DNS lookup and a remote query can be anywhere from milliseconds to whole seconds, depending on the network and random luck.  I've already verified here today that the concerns originally raised in the upstream bug have since been fixed, and Debian also dropped this patch a while ago, we just failed to sync with them when they did.
+ 
+ [Test Case]
+ As stated above, I've already tested that the actual root issue that led to the patch has been resolved, so the only thing to test is that the build binaries no longer have host caching disabled in the default /etc/nscd.conf
+ 
+ [Regression Potential]
+ Very low to non-existent.  It's a single line change to a conffile, reverting a workaround that hasn't been needed in a long while.
+ 
+ [Original Report]
  Binary package hint: nscd
  
  Debian (and by implication Ubuntu) are the only distros to disable nscd
  hosts caching. In most cases, it is deployed with the expectation to
  mitigate expensive lookups (eg over VPN).
  
  The bug cited [1] has been rejected by the core glibc developers three
  years ago as not a bug; all other distros (including Redhat EL and
  Novell SLES) have this functionality enabled. Why should we continue to
  penalise Ubuntu's performance any longer, in cases where nscd is
  deployed to improve performance?
  
  [1] http://sourceware.org/bugzilla/show_bug.cgi?id=4428

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to eglibc in Ubuntu.
https://bugs.launchpad.net/bugs/613662

Title:
  nscd doesn't cache host entries

Status in “eglibc” package in Ubuntu:
  In Progress
Status in “eglibc” source package in Precise:
  New
Status in “eglibc” source package in Quantal:
  New

Bug description:
  [Impact / Justification]
  For nscd users, the performance difference between a cached DNS lookup and a remote query can be anywhere from milliseconds to whole seconds, depending on the network and random luck.  I've already verified here today that the concerns originally raised in the upstream bug have since been fixed, and Debian also dropped this patch a while ago, we just failed to sync with them when they did.

  [Test Case]
  As stated above, I've already tested that the actual root issue that led to the patch has been resolved, so the only thing to test is that the build binaries no longer have host caching disabled in the default /etc/nscd.conf

  [Regression Potential]
  Very low to non-existent.  It's a single line change to a conffile, reverting a workaround that hasn't been needed in a long while.

  [Original Report]
  Binary package hint: nscd

  Debian (and by implication Ubuntu) are the only distros to disable
  nscd hosts caching. In most cases, it is deployed with the expectation
  to mitigate expensive lookups (eg over VPN).

  The bug cited [1] has been rejected by the core glibc developers three
  years ago as not a bug; all other distros (including Redhat EL and
  Novell SLES) have this functionality enabled. Why should we continue
  to penalise Ubuntu's performance any longer, in cases where nscd is
  deployed to improve performance?

  [1] http://sourceware.org/bugzilla/show_bug.cgi?id=4428

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/613662/+subscriptions