On 1/2/06, Jon Jensen <jon@endpoint.com> wrote:
> 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.
IMHO, this is the price you pay for using DNS.
>
> (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.
If we're going to use an external facility, I'd vote for using it as a
black box via the API it was designed with and not doing any caching
tricks, especially if those tricks involve reloading the config file
to make changes visible that would be seen if the facility were used
"correctly". I guess I just see it as a "correct vs. fast" decision.
If caching were to be used, expiry should be based on the TTL for the
DNS record, and not a reload of our config.
.... just my $0.02.
>
> Jon
>
> --
> Jon Jensen
> End Point Corporation
> http://www.endpoint.com/
> Software development with Interchange, Perl, PostgreSQL, Apache, Linux, ...
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
--
Mike Rylander
mrylander@gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org