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
