Обсуждение: Are dns CNAME's allowed or useable in pg_hba.conf hostname specification

From reading the doc’s it looks like a CNAME will not in general work as a hostname specification in pg_hba.conf.  Is
thata correct interpretation of the the documentation? 

From the doc’s (https://www.postgresql.org/docs/current/static/auth-pg-hba-conf.html

If a host name is specified (anything that is not an IP address range or a special key word is treated as a host name),
thatname is compared with the result of a reverse name resolution of the client's IP address (e.g., reverse DNS lookup,
ifDNS is used). Host name comparisons are case insensitive. If there is a match, then a forward name resolution (e.g.,
forwardDNS lookup) is performed on the host name to check whether any of the addresses it resolves to are equal to the
client'sIP address. If both directions match, then the entry is considered to match. (The host name that is used in
pg_hba.confshould be the one that address-to-name resolution of the client's IP address returns, otherwise the line
won'tbe matched. Some host name databases allow associating an IP address with multiple host names, but the operating
systemwill only return one host name when asked to resolve an IP address.) 

"dennisr@visi.com" <dennisr@visi.com> writes:
> Thanks for the quick reply.  Here’s some details on how we have things configured.
> We are using RHEL 7.3,  the DNS names below have been changed to protect the innocent or not so innocent depending on
yourpoint of view. 

> If I do a nslookup on the database host against the following CNAME some-cname-host.example.com
<http://some-cname-host.example.com/>I get: 

>     $> nslookup  some-cname-host.example.com <http://some-cname-host.example.com/>
>     Server:             10.97.40.215
>     Address:          10.97.40.215#53

>     some-cname-host.example.com         canonical name = canonical-host-name.example.com.
>     Name: canonical-host-name.example.com
>     Address: 10.65.160.213

> When I do the reverse lookup on the IP address return above I get the following:

>     $> nslookup 10.65.160.213
>     Server:             10.97.40.215
>     Address:          10.97.40.215#53

>     213.160.65.10.in-addr.arpa    name = canonical-host-name.example.com.

Given that, what you would have to put in pg_hba.conf is
canonical-host-name.example.com (and that needs to forward-resolve to
10.65.160.213, and possibly other addresses as well).  This cross-check
is meant to prevent getting into a PG server by means of a faked
reverse-DNS entry.

(If you're wondering why we don't simply accept anything that
some-cname-host.example.com forward-maps to, it's for performance reasons:
that would require resolving every DNS name in pg_hba.conf to see if it
matches, which could be pretty awful with long pg_hba.conf files.)

            regards, tom lane

> On Dec 5, 2016, at 5:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> "dennisr@visi.com" <dennisr@visi.com> writes:
>> Thanks for the quick reply.  Here’s some details on how we have things configured.
>> We are using RHEL 7.3,  the DNS names below have been changed to protect the innocent or not so innocent depending
onyour point of view. 
>
>> If I do a nslookup on the database host against the following CNAME some-cname-host.example.com
<http://some-cname-host.example.com/>I get: 
>
>>     $> nslookup  some-cname-host.example.com <http://some-cname-host.example.com/>
>>     Server:             10.97.40.215
>>     Address:          10.97.40.215#53
>
>>     some-cname-host.example.com         canonical name = canonical-host-name.example.com.
>>     Name: canonical-host-name.example.com
>>     Address: 10.65.160.213
>
>> When I do the reverse lookup on the IP address return above I get the following:
>
>>     $> nslookup 10.65.160.213
>>     Server:             10.97.40.215
>>     Address:          10.97.40.215#53
>
>>     213.160.65.10.in-addr.arpa    name = canonical-host-name.example.com.
>
> Given that, what you would have to put in pg_hba.conf is
> canonical-host-name.example.com (and that needs to forward-resolve to
> 10.65.160.213, and possibly other addresses as well).  This cross-check
> is meant to prevent getting into a PG server by means of a faked
> reverse-DNS entry.
>
> (If you're wondering why we don't simply accept anything that
> some-cname-host.example.com forward-maps to, it's for performance reasons:
> that would require resolving every DNS name in pg_hba.conf to see if it
> matches, which could be pretty awful with long pg_hba.conf files.)
>
>             regards, tom lane
>

OK thanks, sadly not the answer I was hoping for though.

My preference is to use a network address for this stuff but I was over ruled and needed to use a host specific name or
addressin the config file. I wanted to use a CNAME in place of the A or PTR records so as in the event we ever have to
rebuilda new WAL receiver, I would only need to repoint the CNAME in the DNS system and avoid the possibility of
updatinga few hundred pg_hba.conf’s with a new IP address or hostname (this is a private cloud environment I am working
withso I don’t have a lot of control over hostnames of the nodes they give me or even the networks the node is placed
in.)

Dennis

On 12/5/16 7:09 PM, dennisr@visi.com wrote:
> My preference is to use a network address for this stuff but I was over ruled and needed to use a host specific name
oraddress in the config file. I wanted to use a CNAME in place of the A or PTR records so as in the event we ever have
torebuild a new WAL receiver, I would only need to repoint the CNAME in the DNS system and avoid the possibility of
updatinga few hundred pg_hba.conf’s with a new IP address or hostname (this is a private cloud environment I am working
withso I don’t have a lot of control over hostnames of the nodes they give me or even the networks the node is placed
in.)

Note that the IP addresses in pg_hba.conf are not really by themselves a
primary security measure, because the source IP addresses in the same
network are (potentially) under control of the source host.  Their
purpose is rather to allow different classes of hosts to use different
authentication mechanisms.  For example, newer hosts might use SSL,
older hosts passwords.

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services