From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 65CDC3858CD1; Tue, 12 Mar 2024 06:43:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 65CDC3858CD1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1710225813; bh=wfgCoL8Sbt3kBJohbD216AM1rcqv4OSzrB892UkSze0=; h=From:To:Subject:Date:From; b=oJeBtC5bMHpBaifd84c1/VerEGAldDRqH8XF2InKg5PkEBrW+NqH3enmXnX1lfUgE 2GUbLx41SWL13DI28q+afojEm/6PvNrGr5kzjty0RX5rjZTqFDEkVJyV0QMp87spyq khqRQi/P3Cw7zsqEfOWasfYkdZLk1iH87/URFcKA= From: "fweimer at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug network/31476] New: Automatic activation of single-request options break resolv.conf reloading Date: Tue, 12 Mar 2024 06:43:31 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: network X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: fweimer at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone flagtypes.name Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31476 Bug ID: 31476 Summary: Automatic activation of single-request options break resolv.conf reloading Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: network Assignee: unassigned at sourceware dot org Reporter: fweimer at redhat dot com Target Milestone: --- Flags: security- Initial report from John Levon: Issue with stale resolv.conf state John traced the lack of reloading to a change in _res.options: =E2=80=9C I don't understand the first part of the comment, but indeed, ->resp doesn't match. In particular: 62 return ctx->resp->options =3D=3D ctx->conf->options=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 and ctx->resp (aka _resp) has 0x47002c1 whereas ctx->conf has 0x41002c1. I'm not sure but I suspect the additional RES_SNGLKUP|RES_SNGLKUPREOP may be due to this code: 1000 /* There are quite a few broken name servers out= =20=20=20=20=20=20=20 1001 there which don't handle two outstanding=20=20= =20=20=20=20=20=20=20=20=20=20 1002 requests from the same source. There are also= =20=20=20=20=20=20 1003 broken firewall settings. If we time out after= =20=20=20=20=20 1004 having received one answer switch to the mode= =20=20=20=20=20=20=20 1005 where we send the second request only once we= =20=20=20=20=20=20=20 1006 have received the first answer. */=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 1007 if (!single_request)=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1008 {=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 1009 statp->options |=3D RES_SNGLKUP;=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1010 single_request =3D true;=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1011 *gotsomewhere =3D save_gotsomewhere;=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 1012 goto retry;=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 1013 }=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 1014 else if (!single_request_reopen)=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1015 {=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 1016 statp->options |=3D RES_SNGLKUPREOP;=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 1017 single_request_reopen =3D true;=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1018 *gotsomewhere =3D save_gotsomewhere;=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 1019 __res_iclose (statp, false);=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1020 goto retry_reopen;=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1021 }=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 I'm guessing these got set when the VPN dropped routing to the old nameserv= ers, but before the next getaddrinfo() came in, thus leading to the match failin= g. =E2=80=9D --=20 You are receiving this mail because: You are on the CC list for the bug.=