On Fri, 9 May 2003, Tom Lane wrote:
> Bruno Wolff III <bruno@wolff.to> writes:
> > .... However I don't think doing just forward
> > lookups at connect time scales.
>
> Is it necessary that it scale? AFAICS, putting DNS names in pg_hba.conf
> would be a convenience feature for low-volume databases. People who are
> trying to service lots of connections would put numbers in there anyway
> for performance reasons. I'd prefer to go for simplicity here, and just
> do the lookups on demand.
>
> I think most of the objections that have been raised in this thread are
> not very applicable to real-world uses. The hosts you are going to be
> granting database access to are usually nearby ones, and the DNS server
> you are going to be consulting is not only nearby but authoritative for
> those names. So I think both the speed and security issues are being
> overstated. Indeed we should mention them prominently in the docs, but
> we should not overengineer the implementation.
Agreed. I think there are two ways this type of entry might be used, one
is in an area where IPs rarely change, but the sysadmin would prefer to
have names in the pg_hba.conf anyway, so that on the rare occasion when
they do, he can just restart the database if necessary, so looking them up
at startup only is fine.
the other possibility is for folks running in a DHCP environment, like say
a corporate intranet. For those folks, it might well be that IPs could
change every hour/day/week/month, and requiring the server to be "bumped"
to see the new name -> IP resolution would be suboptimal.
So, if the performance to perform a lookup on each connect isn't too big,
I would lean towards that, since it works for both of the above scenarios.