Private DNS Resolution

You can plan hostnames based on the locations, usages, and account information of ECSs, and map the hostnames to private IP addresses, helping you manage ECSs more easily.

For example, if you have deployed 20 ECSs in an AZ, 10 for website A and 10 for website B, you can plan their hostnames (private domain names) as follows:

• ECSs for website A: weba01.region1.az1.com – weba10.region1.az1.com
• ECSs for website B: webb01.region1.az1.com – webb10.region1.az1.com

After you configure the hostnames, you will be able to quickly determine the locations and usages of ECSs during routine management and maintenance.

For details, see Configuring Private Domain Name Resolution for ECSs.

As the number of Internet users is continuously increasing, a website or web application deployed on a single server can hardly handle concurrent requests during peak hours. A common practice is to deploy the website or application on multiple servers and distribute the load across the servers.

These servers are in the same VPC and communicate with each other using private IP addresses that are coded into internal APIs called among the servers. If one of these servers is replaced, its private IP address changes. As a result, you need to change this IP address in the APIs and re-publish the website. This poses challenges for system maintenance.

If you create a private zone for each server and configure record sets to map their private domain names to the private IP addresses, they will be able to communicate using private domain names. When you replace any of the servers, you only need to change the private IP address in the record set, instead of modifying the code.

Figure 2 illustrates such use of private domain name resolution.

Figure 2 Configuring private DNS for cloud servers

The ECSs and RDS instances are in the same VPC.

• ECS0: primary service node
• ECS1: public service node
• RDS1: service database
• ECS2 and RDS2: backup service node and backup database

When ECS1 becomes faulty, ECS2 must take over. However, if no private zones are configured for the two ECSs, you need to change the private IP addresses in the code for ECS0. This will interrupt services, and you will need to publish the website again.

Now assume that you have configured private zones for the ECSs and have included their private names in the code. If ECS1 becomes faulty, you only need to change the DNS records to direct traffic to ECS2. Services are not interrupted, and you do not need to publish the website again.

For more details, see Configuring a Private Domain Name for an ECS.

The comparison between private DNS and public DNS servers is as follows:

• If a public DNS server is configured for subnets of the VPC associated with a private zone, domain name requests to access cloud resources from ECSs in the VPC will be directed to the Internet.

  The ECSs access Huawei cloud services such as OBS and SMN over the Internet. This increases the network latency and reduces access speed.

  Steps 1 to 10 on the right of Figure 3 show the resolution process.

• If a Huawei Cloud private DNS server is configured for the subnet, the private DNS server directly processes the requests to access cloud services.

  When the ECS accesses the Huawei cloud services, the private DNS server returns their private IP addresses, instead of routing requests over the Internet. This reduces network latency and improves access speed.

  Steps 1 to 4 on the left of Figure 3 show the resolution process.

  To make your ECS accessible within the private network, change the default DNS servers of the ECS to private DNS servers. For details, see How Do I Change Default DNS Servers of an ECS to Huawei Cloud Private DNS Servers?

Figure 3 Accessing cloud services