Re: CIDR in pg_hba.conf
От | Larry Rosenman |
---|---|
Тема | Re: CIDR in pg_hba.conf |
Дата | |
Msg-id | 191700000.1052341861@lerlaptop.iadfw.net обсуждение исходный текст |
Ответ на | Re: CIDR in pg_hba.conf (Bruno Wolff III <bruno@wolff.to>) |
Ответы |
Re: CIDR in pg_hba.conf
(Bruno Wolff III <bruno@wolff.to>)
Re: CIDR in pg_hba.conf (Andrew Sullivan <andrew@libertyrms.info>) |
Список | pgsql-hackers |
--On Wednesday, May 07, 2003 15:07:15 -0500 Bruno Wolff III <bruno@wolff.to> wrote: > On Wed, May 07, 2003 at 15:12:42 -0400, > Andrew Dunstan <andrew@dunslane.net> wrote: >> My slightly cursory look at the relevant section of hba.c suggests that >> the resolution would done at connect time, not at file parse time - I'm >> sure someone will correct me if I'm wrong. >> >> I wasn't going to do reverse lookup - do you think we should? Basically I >> was going to match if a forward mapping of the DNS name matched the >> socket address. > > There isn't a reason to do reverse lookups in this case. It will just > make things harder to use (in the case where there are multiple A > records pointing to the same IP address) and won't add any useful > security. probably true, but, might still make things hard. I would still prefer to see a paranoid lookup: name->ip->name and make sure it's sane. (My abuse/security/paranoid hat). > >> The other issue is that doing an address lookup has the potential to add >> hugely to the time taken to establish connections - CNAMEs will make this >> worse, caching will make it better. Using reverse lookups would >> significantly increase this impact. > > Once your local DNS cache has the A records cached the slowdown should > be minimal. > >> Maybe we need to think a bit harder about this. Or at the very least put >> a prominent warning in the docs and sample files, just like Apache does >> in relation to the same issue for log files etc. > > Yes there should be something about possible delays in the docs as well > as mentioning that the domain to IP address translation happens at > connect time, not server start up. see my other comment on why I think it might make sense to do the lookup(s) at Parse Time. LER > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
В списке pgsql-hackers по дате отправления: