public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "sourceware at psanetra dot de" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug nss/29017] New: Change resolv.conf default to single-request Date: Fri, 01 Apr 2022 17:15:03 +0000 [thread overview] Message-ID: <bug-29017-131@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=29017 Bug ID: 29017 Summary: Change resolv.conf default to single-request Product: glibc Version: 2.10 Status: UNCONFIRMED Severity: normal Priority: P2 Component: nss Assignee: unassigned at sourceware dot org Reporter: sourceware at psanetra dot de Target Milestone: --- glibc 2.9 introduced "same time" lookup of ipv4 and ipv6 host names via DNS and glibc 2.10 introduced the option "single-request" to introduce explicit sequential lookups of those addresses. The default since 2.10 is to send those lookups in parallel. A known issue is that some firewalls and DNS servers fail to handle those parallel requests and return only a single response for one of those requests. In these cases glibc waits for 5 seconds and then switches to single-request mode for a specific process. This default behavior leads to very bad performance on short living processes and is very hard to debug as specialized knowledge about resolv.conf and glibc is required. See reports on Stack Exchange: https://unix.stackexchange.com/questions/141163/dns-lookups-sometimes-take-5-seconds https://serverfault.com/questions/906397/how-do-i-set-the-single-request-option-in-networkmanager https://unix.stackexchange.com/questions/290987/resolving-hostname-takes-5-seconds In my specific case the parallel lookups work just fine at home, while always causing issues at work. We have the year 2022 and these issues still occur, so it was not some kind of issue that went away by time as it was possibly expected when glibc 2.10 was released. I propose to change the default behavior to "single-request" to avoid those issues by default and optionally introduce a new option to lookup ipv4 and ipv6 addresses in parallel to improve performance, although I do not expect that this performance gain is really noticable anymore with the internet connections we have today. -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2022-04-01 17:15 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-01 17:15 sourceware at psanetra dot de [this message] 2022-04-01 17:17 ` [Bug nss/29017] " sourceware at psanetra dot de 2024-03-12 6:45 ` [Bug network/29017] " fweimer at redhat dot com 2024-03-12 19:54 ` cristian at rodriguez dot im 2024-03-12 19:58 ` sam at gentoo dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-29017-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).