Re: Resolving host to IP address

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Sebastien Flaesch <sebastien(dot)flaesch(at)4js(dot)com>
Cc: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Resolving host to IP address
Date: 2022-09-12 14:11:11
Message-ID: 1611957.1662991871@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Sebastien Flaesch <sebastien(dot)flaesch(at)4js(dot)com> writes:
> $ psql 'postgresql://toro.strasbourg.4js.com:5437/test1?user=pgsuser&sslmode=verify-ca&sslrootcert=./root.crt&sslcert=./client.crt&sslkey=./client.key'
> psql: error: connection to server at "toro.strasbourg.4js.com" (127.0.1.1), port 5437 failed: FATAL: no pg_hba.conf entry for host "127.0.0.1", user "pgsuser", database "test1", SSL encryption

> What looks strange to me in this error is that first it mentions 127.0.1.1 (ok) but then, 127.0.0.1

Linux doesn't seem to show its routing of the loopback domain in netstat
output, but it's probably much like what macOS shows explicitly:

$ netstat -r -n
Destination Gateway Flags Netif Expire
...
127 127.0.0.1 UCS lo0
127.0.0.1 127.0.0.1 UH lo0
...

That is, the entire 127/8 range is "routed" through 127.0.0.1 and
will look like that to the server. I see similar entries on NetBSD.

Confirming that guess, I see this behavior on RHEL8,
with no particular OpenSSL involvement:

$ psql -h 127.0.1.1
psql (16devel)
Type "help" for help.

postgres=# select client_addr from pg_stat_activity;
client_addr
-------------
...
127.0.0.1
...

Moral: don't try to use addresses in that range as real addresses.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Francisco Olarte 2022-09-12 14:12:18 Re: Resolving host to IP address
Previous Message Tom Lane 2022-09-12 13:47:51 Re: lippq client library and openssl initialization: PQinitOpenSSL()