Forward all TLD requests to another server

Question

So, an emergency has been landed in my lap, and unfortunately I'm ill-equipped to deal with it. An IT tech for a client's company changed the A record for a domain, then went on holiday. He is the only one who has access, and there's no way to change it back until he reappears from the jungle.

He was supposed to point just the www. A record to a new IP, pointing to our server which is hosting mysite.com - however, he changed the * A record to the new IP - meaning all subdomains are now effectively dead (mail., exchange., secure., etc). Originally the * A record pointed to another server that handled all of the subdomain requests separately.

Although I can't access the DNS controls, I do have complete access to the DigitalOcean server and control panel for where the *A record is now pointing.

Is there anything I can do from my end on the DigitalOcean server, either via the DNS control panel (although it doesn't appear so at a glance) or via the virtual.conf file (see below) to properly forward any requests (i.e. mail.mysite.com) to the correct IP that should then handle the request correctly?

For reference, the server is CentOS 6.5 x64 running nginx. The server block that's currently handling the incoming request is as follows:

server {
    listen       80;
    server_name  mysite.com www.mysite.com;
    root   /var/www/html/mysite.com/;
    error_page 403 404 500 502 503 504 = /server_error.php;
    index  index.php index.html index.htm;

    location / {
         try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }
}

Thanks for your help. Apologies for the TL;DR.

Answer 1

For HTTP that might work, but for HTTPS the server might not have the right certificates, and for other protocols (such as for email) the HTTP service won't do the job.

Maybe stand up HAProxy in tcp mode, listening on the ports that connections come in on and proxying to the correct ports on the "real" server? This might not work quite right for some services, as the apparent source of the connection will be the HAProxy box.

A better approach might be to get access to the DNS. There must be some mechanism you can use to gain access to the account; is nobody else at the client's company set up as a contact with the DNS provider? Or can you just reset the guy's email password and then fire a password reset email?

Edit:

To get HAProxy working for this case, you'll want to install HAProxy - this requires EPEL to be enabled, if it's not already. Then yum install haproxy.

Edit /etc/haproxy/haproxy.cfg; not sure what exactly the default config looks like in there, but you'll want to clear out any listen sections first, while leaving the global and defaults sections.

Then, for each listening port that you need to send to the other server, you will want a section like this (note that if you add port 80, you'll need to stop the nginx service first):

listen port-443
    bind :443
    mode tcp
    balance roundrobin
    server realserver 192.0.2.1:443

(where 192.0.2.1 is the IP of the server that should be handling the connection).

Answer 2

Another approach would be to just call the DNS Service provider, and explain them what happened. I guess after some "proof" that you're the owner of the domain / delegate or something, they might give you access or change it for you...