Re: pg_hba.conf hostname todo

>>> Host name lookup could occur when the postmaster reads the pg_hba.conf
>>> file, or when the backend starts. Another solution would 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.
>> I'm inclined towards doing the reverse-DNS of the connecting IP and then
>> checking that the forward of that matches.
>
> Hmm what if it doesn't? Which is the case any many scenario. My thoughts
> are:
>
> If www.commandprompt.com is allowed, then the ip address 207.173.200.129
> is allowed to connect.
>
> If we go the reverse way:
>
> 129.200.173.207.in-addr.arpa name = 129.commandprompt.com.
>
> Which really isn't that useful imo.

Just make absolutely sure you don't trust the *reverse* without
double-checking the forward.

Trusting the forward without double-checking the reverse seems
reasonable. Though in a situation like yours, I'd personally recommend
either putting "129.commandprompt.com" in the pg_hba.conf, or better yet
change the reverse to actually be meaningful ;-)

>>> Allow one to specify a FQDN or a simple wild card DN. E.g;
>>> *.commandprompt.com.
>>>
>>> A valid entry would look like this:
>>>
>>> host all all *.commandprompt.com trust
>>> host all all www1.postgresql.org md5
>>>
>>> Thoughts?
>> While a wildcard does make sense (ie: www*.postgresql.org), I would
>> generally expect 'commandprompt.com' to mean '*.commandprompt.com'
>> implicitly.
>
> Hmm interesting. I wouldn't expect that. I might
> expect .commandprompt.com to mean *.commandprompt.com. But
> commandprompt.com I would expect only whatever the A record returns as
> commandprompt.com.
>
> One thing I don't want to do is create a bunch of different style
> syntaxes that are available :)

My vote is for specifically requiring "*.commandprompt.com" if you want
a wildcard. That leaves any guesswork out of it.

commandprompt.com should *definitly* not be "*.commandprompt.com" IMHO -
having A records on the domain is way too common these days. (And I
think it's a lot less frowned upon than it once used to be, given that
so many people use it now)

And to repeat the above - for wildcards you *must* do both reverse and
forward lookups on the connection. This makes it impossible/impractical
to parse it during pg_hba.conf load which is in the TODO item, but I
don't really see the point of that part anyway.

//Magnus