Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fno0w-0002o7-Er for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Aug 2018 16:42:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fno0u-0002nX-F8 for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Aug 2018 16:42:16 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fno0u-0002nP-1K for pgsql-hackers@lists.postgresql.org; Thu, 09 Aug 2018 16:42:16 +0000 Received: from mail-qt0-x242.google.com ([2607:f8b0:400d:c0d::242]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fno0q-00068z-Fb for pgsql-hackers@lists.postgresql.org; Thu, 09 Aug 2018 16:42:14 +0000 Received: by mail-qt0-x242.google.com with SMTP id c15-v6so7263632qtp.0 for ; Thu, 09 Aug 2018 09:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=kJvZCUq/DBcH5JnpkwF4Fuaf7JcCSN8KuzyNPQxBiJs=; b=zR52VtEMetqAP1uSRIuk3DFXj5afWZVMNNZjqzMOunGbIU4MVDc0S/7a/gn2218wTZ 38sfgzQL1N7UEFCOA1OQRU/yi8HLwDasW/zxmqZ3EoXK/ORXpGQGcBmMvxTLX2p94cJ+ aPRdr69xhKv65m+JK26w3qTwjf+uTmsLuv/7NFAyKR5pTVdwShzO9rTC2MhDJ3NIz5hK OO/wwspVXsIHlfkCvVYz5ZJssBmHyjG0ivyupB/M97cBlA1cnsv9HSrN9p+Fu1rWNKXE 9pE1MPuyZMOYCvnuR6RAp0T7Z7DDbtpYQ7XOzZJTe74z96vQ53Y6wm9FnEFKBdKZIFmE ChIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=kJvZCUq/DBcH5JnpkwF4Fuaf7JcCSN8KuzyNPQxBiJs=; b=NVnVnUUDo2RSEhC4PGhpud2oqcGibhDZfHj6FHaU1VcAL8sRfX2zuNAKuvOg4yKZSs kz3P7CVAuVF5yjKZ/+2jEI9YyNqKEJ6B4uiwkakjylygiLRHo7WWzBpbrqirITFLgWqc g0oYmmfoFnoUnETjiq+TIQOgmjTweNh2Eso2j3DEPgUmlLzOaWnemDnedDqrhNGTTwZz XCS/YS01Sp/5hqpIg/O5KIAK+lqlIVig5w57HfvzVcg8ANqe+WAZ6Bemnpb5QM07b+jM bUGUdpJE/6/qynisnBzwGLcRlWcGP0rE6fmXfhSXQfAREozRkfgJBjE4CYVJs6Hlk4Zv seaA== X-Gm-Message-State: AOUpUlHBhpemuF7bakN0nNY3z9icxfxxe6g1o5G7efrD1DuEH8ZYiPss 5Wk0JRa/RxfIBvu43QTPQyD52x0/mGLCeO/R0zw1TDfaZt8/NJ5YMVz0tJ8uXtXoktaN8naHMGO LkVrTkycsNiZfTZy9EodA7zzbqsk1UwySF/qOaIIT1h4iXArrpJlZxaNApaU9E+Ftj+UZDXbbhE 5c+/I44MY3f7i34Q== X-Google-Smtp-Source: AA+uWPzoF302lXXdKilPuRDcyNd4DvUjYQ+jTlMy/VGSnmtuvIt3b1pK7A2ue2koH3KPg7wWyOI5HQ== X-Received: by 2002:a0c:d805:: with SMTP id h5-v6mr2600541qvj.12.1533832931240; Thu, 09 Aug 2018 09:42:11 -0700 (PDT) Received: from alvin.alvh.no-ip.org ([190.121.29.3]) by smtp.gmail.com with ESMTPSA id i128-v6sm4485896qke.36.2018.08.09.09.42.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 09 Aug 2018 09:42:10 -0700 (PDT) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id 080F7465; Thu, 9 Aug 2018 12:42:09 -0400 (-04) Date: Thu, 9 Aug 2018 12:42:08 -0400 From: Alvaro Herrera To: Tom Lane Cc: pgsql-hackers@lists.postgresql.org Subject: Re: libpq should not look up all host addresses at once Message-ID: <20180809164208.3rsglmzjrg6rnudt@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4913.1533827102@sss.pgh.pa.us> User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2018-Aug-09, Tom Lane wrote: > Whilst fooling with the patch for CVE-2018-10915, I got annoyed by > the fact that connectDBStart() does the DNS lookups for all supplied > hostnames at once, and fails if any of them are bad. It was reasonable > to do the lookup there when we only allowed one hostname, but now that > "host" can be a list, this is really pretty stupid. The whole point > of allowing multiple hostnames is redundancy and avoiding a single > point of failure; but the way this is written, *each* of your servers' > DNS servers is a single point of failure all by itself. If any one of > them is down, you don't connect. Plus, in the normal case where you > successfully connect to something before the very last host in the list, > the extra DNS lookups are wasted --- and DNS lookups aren't that cheap, > since they typically involve a network round trip. I'm not very familiar with the libpq code structure, but I think connectDBStart() is not used for synchronous connections, only asynchronous, is that correct? If that's the case, then perhaps the reason this hasn't been more widely reported is simple that those two features (async conns and multihost conninfo strings) are just not very commonly used ... and even less so with failing DNS setups. > I'm tempted to call this a back-patchable bug fix, because the existing > behavior basically negates the entire value of the multi-hostname feature > once you consider the possibility of DNS server failures. But given the > lack of field complaints, maybe that's an overreaction. Well, since it's broken, then I don't think it serves anybody very well. I vote to backpatch it to 10. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services