Thursday, August 19, 2021

 

Azure Private Endpoint DNS configuration and zone separation

Introduction:

This article is a continuation of the series of articles starting with the description of SignalR service. In this article, we follow up on the discussion of Azure Private Endpoints with what helps Azure Gateway span private IP addresses, public IP addresses and availability zones. The topic in this article is the DNS configuration to route traffic between zones.

Zone-Down and DNS Configurations.

Availability zones are indistinguishable from one another. They are represented by numbers rather than by names in the Azure Resource Manager templates for resources provisioned in a region. A region can have up to three availability zones so their number is finite although there can be up to 100 private endpoints per application in a premium sku.

The Azure private endpoint is merely a network interface and has a designated IP address that can be reached over the virtual network. The endpoint can be accessed over the same virtual network, regionally peered virtual network, globally peered virtual network, on-premises using ExpressRoute or VPN and services with Azure Private Link. The connection to the private endpoint is always one-direction. It can only be initiated by the client.

An Azure service can have more than one private endpoints. These endpoints can be one per zone if the virtual network is separated. An application gateway can span all the endpoints including the public endpoint as its backend pool members. When the client sends traffic to the application gateway, it can be diverted to different private endpoints.

Some restrictions apply to the Azure private endpoint. For example, there are limits to the number of private endpoints that can be created per subscription. The resource and the virtual network must be in the same region otherwise there will be an error as follows: “Resource

/subscriptions/<hidden>/resourceGroups/RAVIRAJAMANI_TEST_RG/providers/Microsoft.Network/virtu alNetworks/RAVIRAJAMANI-VNET-1 referenced by resource /subscriptions/<hidden>/resourceGroups/ravirajamani_test_rg/providers/Microsoft.Network/privateEn dpoints/ravirajamani-redis-3-ep was not found. Please make sure that the referenced resource exists, and that both resources are in the same region.” Since all availability zones are in the same region for a resource, this restriction does not impose any difficulty with provisioning private endpoints for a given service. These endpoints can be one per zone if the virtual network is separated. An application gateway can span all the endpoints including the public endpoint as

its backend pool members. When the client sends traffic to the application gateway, it can be diverted to different private endpoints.

Azure Private Endpoint DNS configuration and zone separation

Introduction:

This article is a continuation of the series of articles starting with the description of SignalR service. In this article, we follow up on the discussion of Azure Private Endpoints with what helps Azure Gateway span private IP addresses, public IP addresses and availability zones. The topic in this article is the DNS configuration to route traffic between zones.

Zone-Down and DNS Configurations.

Availability zones are indistinguishable from one another. They are represented by numbers rather than by names in the Azure Resource Manager templates for resources provisioned in a region. A region can have up to three availability zones so their number is finite although there can be up to 100 private endpoints per application in a premium sku.

The Azure private endpoint is merely a network interface and has a designated IP address that can be reached over the virtual network. The endpoint can be accessed over the same virtual network, regionally peered virtual network, globally peered virtual network, on-premises using ExpressRoute or VPN and services with Azure Private Link. The connection to the private endpoint is always one-direction. It can only be initiated by the client.

An Azure service can have more than one private endpoints. These endpoints can be one per zone if the virtual network is separated. An application gateway can span all the endpoints including the public endpoint as its backend pool members. When the client sends traffic to the application gateway, it can be diverted to different private endpoints.

Some restrictions apply to the Azure private endpoint. For example, there are limits to the number of private endpoints that can be created per subscription. The resource and the virtual network must be in the same region otherwise there will be an error as follows: “Resource

/subscriptions/<hidden>/resourceGroups/RAVIRAJAMANI_TEST_RG/providers/Microsoft.Network/virtu alNetworks/RAVIRAJAMANI-VNET-1 referenced by resource /subscriptions/<hidden>/resourceGroups/ravirajamani_test_rg/providers/Microsoft.Network/privateEn dpoints/ravirajamani-redis-3-ep was not found. Please make sure that the referenced resource exists, and that both resources are in the same region.” Since all availability zones are in the same region for a resource, this restriction does not impose any difficulty with provisioning private endpoints for a given service. These endpoints can be one per zone if the virtual network is separated. An application gateway can span all the endpoints including the public endpoint as its backend pool members. When the client sends traffic to the application gateway, it can be diverted to different private endpoints.

Each endpoint must be given a name. With records in the domain name server, the endpoint becomes reachable and resolvable from a virtual network. The following options are available to configure the DNS settings of an Azure private endpoint: 1) using only the host file that resolves the name locally 2) using a private DNS zone to override the DNS resolution for a private endpoint with the zone linked to the virtual network, and 3) using a DNS forwarder with a rule to use the DNS Zone in another DNS server. It is preferrable to not override a zone that resolves public endpoints because if the connectivity to the public DNS goes down, those public endpoints will remain unreachable. That is why a different domain name with a suffix such as “core.windows.net” is recommended. Multiple zones with the same name for different virtual networks would need manual operations to merge the DNS records.

Conclusion:

Zone based traffic diversion is not a feature that Azure services provide but they do allow private endpoints. If we setup endpoints per zone, the diversion of traffic between zones to simulate zone down can be facilitated with an application gateway.

No comments:

Post a Comment