Re: CIDR in pg_hba.conf

On Fri, May 09, 2003 at 13:40:18 +0900, Curt Sampson <cjs@cynic.net> wrote:
> On Thu, 8 May 2003, Bruno Wolff III wrote:
> 
> > On Fri, May 09, 2003 at 00:59:58 +0200,
> >   Kurt Roeckx <Q@ping.be> wrote:
> > >
> > > There are.  You can even make an authoritative nameserver return
> > > a wrong answer.
> >
> > This is incorrect.
> 
> Actually, you can quite easily make an authoratative nameserver return
> an incorrect answer through cache poisoning, if the particular software
> and version happens to have that bug and recursive searches are turned on.
> 
> However, it's also possible to set up nameservers securely, so you
> shouldn't use this an an excuse never to use hostnames.

I disaggree that it is easy to make an authoritative server return poison.
Even the BIND people are now recommending separating authoritative and
caching servers. Even if the two were combined a correctly programmed
cache can't be poisoned because it shouldn't trust glue from a server
that isn't authoritative for the name server domain it is providing
glue for. I don't know whether or not BIND still does this (trust glue
unconditionally), but the cache I use doesn't.

> > Efficiency. If there are a number of domain name entries you may only
> > want to check them when reading hba.conf. This does break some useful
> > things about using domain names in hba.conf.
> 
> Personally, I think the best way to deal with the issue is, if the
> connecting IP address is not found in hba.conf, do an in-addr.arpa
> lookup on the IP address and see if you get a hostname. If you do, check
> the hba.conf for that hostname. If the hba.conf has the hostname, then
> you do a forward lookup on it and make sure that there's an A record
> matching that IP address.
> 
> Yes, it can slow things down significantly. But you can still always
> just hardwire the IP addresses in hba.conf if you want to avoid the
> slowdown and the addresses don't change often. However, if the addresses
> do change often, this gives you the option of having the server follow
> the changes automatically, at the price of a slowdown in connecting.

I don't think the slow down is a big deal. It is just two dns lookups
instead of one. The problem is that it limits you to only be able to
use the domain in the PTR record when there may be other forward
domains that would be preferred. However I don't think doing just forward
lookups at connect time scales.