From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id CBCB33858D20 for ; Mon, 11 Mar 2024 10:51:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CBCB33858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org CBCB33858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710154287; cv=none; b=KsF0Th08nBGUCQjPRrLLjO4cpgiDLjz8Pd+8Xewa98mPYUhc6C1+uObQJq9nampEcSKJNfkBN5t+vJfRyZx4AavKl4zX1srJBQU1Z/h/69GPBLCc7cIopd2sSyt4jwjbSIGEAfHZY7BCMzTX/KIUpXA7xERRnMdC60q/UO1VDlg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710154287; c=relaxed/simple; bh=MwBfzFT1UdcUGxgN3Ki/I9U+/5udfNJYqmKhZZbL2fY=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=OJWJhpbc7rlSBNGRP2pZ7tV7T5mXWs79L6FC5E/+InR9vNP9CmF8pgm6kUmuL/R1L0bihOJWmfd/GO3xpAVNidQDaAeQ9Gk+ofY7O7wFDLfp1NnpVJl6c6bSSEMCD7SpUxy84dBsEkDGA7Jn7gY0oCSW9I5PbEym56Ug8ENWrUo= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1710154285; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qk14OUkUJqf2DL5Nf/v5pA6n2aW9Sp29OkXt7jIbh74=; b=b+TmJKkVu2GAL//RyCv5wAuBkD9ljSDOzy2uk6wepJQUAUKOXNCy6MbROd8e8JsfrY0Yb+ MIC+pPHPVJIJCiLzKUxoUzY00VlRBmeqDIBk8awPT2EMM4qdHm4ntvPcMLohtW2iTubNTV I9RoldEJu1IBecHf9wlg9ubh+5RC5OY= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-657-F-Twr2WOMkmfjz7WxMZpIg-1; Mon, 11 Mar 2024 06:51:22 -0400 X-MC-Unique: F-Twr2WOMkmfjz7WxMZpIg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id EDD523C0D187; Mon, 11 Mar 2024 10:51:21 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.78]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 219312166AE4; Mon, 11 Mar 2024 10:51:20 +0000 (UTC) From: Florian Weimer To: John Levon Cc: libc-alpha@sourceware.org Subject: Re: Issue with stale resolv.conf state References: Date: Mon, 11 Mar 2024 11:51:19 +0100 In-Reply-To: (John Levon's message of "Mon, 11 Mar 2024 09:08:26 +0000") Message-ID: <874jddqbx4.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * John Levon: > I don't understand the first part of the comment, but indeed, ->resp doesn't > match. In particular: > > 62 return ctx->resp->options == ctx->conf->options > > 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 > 1001 there which don't handle two outstanding > 1002 requests from the same source. There are also > 1003 broken firewall settings. If we time out after > 1004 having received one answer switch to the mode > 1005 where we send the second request only once we > 1006 have received the first answer. */ > 1007 if (!single_request) > 1008 { > 1009 statp->options |= RES_SNGLKUP; > 1010 single_request = true; > 1011 *gotsomewhere = save_gotsomewhere; > 1012 goto retry; > 1013 } > 1014 else if (!single_request_reopen) > 1015 { > 1016 statp->options |= RES_SNGLKUPREOP; > 1017 single_request_reopen = true; > 1018 *gotsomewhere = save_gotsomewhere; > 1019 __res_iclose (statp, false); > 1020 goto retry_reopen; > 1021 } That's a very good point. Yes, the current reloading code does not take into account that we change _res.options dynamically based on network behavior. That automatic configuration change based on temporary network glitches is problematic in other contexts as well (it may further trigger bugs in dual query processing). Maybe we should just remove the automatic downgrade, basically not persist this across queries anymore. Thanks, Florian