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

On Sun, 1 Jan 2006, Andreas Pflug wrote:

>>> While I haven't tried it, I suspect that allowing a DNS host name
>>> would take little work (basically removing the AI_NUMERICHOST flag
>>> passed to getaddrinfo in hba.c). There was once a good reason not
>>> to allow it: slow DNS lookups would lock up the postmaster. But
>>> now that we do this work in an already-forked backend, with an overall
>>> timeout that would catch any indefinite blockage, I don't see a good
>>> reason why we shouldn't let people use DNS names.
[snip]
>
> Routers/firewalls that allow DNS names will usually resolve them immediately,
> and store the IP addresses.

I think it's a great idea to make DNS names an option in pg_hba.conf.
However, I think we're talking about two fairly different features here.

(1) What Tom proposed is that we store the hostname and do a new DNS
lookup for every connection. That could be useful in certain situations,
but I wouldn't use it for a busy production server. The additional time
for DNS lookups (even with a fast local caching nameserver) would not be a
price I'd want to pay for the convenience. In a development environment,
it could be just the ticket, though.

(2) As Andreas mentioned, firewalls commonly do the DNS lookups when they
read their configuration, and store the IP addresses. If we did this,
you'd presumably only have to reload the postmaster configuration to cause
the DNS lookups to be done again, but until then they'd be static and as
fast as using actual IP addresses.

If both were implemented, I'm not sure how you'd indicate which method you
want on any given pg_hba.conf line.

If we were only to have one of these, I'd prefer (2). You could always set
up a cron job to reload the postmaster config hourly or daily, to keep the
DNS lookups from getting too stale.

Jon

--
Jon Jensen
End Point Corporation
http://www.endpoint.com/
Software development with Interchange, Perl, PostgreSQL, Apache, Linux, ...