Please read the below discussion posts and provide two responses in 50 to 75 words
Post#1
DNS Failover is designed to operate at the DNS level. That is, the level before a client connects to any of your servers. DNS essentially converts your domain name (e.g.www.example.com) into the IP address of your server. By monitoring applications and altering DNS dynamically so clients are pointed to different IP addresses, you can control traffic fairly easily and expensively. However, DNS failover does have two notable limitations: a) DNS Failover does not fix an outage when a client is already connected to an application. This is because their browser may not query DNS again for quite some time. b) DNS Failover has a TTL cache issue that could take anywhere from 1 to 30 minutes or more for the IP address change to be visible around the world. This is since many ISP’s recursive DNS servers cache longer than required to reduce traffic. “Time is an important component of the Domain Name System (DNS) and the DNS Security Extensions (DNSSEC). DNS caches rely on an absolute notion of time (e.g., “August 8, 2018 at 11:59pm”) to determine how long DNS records can be cached (i.e., their Time To Live (TTL)) and to determine the validity interval of DNSSEC signatures. This is especially interesting for two reasons” (Malhotra, 2019).
DNS Failover has been around for quite some time and is reliable. As a result, the sequential mode is the most popular for e-commerce applications or where back-end databases exist and some type of synchronization step is required before falling back to the primary. The cloud network monitors all of the available servers based on the monitoring criteria you specify via the management GUI and when it detects the primary down, it automatically fails over to the secondary IP (or if the secondary is down, fails over to the tertiary, etc.). In a typical static content scenario, when the primary comes back, it updates DNS again to send traffic to the primary. However, in an application where back-end databases must be synchronized, you can easily disable auto-failback to prevent the primary server from receiving traffic again. “A passive redundancy approach with diversification has been applied to intrusion-tolerant systems (ITSs) that aim to tolerate cyberattacks on a server” (Okamoto, 2017).
The monitoring system will still alert you that it is back online, but you have to manually force it to start receiving traffic again. This allows you to perform whatever tasks are required to ensure that the primary has the latest copy of the database or whatever is required. One critical drawback to using DNS failover in a situation where back-end synchronization is critical is when the primary is only down for a very short period. The short period would be sufficient to trigger a failover, but insufficient so that existing client connections (or new connections where the TTL cache has not expired) permit some clients to still hit the primary site. In this case, both the primary and secondary sites could receive traffic and create completely different databases that are very difficult to synchronize. “A DNS Load Balancer Daemon (LBD) has been developed at CERN as a cost-effective way to balance applications accepting DNS timing dynamics and not requiring persistence” (Reguero Naredo, 2017).
Post#2
Cloud computing efficiency and security depends on several security concerns related to networks and connectivity. Protecting information system in cloud environment, from threats can be done largely by maintaining secure data traffic. The concepts of Domain Name System failover and Cloud failover come in this context of data traffic security. These two are most popular approaches in cloud security and share some similarities and dissimilarities between each other.
Comparison
Functionality of DNS and cloud failover depends on the authentication of IP addresses largely. Both the preventive measures in cloud service security find out necessary action to recover from failures such as downtime recovery. Both the solutions need open access to public cloud in order to become active. The monitoring mechanism used in both the systems are almost equal and works in the same way for identification of servers and detection of faults (Naredo & Pardavila, 2017). DNS and Cloud failover are equally capable of delivering fast recovery as soon as within 60 seconds and can change functions automatically based on the requirement scenario.
The differences in cloud and DNS failover starts with the process through which these functions run. DNS finds easiest solution in re-routing of traffic in cases where a particular server fails, and it makes the traffic run through other active servers. A system embedded in the process helps in detecting the active server through a technique known as ‘round-robin’ method. A fault in DNS failover is that it contains the cached data which keeps revolving till one user’s Time to Live (TTL) in the server. “A DNS Load Balancer Daemon (LBD) has been developed at CERN as a cost-effective way to balance applications accepting DNS timing dynamics and not requiring persistence” (Naredo & Pardavila, 2017).
Cloud failover is popular for its accuracy and precision of carrying out the task necessary for sustained uptime. It does not send cached data back frequently. Sessions cared by cloud have better utilization capacities as it allows remote deployment unlike DNS failover where critical applications of a server are interrupted. To sustain through the TTLs, cloud failover uses session-wise load-balancing that proves to be more efficient than round-robin of DNS. Further, DNS failover fails to offer the flexibility due to the pre-determined conditioning that makes it a rigit system. Cloud, however, includes the DNS often for offering optimized result via a permanent proxy IP address. “DNS, being open-source, is less secure and it has no uncommon method for deciding if data has been intercepted while transmission or information of a domain name originates from an approved domain owner or not” (Ansari et. Al., 2020).
Conclusion
As a result of limitations, cloud failover service is costlier than DNS. There are steady improvements identifiable in DNS in global network. Some of the services are also allowing cache-free recovery of server. In spite of the advancements, it is yet to compete equally with cloud failover. On the other hand, cloud has its challenges too. “In spite of Cloud Computing services seem to be very attractive as an alternative to traditional on-premise data centers, there is still some concern about the providers availability” (Goncalves & Fagotto, 2018).
