On 15th of October Peter Eisentraut committed patch (his own) which adds:
Support host names in pg_hba.conf Peter Eisentraut, reviewed by KaiGai Kohei and Tom Lane
As you perhaps know, pg_hba.conf contains lines like these:
host all all 127.0.0.1/32 trust
Which means that any connection coming over TCP/ip, from localhost, to any database, using any username, should be trusted, and doesn't need to provide password – this is of course just an example.
Now, with this new patch of Peter, instead of using IPs for hosts, we can use hostnames, like this:
host all all krowka.home.depesz.com trust
Couple of notes though:
- you have to use full hostnames, including domain
- failure of dns will mean that you cannot connect to database
Personally I think that using it is too dangerous (in terms: too easy to break it so it will cease to work) to be really useful. But that's because I have to use lots of VPNs, and they tend to force set their own DNS servers, which not always resolve all names in sensible way.
But if you are 100% sure of your dns servers, it might make it a bit easier to read than IP based version of the file.
A small correction; 127.0.0.1/32 means all TCP/IP connections originating *only* from localhost.
Perhaps you meant 0.0.0.0/0.
@Gurjeet:
thanks, fixed.
Would not a hosts file of critical boxes serve in the event of a DNS failure? Assuming the IP of the destination box wasn’t being spoofed or subject to a MIM attack.
@Loef:
it probably could, but it brings to the table problems of updates and file distribution. Granted – it’s solvable, but I just can’t think of any real reason to use it.
too bad this patch supports FQDN only.
Would just be too easy to move pg_hba.conf from test to live without touching (yes, we have same hostnames in test/live)
I’m planning to add wildcard support (details TBD), which will address more scenarios better.