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.

How "dynamically" are you talking about?

If you are using a DNS server, what is your TTL on the records? A simple
-HUP once every half hour is more than sufficient. If you are using ssh to
update the hosts file, adding a simple -HUP tp the script is not a big
deal.

>
>>"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.

It isn't so much an auth issue because I'm not assuming a "hacker" so much
as the stream of data that across the network. Within the firewall ==
safe, outside of the firewall can be snooped.