OT: Dealing with a hosting company with it's head up it's rear end

Aryeh Friedman aryeh.friedman at gmail.com
Thu Aug 13 20:23:54 UTC 2020

On Thu, Aug 13, 2020 at 3:13 PM Michael Sierchio <kudzu at tenebras.com> wrote:

> Unless they are completely clueless, that's easily detected.  Although
> there is evidence suggestive of them being clueless...

Yes they are complete clueless as evidenced in the same thread:'

us: We need reverse DNS on the private IP range that the VM's are on and a
request to get a stable VPN connection (not one that dies randomly every 30
to 60 mins)
them: You should be using the IP address when connecting to the servers
which would not utilize rDNS, I am not sure what you are referring to when
mentioning reverse DNS on the LAN for rapid communication? Can you please
clarify the specific record being requested .... As for the VPN - I will
relay this to our network team to review the timeout settings on the VPN -
however going forward RDP and SSH will be closed off and utilizing the
NCentral login provided to connect from within NCentral using the usernames
and passwords provided will be the best and most secure method of accessing
either server.

Almost everything that is accessible by IP (SSH, SCP, Mail, HTTP, etc.) for
security and record keeping reasons will when you connect to the remote
side of the connection attempt to turn the IP you are coming from into a
DNS name and in *MANY* cases (such as all 4 listed above, and many others)
will attempt to resolve the IP you are coming from before allowing you to
connect.  If they can't then they in most cases will hang until the
resolution times out (in more extreme cases will just refuse the connection
after the timeout hang).   This causes 10 to 30 second hangs during each
connection being made.   Since part of our system requires many such
connections (HTTP from windows to FreeBSD) on the order of 2 or 3 a minute
this causes a severe performance hit on that subsystem and makes it barely
usable (note to Steve this is *ONE*, out of quite a few other ones, of the
sources of performance issues your staff/clients are complaining about)..
As to what we need: 1. We need all IP's within the VPN/private network to
have a reasonable reverse DNS entry and be accessible from the
nameserver(s) that Windows, FreeBSD and CentOS us. 2. Because the IP
assigned when connecting to the VPN is dynamic it is not possible to have a
one entry fixes all type solution and thus the entire range must have

them: TCP/IP is not designed for your use case

(super WTF?!?!?)

Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org

More information about the freebsd-questions mailing list