Re: Why don't we allow DNS names in pg_hba.conf?

Mark Woodward wrote:

>>Added to TODO:
>>
>> o Allow pg_hba.conf to specify host names along with IP addresses
>>
>> 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 not so sure you need to be paranoid about it. The scenario is, at
>startup or HUP, names are looked up and stored as IP addresses. Then hba
>works as it is supposed too.
>
>

If you do it like that you destroy the only real use case I can see for
this that has much value, namely to handle cases where the address can
change dynamically.

>"spoofing" is not really a problem, IMHO, because there should be a fire
>wall between PostgreSQL (most services really) and the raw internet, *and*
>the admin MUST have control over the authenticity of the name resolver. If
>someone is in the position to spoof name resolution, they are probably
>also in a position to spoof IP addresses.
>
>While I do see a need for this, but not in a sense that any old name would
>be used. I see it more like a data center wide "hosts" file use to
>dedicate various IP addresses to various services, i.e. freedb, streetmap,
>session, web0, web1, .., webn etc.
>
>What also may be handy in this scenario is that the names must fall within
>a range of acceptable addresses.
>
>Range: 192.168.245.1 ... 192.168.254.254
>
>joey (192.168.254.55) -- OK
>
>joey (10.1.1.0) -- Not OK.
>
>This would be useful to declare a range of addresses as having some level
>of trust, and specific names within that range as having more (or less).
>
>In this scenario, think of a VPN, "joey" may be a laptop, and while he is
>on the VPN he is trusted, and when he is not on the vpn he is not trusted.
>This is especially important with regards to cyber security.
>
>
>

We have address ranges now; are you proposing to have those IN ADDITION
to hostname parameters (as opposed to being an alternative)?

We can over-egg this pudding massively. I suggest we start with a simple
implementation and see what needs it leaves unfilled. I would vote for
allowing a hostname (or list of hostnames?) to replace the address/mask
params, and that at connect time we do a forward lookup trying for a
match with the connecting address. If we get a match then that's the hba
line that applies.

Frankly, any auth mechanism based on the name or address of the client
is insecure. If you have people connecting across possibly insecure
networks you should use SSL with client certificates signed by your own
CA, or a similar approach.

cheers

andrew