This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug network/19692] New: Reduce recursive resolver stress for large responses


https://sourceware.org/bugzilla/show_bug.cgi?id=19692

            Bug ID: 19692
           Summary: Reduce recursive resolver stress for large responses
           Product: glibc
           Version: 2.24
            Status: NEW
          Severity: normal
          Priority: P2
         Component: network
          Assignee: unassigned at sourceware dot org
          Reporter: fweimer at redhat dot com
        Depends on: 19591
  Target Milestone: ---

NSS uses an API style where the caller allocates a response buffer and is told
to try again, with a larger buffer, if the recusor-supplied data does not fit
into the buffer.  This is painful with all NSS database, but rather hideous
with host name lookups over nss_dns.  A typical sequence goes like this:

  UDP query
  UDP response with TCP=1
  TCP query
  TCP response
  TCP response parsing in nss_dns notices that the buffer is not large enough
  repeat

One way to implement this is to pass around reallocatable buffers, but NSS from
static libraries will need a fix for bug 19591.  Another potential fix would
involve a one-record cache, so that nss_dns does not have to redo the actual
DNS lookup.

Due to internal buffers, this also affects getaddrinfo, gethostbyname etc., not
just the _r variants.

To some degree, this also impacts other databases and NSS service modules, but
I think the effect with nss_dns is more pronounced.


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=19591
[Bug 19591] malloc does not work across a static dlopen boundary
-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]