CLOSE_WAIT connection duea to squid upstream bug #4007

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux (RHEL) 7
  • squid-3.5.20-10.el7

Issue

  • Is there a fix in the Red Hat distributed squid for the upstream squid bug #4007 Hang on DNS query with dead-end CNAME?
  • We are observing unexpected CLOSE_WAIT connections after telnet quit:
# netstat -natp
tcp6 1 0 ::1:8080  ::1:4285     CLOSE_WAIT  -
$ /usr/bin/squidclient -p 8080 mgr:active_requests
...
Connection: 0x565477e1ee28
        FD 33, read 46, wrote 0
        FD desc: Reading next request
        in: buf 0x56547877c640, used 0, free 39
        remote: [::1]:4285
        local: [::1]:8080
        nrequests: 1
uri www.example.com:443
logType TAG_NONE
out.offset 0, out.size 0
req_sz 46
entry (nil)/N/A
start 1534921819.179745 (707.093529 seconds ago)
username -
delay_pool 0

Resolution

Update to squid-3.5.20-12.el7_6.1 shipped with 7.6.Z Stream Advisory RHBA-2019:0181 or newer.

Root Cause

Previously, if a host was requested with a Canonical Name (CNAME) record that did not point to an IP address, the squid server did not terminate the connection. Consequently, the connection became unresponsive. This bug has been fixed, and squid now closes the connection immediately in the described scenario.

Diagnostic Steps

When given a host with a CNAME pointing to no address the connection hangs forever with the following in the log:

18:01:01 kid1| ipcacheParse: No Address records in response to 'example.com'
18:05:15 kid1| ipcacheParse: No Address records in response to 'example.com'

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments