stop using public dns for proxy ip

[ch604]

engintron is toted as a plugin for cpanel servers, which are expected to host websites to start with. assuming that is true, what is the reasoning behind using public dns to determine the IP address of the website? i imagine that this would slow the connection by creating an extra external lookup. i would figure that engintron would generate its own PROXY_DOMAIN_OR_IP block per domain based on information in /etc/userdatadomains or another static file. this would prevent issues when using IP obfuscation tools like cloudflare or sucuri, as well as issues when testing migrated sites with hosts file modification.

[bdtech]

Try custom_rules yet?
set $PROXY_DOMAIN_OR_IP "YOUR-CP-SERVER-IP";

[ch604]

hositng sites on multiple ips would break manually setting the variable globally ahead of time. engintron is already creating nginx configurations per domain, so it may as well also include the real hosted ip per the apache configuration.

[fevangelou]

@ch604

engintron is already creating nginx configurations per domain, so it may as well also include the real hosted ip per the apache configuration

Not exactly... As for public DNS, if you don't like the ones that come with Engintron, you can simply use the internal DNS resolvers or custom ones. In v1.9.3 or 1.9.4 I'll offer the option to easily bypass them with your own.

[ch604]

its not that i dont like the public dns resolver or want to use a custom one; its that i dont understand why a dns lookup has to occur at all. nginx and apache are installed on the same server, and i cant think of a reason as to why engintron should not be able to utilize the information from apache or cpanel to proxy a connection, instead of making a dns lookup to get the same ip address its already listening on.

using a dns lookup adds a delay in processing, and nginx breaks if dns is not pointed to the server on which it is running. using a static ip generated from /etc/userdatadomains fixes both.

[bdtech]

Why not use the internal DNS resolver? Its latency should be effectively 0.01ms

[ch604]

the internal dns resolver will return a public ip, while in a NAT situation, the proxy would need to go to the natted ip instead. some servers also do not serve dns since this processing is offloaded elsewhere.

id rather not kludge a temporary fix just to test migrated websites using hosts file edits, though a script to set and unset this wouldnt be so bad. nginx under engintron should be able to accept and serve properly formed requests whether dns is live or not.

[fevangelou]

@ch604 This is required by Nginx to properly proxy HTTP traffic to Apache, the fastest way. And keep in mind that DNS requests are cached for 30 mins by default, so it's not a performance issue. Either way this option will soon be configurable, exactly to address cases like AWS etc.