Обсуждение: BUG #15655: local machines pushed openvpn dns issue

The following bug has been logged on the website:

Bug reference:      15655
Logged by:          Anthony Affee
Email address:      aaffee@follett.com
PostgreSQL version: 9.4.1
Operating system:   MacOS
Description:

Hi,

 The psql command line for MacOS looks to external DNS resolution first.
Once it fails, it then looks to the local machines DNS to resolve hostname.
My instance details for this report is among more than 20 people in my
company with the same if not identical setup as below.

MacOS: Any version but specifically latest release
OpenVPN Server: Latest server release
OpenVPN Client: Tunnelblick latest release
PostgreSQL Server: RedShift Latest release
RedShift Network: Internal/Private Only
Client DNS: Internal AWS DNS Primary server pushed in configuration to
override client

Error:

[anthony@Anthonys-Mini ~]$ psql
'postgresql://username:passwordhidden@redshifthidden.us-east-1.redshift.amazonaws.com:5439/dbname'
psql: could not connect to server: Operation timed out
    Is the server running on host
"redshifthidden.us-east-1.redshift.amazonaws.com" (34.206.57.41) and
accepting
    TCP/IP connections on port 5439?

After the first attempt to connect over the VPN is made, the above error is
given after it hangs for a while. As soon as the error is given and I
attempt to try again, the connection works nearly instantly. As you can see
above, the DNS is resolving the external IP address for this RedShift
instance. Since the local MacOS is pushed an internal DNS resolver, this
clearly is not using the local computers DNS, rather it appears to be using
a hard coded DNS from psql. We use many different apps and technologies and
RedShift with psql is the only DNS issue presented. We need psql to look for
the local machines DNS. Once it connects successfully, MacOS caches this DNS
and it will work for a while without an issue. NSLookup command even works
on the first attempt and displays the correct internal DNS IP for
RedShift.

Here is what the second and successful attempt looks like:

[anthony@Anthonys-Mini ~]$ psql
'postgresql://username:passwordhidden@redshifthidden.us-east-1.redshift.amazonaws.com:5439/dbname'
psql (9.4.1, server 8.0.2)
SSL connection (protocol: TLSv1, cipher: DHE-RSA-AES256-SHA, bits: 256,
compression: off)
Type "help" for help.

dbname=#

Can you help us resolve this? This is a big compatibility issue for
environments that rely on OpenVPN to connect to Cloud technologies.

PG Bug reporting form <noreply@postgresql.org> writes:
> The psql command line for MacOS looks to external DNS resolution first.
> Once it fails, it then looks to the local machines DNS to resolve hostname.

Neither psql nor libpq (or indeed anything in PG) contain their own
DNS resolution code.  It's just using whatever behavior the local libc
provides for that.

Apple's libraries do indeed have some nonstandard DNS resolution behavior,
though.  Some quick poking around here suggests that "scutil --dns" might
help you investigate how that's configured on your machine.

Also worth noting is that the PG community at large has no idea what AWS
may have done to versions that they provide; if this isn't a purely
stock psql, you should probably be asking AWS about it.

            regards, tom lane

"Affee, Anthony" <aaffee@follett.com> writes:
> Thank you for the quick reply. Running that command while on the VPN shows the correct output. This is indeed a weird
issue.I guess this in the end would be an OS/libc issue since I am not using anything from AWS locally. That is why I
skippedthe PG Client software and just used the command line to see if that would resolve the issue, but if you are
sayingits determined by the libc used on MacOS, then that has to be the only thing left in the chain. Do you happen to
knowhow I could open a bug report for the correct one MacOS has that PG is using? 

Hm ... lots of people use PG on Macs, and I don't recall hearing similar
complaints before.  So I'm still inclined to think this is mostly an AWS
issue; maybe their DNS server isn't acting as Apple expects?

You could try filing a gripe at

https://developer.apple.com/bug-reporting/

but IME you shouldn't expect a speedy response.  Pursuing it concurrently
with AWS would be advisable.

            regards, tom lane