On Fri, Jun 13, 2008 at 12:47:22PM -0400, Andrew Dunstan wrote:
> The reason it wasn't done years ago was that there was disagreement on the
> way it should work. And the TODO actually lists several alternatives:
>
> Host name lookup could occur when the postmaster reads the
> pg_hba.conf file, or when the backend starts. Another solution would
It needs to happen at authentication time. I'm not sure whether
"reads the pg_hba.conf" or "backend starts" is the right way to say
that, but it must happen only when you're actually authenticating the
host entry.
This is because DNS RRs have a TTL on them, so looking up the host at
any moment other than when you're actually doing the authentication is
prone to error.
> be to reverse lookup the connection IP and check that hostname
> against the host names in pg_hba.conf. We could also then check that
> the host name maps to the IP address.
There is, curiously, an existing Internet Draft currently in WGLC at
the dnsop working group at the IETF that warns explicitly against
using hostname forward and reverse matching checks as a security
mechanism, without having other options. So if the mechanism is going
to force matching forward and reverse data, then I urge whoever
implements this to make it possible to turn that matching check off,
because it won't work reliably. The draft is available from
<http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-reverse-mapping-considerations/>.
By the way, in the context of DNSSEC, a matching check might not add
anything, but a check for existing signed reverse data may. That is,
if you have authenticated forward zone data and you have authenticated
reverse zone data, you can be confident that you have the right
hostname even if the forward and reverse hostnames don't match.
A
--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/
