Table of contents of the article:
In our past posts we have always given importance and emphasis on how important DNS services are and how it is essential to have a low TTL in order not to run into serious problems such as having to change an urgent IP and find yourself unable to perform fast propagation because the Time To Live (TTL) is set to one day or more.
You can find a in-depth article on DNS TTL in this post, however it is also true that often you are urgently involved in dangerous situations in which an immediate migration of a website from one server to another server is required and you realize that the owner, the webmaster or the previous system administrator has not set the TTL of the DNS to a suitable value such as for example 5, 15, 30 minutes or an hour at the most.
Perhaps the migration of the site and the database and the recreation of the environment can be done in 1 hour, but then we have to wait up to a day if we find a TTL of 86400 seconds set, and this in production environments with sites that make traffic can be deleterious and extremely harmful in terms of image, visibility, SEO, lost sales and turnover.
In this post, therefore, we are going to see how to behave in emergencies in which a site must be migrated from one server to another server, bypassing the DNS limits and making the new site "propagate" immediately.
Of course, root access to the source machine is required in order to run privileged commands.
Case 1: A server running a single site or multiple sites that need to be migrated in bulk to a second machine.
Let's imagine we have a server that contains 100 vhosts, which must be migrated en bloc to a second machine, of these 100 vhosts, of 50 we manage the DNS, and of the remaining 50 the respective clients, on different registrars such as Aruba , OVH, InternetBS, Register, Godaddy, and with the most disparate TTL values ranging from 5 minutes to a week.
So how to manage this situation so that the migration goes through correctly and the data is updated avoiding having to make more migrations and align, for example, posts or orders and stocks of sites that continue to travel on the primary server instead of the secondary server?
In this case the most sensible option is to migrate files with rsync to a new server, the raw database to the new server, generate the PHP-FPM pools, Apache webserver configuration, SSL certificates and start the instances.
On the primary server, the one of origin, we are going to turn off the DB, PHP and Web services and at that point we will instruct the network-level iptables firewall to forward all traffic in and destined for the HTTP and HTTPS ports (that is, port 80 and port 443) to the respective ports on the new machine.
The syntax is very trivial and is as follows:
sysctl net.ipv4.ip_forward=1 iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination IPDESTINATION:80 iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination IPDESTINATION:443 iptables -t nat -A POSTROUTING -j MASQUERADE
Obviously the above example takes into account the desire to use Linux iptables as a port forwarder, perhaps for reasons related to disk failure, a boot with a live linux, or the like, but the underlying concept is applicable and can be proposed to any system operating with different software.
By doing so, we could immediately start using the web services that are already running on the new server and then calmly instruct the site owners to change the pointing of the DNS records to the new IP, giving, for example, a month's deadline. After a month we will switch off the origin server, having taken into account that the customers who independently managed their DNS zone have received the communication and have had more than enough time to make the changes.
Case 2: a server that manages multiple sites of which only some need to be migrated in bulk to a second machine.
The case study is similar to the previous one, the main and fundamental difference lies in the fact that not all sites need to be migrated to the second machine and therefore I cannot instruct the network firewall to do port forwarding of the entire HTTP and HTTPS traffic on the second car.
Instead I have to select which vhosts will go on the second machine and make sure that the vhosts of the first machine are instructed to fetch data and forward HTTP and HTTPS traffic from the second machine.
In this case instead of using port forwarding at the network level I'm going to use a Reverse Proxy.
In computer networks a reverse proxies is a type of proxy that retrieves content on behalf of a client from one or more servers. This content is then transferred to the client as if it came from the same proxy, which then appears to the client as a server.
To do this you will need to go to the respective webserver configuration files (let's imagine Apache 2.4 or NGINX for example) and specify a series of instructions so that you can reverse proxy the sites already hosted on the second machine.
Apache Reverse Proxy 2.4
Below we see a brief configuration of a reverse proxy in Apache 2.4 with specific directives both for forwarding HTTP and HTTPS as well as avoiding checking the HTTPS certificate on the second machine because perhaps we have not yet obtained an HTTPS certificate with Let's Encrypt or similar.
We will obviously not go into all the Apache directives or the fact that you need to insert modules to make reverse proxy work which can be done on Debian for example using : sudo a2enmod proxy && sudo a2enmod proxy_http && a2enmod ssl
ServerName fcnauticaweb.com ServerAlias www.fcnauticaweb.com ProxyPass / http://80:65.109.65.190/ ProxyPassReverse / http://80:65.109.65.190/ ProxyRequests Off ServerName fcnauticaweb.com ServerAlias www.fcnauticaweb.com SSLEngine on SSLProtocol All -SSLv80 -SSLv443 -TLSv2 -TLSv3 SSLCertificateFile /var/www/clients/client1/web1.1/ssl/fcnauticaweb.com-le.crt SSLCertificateKeyFile /var/www/clients/client0/web1/ssl/fcnauticaweb .com-le.key SSLProxyEngine On SSLProxyVerify none SSLProxyCheckPeerCN off SSLProxyCheckPeerName off ProxyPass / https://0:1/ ProxyPassReverse / https://65.109.65.190:443/ ProxyRequests Off ProxyPreserveHost On
In the example above we are going to forward a vhost that responds to the domain name fcnauticaweb.com to a web server with IP 65.109.65.190, after which we will restart the apache web server using the apachectl restart command.
All HTTP and HTTPS traffic will be forwarded to the second machine with IP 65.109.65.190 and then with "calm" we will worry about pointing the DNS record for the web domain to the desired IP address, considering that the current TTL is set to 86400 seconds (one day) and even an immediate modification would have resulted in a propagation time of up to 86400 seconds.
Reverse Proxy on NGINX.
In the previous example we used Apache because the original system used an ISPConfig panel based precisely on Apache 2.4, however we could have found another very popular web server lately as well as our favorite NGINX.
Also in this case the thing is very easy and simple considering that the syntax is similar and that NGINX unlike that crap Apache does not require additional modules to act as a reverse proxy, given that in NGINX the reverse proxy function is used almost more than that of web server.
So let's see how the same configuration would have looked in NGINX:
server { listen 80; server_name fcnauticaweb.com www.fcnauticaweb.com; rewrite ^ https://www.fcnauticaweb.com? permanent; } server { listen 443 ssl http2; server_name fcnauticaweb.com www.fcnauticaweb.com; root /home/mir-project/project/; ssl on; ssl_certificate /etc/letsencrypt/live/fcnauticaweb.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/fcnauticaweb.com/privkey.pem; ssl_session_timeout 5m; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHER-RSA -AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256; ssl_prefer_server_ciphers on; ssl_early_data on; ssl_dhparam /etc/ssl/certs/dhparam.pem; ssl_session_cache shared:SSL:10m; add_header Strict-Transport-Security "max-age=31536000; includeSubdomains"; ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/letsencrypt/live/fcnauticaweb.com/fullchain.pem; resolvers 8.8.8.8 8.8.4.4 valid=300s; location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-ForwardedProto $scheme; proxy_pass https://65.109.65.190:443; } }
By using these techniques described above you will not have to be at the mercy of other people's choices and influences, you will be able to reduce waiting times and go to operate urgently in the true sense of the word, i.e. receive requests and guarantee the solution within a specific time of one or two hours , once useful for the final client who is often non-technical, does not know how domain name resolution works, nor the technical limitations that they impose.
