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

On Sun, 1 Jan 2006, Tom Lane wrote:

I was reminded of $subject by
http://archives.postgresql.org/pgsql-admin/2006-01/msg00002.php

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.

Thoughts?

Security?

Employee adds his DNS to pg_hba.conf, becomes disgruntled employee, moves
to different IP and same name, and can still access your database?

What about "DNS hijacking/forging"? I don't know how hard it is to do,
but if one of the upstream network provides puts in a 'filter' for port 53
(DNS) and starts feeding you incorrect data, so that they can access your
databases?

Both are relatively extreme, and in both bases, the 'attacker' would have
to have previous knowledge (ie. disgruntled ex employee) but DNS !=
trusted IP ... then again, it may be possible to hijack/forge the IP
itself, in which case, there is no difference ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

On Sun, Jan 01, 2006 at 02:50:37PM -0400, Marc G. Fournier wrote:

Employee adds his DNS to pg_hba.conf, becomes disgruntled employee, moves
to different IP and same name, and can still access your database?

I think it depends how you do the check. You can either do a forward
lookup from the name and match that to the IP. Or you can do a reverse
lookup on the IP to match the name. Or both.

To work around either requires hijacking DNS but which servers varies.
If you've got the entries in /etc/hosts that makes hijacking harder.

I'm thinking something like tcpwrappers would be an example here. They
have a paranoid mode where your reverse and forward have to match.
Something to consider.

For the user in referred to thread: SSH tunnelling. I wonder if there's
a way we can make that easier to setup...

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Marc G. Fournier wrote:

On Sun, 1 Jan 2006, Tom Lane wrote:

I was reminded of $subject by
http://archives.postgresql.org/pgsql-admin/2006-01/msg00002.php

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.

Thoughts?

Security?

I'd bet most pg_hba.conf entries will be (private) networks, not hosts.
Since private networks defined in DNS are probably quite rare, only few
people could benefit.

Those who *do* define specific host entries, are probably quite security
aware. They might find DNS safe for their purposes, but they'd probably
like a function that shows the resulting hba entries after DNS resolution.

Routers/firewalls that allow DNS names will usually resolve them
immediately, and store the IP addresses.

Regards,
Andreas

"Marc G. Fournier" <scrappy@postgresql.org> writes:

On Sun, 1 Jan 2006, Tom Lane wrote:

... I don't see a good
reason why we shouldn't let people use DNS names.

Security?

Possibly, but if you're worried about that sort of attack you just don't
use DNS names in pg_hba.conf. Certainly it'd be worth putting a warning
in the manual about the risks of referring to DNS servers that aren't
directly under your control. But that doesn't seem like a reason not to
provide the feature for those who want it.

regards, tom lane

On Jan 1, 2006, at 2:02 PM, Martijn van Oosterhout wrote:

For the user in referred to thread: SSH tunnelling. I wonder if
there's
a way we can make that easier to setup...

Making this easier and transparent would be nice, but I would still
vote to allow DNS names in pg_hba.conf.

SSH tunneling implies another level of software, user accounts, and
permissions. It would be nice to handle the entire sphere of users
and permissions from within PostgreSQL. For database access
requirements, I would much rather allow DNS names in pg_hba.conf than
provide SSH access.

John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL

Am Sonntag, 1. Januar 2006 19:30 schrieb Tom Lane:

I don't see a good
reason why we shouldn't let people use DNS names.

I generally support this, but I wonder if this could have strange effects if a
name resolves to more than one IP address or even an IPv4 and an IPv6
address.

Peter Eisentraut <peter_e@gmx.net> writes:

Am Sonntag, 1. Januar 2006 19:30 schrieb Tom Lane:

I don't see a good
reason why we shouldn't let people use DNS names.

I generally support this, but I wonder if this could have strange
effects if a name resolves to more than one IP address or even an IPv4
and an IPv6 address.

That's a good point: we'd have to be prepared to match the actual remote
IP address to more than one return value from getaddrinfo, so the change
wouldn't be a one-liner after all. It still seems like a pretty
localized change though.

regards, tom lane

Tom Lane wrote:

I was reminded of $subject by
http://archives.postgresql.org/pgsql-admin/2006-01/msg00002.php

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.

Thoughts?

We debated this back in May 2003 - I was going to do it but it got lost
among other stuff. Still worth doing, I think.

cheers

andrew

I also support this change. My clients have tended to move
machines and networks around a lot as well as move databases from machine
to machine. It would be nice to let the network gurus concentrate
on getting the dns servers up and correct and leverage that
work instead of having to change pg_hba.conf when these changes
occur.

elein
elein@varlena.com

Yes, it would be good to implement this. A warning about security and
(possible) slow connections due to name resolution issues should be placed in
the docs.
Regards

paolo

elein <elein@varlena.com> ha scritto

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

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

Jon Jensen <jon@endpoint.com> writes:

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

Can you demonstrate that this is actually a serious concern next to the
total time spent launching a backend? I can't measure any real change
in total time for "psql -l" when log_hostname is enabled, which should
be a comparable hit.

I started out proposing a one-line change. The odds of this ever
getting done drop by an order of magnitude every time someone proposes
another order-of-magnitude increase in the work required...

regards, tom lane

On Mon, 2 Jan 2006, Tom Lane wrote:

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

Can you demonstrate that this is actually a serious concern next to the
total time spent launching a backend? I can't measure any real change
in total time for "psql -l" when log_hostname is enabled, which should
be a comparable hit.

The difference is negligible when using a UNIX socket (of course) or names
listed in /etc/hosts. But it's certainly slower in my tests if you really
use DNS. On a run of 1000 connections doing "psql -l", it takes 18.89s
without the DNS lookup for log_hostname, and 31.5s with. Or run as a
one-off, it's 0.032 to 0.041s. Enough to make a difference on a busy
server taking connections only over a local network.

However, if I consider the likely use cases, this feature probably isn't
important to such highly speed-sensitive servers anyway. And for those who
want every last bit of speed possible, /etc/hosts still allows them to use
this feature without a noticeable speed penalty. If the documentation
mentions that DNS lookups are done for every request if you choose to use
hostnames in pg_hba.conf, I think that's fair enough.

I started out proposing a one-line change. The odds of this ever
getting done drop by an order of magnitude every time someone proposes
another order-of-magnitude increase in the work required...

It sounds like it's beyond a one-line change anyway, due to the
possibility of multiple IP addresses coming back.

But I agree that complicating this simple feature is overkill. The
database is not a firewall, and doesn't have a firewall's speed due to
connection overhead anyway.

Jon

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

Jon Jensen <jon@endpoint.com> writes:

On Mon, 2 Jan 2006, Tom Lane wrote:

Can you demonstrate that this is actually a serious concern next to the
total time spent launching a backend? I can't measure any real change
in total time for "psql -l" when log_hostname is enabled, which should
be a comparable hit.

The difference is negligible when using a UNIX socket (of course) or names
listed in /etc/hosts. But it's certainly slower in my tests if you really
use DNS. On a run of 1000 connections doing "psql -l", it takes 18.89s
without the DNS lookup for log_hostname, and 31.5s with. Or run as a
one-off, it's 0.032 to 0.041s.

Um --- I was testing a local-loopback connection, but now that I look at
the nsswitch.conf setup, it was going to /etc/hosts for that case.
Coming across the network so that a real DNS lookup is forced, there
seems to be a difference of about 4ms (note this is with a local DNS
daemon). I don't think that's significant. If it is, you've got other
performance problems anyway, and should switch to pooled connections to
reduce the number of backend launches.

regards, tom lane

On Sun, Jan 01, 2006 at 09:03:00PM +0100, Andreas Pflug wrote:

Marc G. Fournier wrote:

On Sun, 1 Jan 2006, Tom Lane wrote:

I was reminded of $subject by
http://archives.postgresql.org/pgsql-admin/2006-01/msg00002.php

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.

Thoughts?

Security?

I'd bet most pg_hba.conf entries will be (private) networks, not hosts.
Since private networks defined in DNS are probably quite rare, only few
people could benefit.

Those who *do* define specific host entries, are probably quite security
aware. They might find DNS safe for their purposes, but they'd probably
like a function that shows the resulting hba entries after DNS resolution.

I don't know if the normal DNS libraries allow this, but it would be
cool if you could specify that an entry in pg_hba.conf could be looked
up from /etc/hosts, but not from generic DNS. AFAIK that would eliminate
the possibility of spoofing.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

--- "Jim C. Nasby" <jnasby@pervasive.com> escreveu:

I don't know if the normal DNS libraries allow this, but it would be
cool if you could specify that an entry in pg_hba.conf could be
looked
up from /etc/hosts, but not from generic DNS. AFAIK that would
eliminate
the possibility of spoofing.

Take a look at 'man /etc/host.conf'.

Euler Taveira de Oliveira
euler[at]yahoo_com_br

_______________________________________________________
Yahoo! doce lar. Fa�a do Yahoo! sua homepage.
http://br.yahoo.com/homepageset.html

Euler Taveira de Oliveira wrote:

--- "Jim C. Nasby" <jnasby@pervasive.com> escreveu:

I don't know if the normal DNS libraries allow this, but it would be
cool if you could specify that an entry in pg_hba.conf could be
looked
up from /etc/hosts, but not from generic DNS. AFAIK that would
eliminate
the possibility of spoofing.

Take a look at 'man /etc/host.conf'.

That won't work for per application settings. I think this is a non starter.

I have been thinking more about possible real world use cases for this
facility. I suspect they will be comparatively rare. In cases where you
don't trust DNS you shouldn't use it, and in cases where you do you
probably know the address(es) anyway. If the change is simple it's worth
doing, but it's not a huge leap. The biggest wrinkle will probably be
handling names that map to multiple addresses.

One thing that bothers me slightly is that we would need to look up each
name (at least until we found a match) for each connection. If you had
lots of names in your pg_hba.conf that could be quite a hit. We need to
test this not with one but with a couple of hundred names, maybe, to see
what the hit is like.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

One thing that bothers me slightly is that we would need to look up each
name (at least until we found a match) for each connection. If you had
lots of names in your pg_hba.conf that could be quite a hit.

A possible answer to that is to *not* look up the names from
pg_hba.conf, but instead restrict the feature to matching the
reverse-DNS name of the client. This limits the cost to one lookup per
connection instead of N (and it'd be essentially free if you have
log_hostnames turned on, since we already do that lookup in that case).

I'm not sure about the relative usefulness of this compared to the
forward-lookup case, nor whether it's riskier or less risky from a
spoofing point of view. But something to consider.

regards, tom lane