Re: host name support in pg_hba.conf

Peter Eisentraut wrote:
> On mån, 2010-08-09 at 13:56 -0500, Kevin Grittner wrote:
>> Peter Eisentraut wrote:

>>> is reverse looked up, which results in a host name.
>>
>> Some IP addresses have several host names, including in reverse
>> lookup; how is that handled?
>
> This is not possible,

http://en.wikipedia.org/wiki/Reverse_DNS_lookup#Multiple_pointer_records

> or at least the C library APIs don't expose it.

That may explain the prevalence of bugs in code dealing with it.

-Kevin

On tis, 2010-08-10 at 07:32 -0500, Kevin Grittner wrote:
> http://en.wikipedia.org/wiki/Reverse_DNS_lookup#Multiple_pointer_records

Yeah, you can configure all kinds of nonsense and sometimes even get
away with it, but the basic assumption throughout is that a system has
one host name and between 1 and many IP addresses. We must make our
implementation robust again other setups, but we don't have to (or
rather cannot) support them.

On Tue, Aug 10, 2010 at 10:05 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On tis, 2010-08-10 at 07:32 -0500, Kevin Grittner wrote:
>> http://en.wikipedia.org/wiki/Reverse_DNS_lookup#Multiple_pointer_records
>
> Yeah, you can configure all kinds of nonsense and sometimes even get
> away with it, but the basic assumption throughout is that a system has
> one host name and between 1 and many IP addresses.

These days, I think it's more common the other way around: one IP
address, and many host names.

> We must make our
> implementation robust again other setups, but we don't have to (or
> rather cannot) support them.

"Cannot" is a good argument for not supporting just about anything.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:

> Yeah, you can configure all kinds of nonsense and sometimes even
> get away with it, but the basic assumption throughout is that a
> system has one host name and between 1 and many IP addresses.

It's hardly nonsense to have multiple names on a machine. While we
usually avoid having multiple reverse lookup names, we have many
in-house web applications and we neither want users to access them
by IP address or have to worry about which web server is hosting
which applications at the moment. So it's not unusual for one of
our web servers to have 10 or 15 DNS names for forward lookup. If
one machine becomes overloaded, we can move an application, change
the DNS, and everyone's bookmark still works. This is precisely the
sort of situation where using a hostname in pg_hba.conf would be
most useful.

> We must make our implementation robust again other setups, but we
> don't have to (or rather cannot) support them.

Without the logic to ensure that the hostname matches the reverse
lookup, this might be useful for us. With that logic it is useless
for us. I'm wondering how much you gain by having it in there. Why
can't a forward lookup which matches the requesting IP be considered
sufficient?

-Kevin

On tis, 2010-08-10 at 10:11 -0400, Robert Haas wrote:
> These days, I think it's more common the other way around: one IP
> address, and many host names.

Yes, that setup is very common, but it's actually only an illusion that
DNS creates. The actual machine still has only one host name and some
IP addresses, as far as the kernel is concerned. As you are surely
aware, this situation creates all kinds of problems in practice.

On tis, 2010-08-10 at 09:18 -0500, Kevin Grittner wrote:
> Without the logic to ensure that the hostname matches the reverse
> lookup, this might be useful for us. With that logic it is useless
> for us. I'm wondering how much you gain by having it in there. Why
> can't a forward lookup which matches the requesting IP be considered
> sufficient?

For one thing, because people might like to add wildcard support. So I
might be able to say

host all all appserver*.example.com md5

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Without the logic to ensure that the hostname matches the reverse
> lookup, this might be useful for us. With that logic it is useless
> for us. I'm wondering how much you gain by having it in there. Why
> can't a forward lookup which matches the requesting IP be considered
> sufficient?

I was about to complain about that same thing. ISTM the logic ought
to be that you do a forward DNS lookup on the name presented in
pg_hba.conf, and if any of the returned IP addresses match the
connection's remote IP address, then you have a match. This business
with doing a reverse lookup is at least twice as expensive, far more
fragile, and it seems completely bogus from a security viewpoint.
Why should I trust the RDNS server for an attacker's IP address?

regards, tom lane

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [100810 10:39]:

> I was about to complain about that same thing. ISTM the logic ought
> to be that you do a forward DNS lookup on the name presented in
> pg_hba.conf, and if any of the returned IP addresses match the
> connection's remote IP address, then you have a match. This business
> with doing a reverse lookup is at least twice as expensive, far more
> fragile, and it seems completely bogus from a security viewpoint.
> Why should I trust the RDNS server for an attacker's IP address?

Well, you don't trust the RDNS of the IP, you trust the normal lookup of
the hostname returned by the RDNS. So if some other ip network is
trying to give hostnames that should be authorized, you see that
immediately when you resolve the "authorized" hostname and it doesn't
give you that IP.

The PTR query is a means to get the "hostname" to check against, so you
d'nt have to pre-cache all thos possible results of all the hostnames.
Pre-caching all the hostnames in pg_hba.conf is madness. How long do
you cache them for? or do send out 1000 queries every connection? You
can't support wildcards, or anythign usefull...

AFAIK, every software I've used which allows hostnames as some
connection control all do PTR->A/AAAA lookups as Peter proposed.

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

On tis, 2010-08-10 at 10:39 -0400, Tom Lane wrote:
> I was about to complain about that same thing. ISTM the logic ought
> to be that you do a forward DNS lookup on the name presented in
> pg_hba.conf, and if any of the returned IP addresses match the
> connection's remote IP address, then you have a match. This business
> with doing a reverse lookup is at least twice as expensive, far more
> fragile, and it seems completely bogus from a security viewpoint.

If you have hundreds on lines in pg_hba.conf, then you need to do
hundreds of DNS lookups per connection attempt (*), and each of those
lookups could result in even more IP addresses, or could time out. So
if some unrelated part of the system breaks (DNS down), it could take
you hours to establish a connection. On the other hand, with the
reverse DNS lookup, you would normally do about two DNS queries per
successful connection attempt, and those would only be in relation to
the machines actually involved in the connection. Also, if you are in a
names-only environment, you might also like to turn on log_hostnames, in
which case the reverse lookup is free (well, shared).

(*) That could of course be addressed by your earlier idea of caching
the resolved names when pg_hba.conf is read, but I don't think many
people were on board with that idea.

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On tis, 2010-08-10 at 09:18 -0500, Kevin Grittner wrote:
>> Why can't a forward lookup which matches the requesting IP be considered
>> sufficient?

> For one thing, because people might like to add wildcard support. So I
> might be able to say
> host all all appserver*.example.com md5

I don't think that the possibility that we might support that in future
can justify using a slow and not-too-reliable method for ordinary
non-wildcard names.

regards, tom lane

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On tis, 2010-08-10 at 10:39 -0400, Tom Lane wrote:
>> I was about to complain about that same thing. ISTM the logic ought
>> to be that you do a forward DNS lookup on the name presented in
>> pg_hba.conf, and if any of the returned IP addresses match the
>> connection's remote IP address, then you have a match. This business
>> with doing a reverse lookup is at least twice as expensive, far more
>> fragile, and it seems completely bogus from a security viewpoint.

> If you have hundreds on lines in pg_hba.conf, then you need to do
> hundreds of DNS lookups per connection attempt (*), and each of those
> lookups could result in even more IP addresses, or could time out.

If you have a configuration that would actually require that, then you
would have a case for using a wildcard. My complaint is that you're
trying to force everyone to pay for that feature whether it's of use to
them or not. I think it's at least as likely that typical setups would
need exactly *one*, non wildcard, entry, to wit appserver.mycompany.com
(which'd necessarily yield IPs for all the machines running your app
server code).

regards, tom lane

* Aidan Van Dyk (aidan(at)highrise(dot)ca) wrote:
> The PTR query is a means to get the "hostname" to check against, so you
> d'nt have to pre-cache all thos possible results of all the hostnames.
> Pre-caching all the hostnames in pg_hba.conf is madness. How long do
> you cache them for? or do send out 1000 queries every connection? You
> can't support wildcards, or anythign usefull...
>
> AFAIK, every software I've used which allows hostnames as some
> connection control all do PTR->A/AAAA lookups as Peter proposed.

Completely agreed. It's madness to precache all thse hostnames, but we
need to figure out the hostname, thus, rDNS is used. The forward lookup
is then to double-check that it matches. This is exactly how Kerberos
works also. You certainly don't want to be repeatedly doing rDNS
lookups to see if maybe that IP has other hosts. I also don't buy that
there's an issue with setting up your rDNS to go to what you put in the
pg_hba and then having the forward of that include the IP; again, it's
how Kerberos works, and even if you don't believe in Kerberos, I hope
you realize it's kind of popular.

Thanks,

Stephen

* Kevin Grittner (Kevin(dot)Grittner(at)wicourts(dot)gov) wrote:
> It's hardly nonsense to have multiple names on a machine. While we
> usually avoid having multiple reverse lookup names, we have many
> in-house web applications and we neither want users to access them
> by IP address or have to worry about which web server is hosting
> which applications at the moment. So it's not unusual for one of
> our web servers to have 10 or 15 DNS names for forward lookup. If
> one machine becomes overloaded, we can move an application, change
> the DNS, and everyone's bookmark still works. This is precisely the
> sort of situation where using a hostname in pg_hba.conf would be
> most useful.

We're talking about client systems connecting to PG here. Are you
authenticating your web users by looking at their client addresses..?
That strikes me as pretty unlikely. Your web servers will be connecting
to your PG server from *one* address (whatever the main one is for that
pariticular server), and that address just needs to have an rDNS entry
that goes to a host whose forward DNS includes that IP.

If you have multiple web servers that are connecting to the same PG
database, then have multiple pg_hba entries, or make them all have the
same hostname per reverse DNS (though I don't really see why you'd want
to).

> > We must make our implementation robust again other setups, but we
> > don't have to (or rather cannot) support them.
>
> Without the logic to ensure that the hostname matches the reverse
> lookup, this might be useful for us. With that logic it is useless
> for us. I'm wondering how much you gain by having it in there. Why
> can't a forward lookup which matches the requesting IP be considered
> sufficient?

Because "you can't get there from here". You'd either have to cache all
the entries in pg_hba (which is horrible), or do a look-up on each one
on every connection (which is going to be a hell of alot slower than
doing one more DNS lookup here). This isn't magic. What we have is a
bunch of host names and a single IP (the connecting one). Figuring out
which one goes with which is the issue.

Stephen