Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: mark(at)mark(dot)mielke(dot)cc
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Euler Taveira de Oliveira <eulerto(at)yahoo(dot)com(dot)br>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why don't we allow DNS names in pg_hba.conf?
Date: 2006-01-03 18:21:52
Message-ID: 18463.1136312512@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
mark(at)mark(dot)mielke(dot)cc writes:
> On Tue, Jan 03, 2006 at 12:43:03PM -0500, Tom Lane wrote:
>> 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.

> I think it's riskier. I have my own PTR records, that I can make be
> whatever I wish without any authority verifying that my actions are
> proper.

Yeah, that occurred to me after a few moments' thought.  We could do one
extra forward lookup to confirm that the reverse-lookup name maps back
to the IP address.

> It's not a big deal.

Depends on how many names you want to put into pg_hba.conf.  I don't
offhand see a use-case for very many, but maybe there is one.  Even
if there are a lot, they'd not be expensive to look up if there is
a local nameserver that is authoritative for those names ... which
I'd think would be the normal case.  The more "outside" names you've
got in pg_hba.conf, the more open you are to spoofing.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Stephen FrostDate: 2006-01-03 18:30:56
Subject: Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and
Previous:From: Tino WildenhainDate: 2006-01-03 18:21:33
Subject: Re: Why don't we allow DNS names in pg_hba.conf?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group