You can choose two main networking options when running your Azure Database for PostgreSQL - Flexible Server. The options are private access (VNet integration) and public access (allowed IP addresses). At server creation, you must pick one option.
- Private access (VNet integration) – You can deploy your flexible server into Azure Virtual Network. Azure virtual networks provide private and secure network communication. Resources in a virtual network can communicate through private IP addresses.
- Public access (allowed IP addresses) – Your flexible server is accessed through a public endpoint. The public endpoint is a publicly resolvable DNS address. The phrase “allowed IP addresses” refers to a range of IPs you choose to give permission to access your server via firewall rules.
In this blog article we will delve into Private access (VNET integration) network option and discuss common patterns and actions necessary for successful Dynamic Name Resolution (DNS) in that scenario.
Private Access with VNET Integration Networking Option
When deploying your Flexible Server within a VNET, the Flexible Server must be deployed in subnet that has been delegated to PostgreSQL Flexible Server. You can deploy multiple Flexible Server instances into the same delegated subnet as long as the subnet size supports it. This is described in detail Networking overview - Azure Database for PostgreSQL - Flexible Server | Microsoft Docs. No public endpoint to the Flexible Server is exposed. This requires that you plan upfront how your clients can resolve your Flexible Server instance without any issues.
It is not recommended to connect to Flexible Server using its IP address as it is dynamic and can change. Recommended best practice is to always use the fully qualified domain name (FQDN) as hostname when connecting to Flexible Server. The FQDN can be found in Azure Portal, Flexible Server, overview panel, as shown in Figure 1 below.
Figure1: FQDN on Azure Database for PostgreSQL – Flexible Server overview Azure Portal blade.
When using Private access with VNET integration one important part of network infrastructure one needs to be aware of is Domain Name Services (DNS).
Let us begin with reminding you what is DNS and its place within networking stack. Domain Name Servers or DNS are very similar to a phone book that contains all the public domains and their corresponding IP Addresses. DNS is an internet service that translates the domain name into IP addresses. Whenever you request for google.com or any other website, your request first goes to DNS servers. Then, the DNS server translates the domain into the corresponding IP Address and forwards the request to the website server, and finally the website loads into your browser.
A resource record is a one-line text description that defines a particular resource. It’s the base unit of the DNS system. The resource records pertaining to your domain are stored in a zone file. A DNS zone is a subset of the domain name system, often a single domain. A zone file contains the mappings between IP addresses and names within that subset, in the form of individual resource records that point to different aspects of the domain.
Now let’s discuss how Azure Database for PostgreSQL – Flexible Server integrates with DNS when private networking option is picked. Azure private DNS zone integration allows you to resolve the private DNS within the current VNET or any in-region peered VNET where the Private DNS Zone is linked. If you use Azure Portal or Azure CLI for creating flexible servers, you can either provide a private DNS zone name that you had previously created in the same or a different subscription must end with postgres.database.azure.com, otherwise a default private DNS zone is automatically created in your subscription. If you use Azure API, an Azure Resource Manager template (ARM template), or Terraform, please create private DNS zones that end with postgres.database.azure.com and use them while configuring flexible servers with private access.
Below, I will describe some common network topologies and how to configure DNS to be able to resolve your Azure Database for PostgreSQL - Flexible Server private endpoint.
Access within the same VNET
This is most common and simplest pattern available with private access\VNet integration option for Flexible server networking. It consists of private Azure VNET with subnet delegated for Azure Database for PostgreSQL Flexible server.
Since Azure automatically creates system routes and assigns the routes to each subnet in a virtual network all clients have connectivity with Flexible Server. Since Azure DNS is used to provide name resolution, all clients can resolve the Flexible Server FQDN using the Private DNS Zone. No additional configuration is required.
In the below diagram image\Figure 2:
- Flexible Server is deployed in a delegated subnet.
- Clients can be deployed in a different subnet within the same VNET.
- Azure Private DNS Zone is used for name resolution
Figure 2: Azure Database for PostgreSQL – Flexible Server access within same VNET
Access from another VNET using peering.
This pattern is an extension of the previous pattern and used for grouping applications into separate virtual networks due to segmentation requirements.
In the below diagram image\Figure 3:
- Flexible Server is deployed in a delegated subnet in VNET1.
- VNET1 and VNET2 are peered.
- Client are deployed in a subnet in VNET2.
Figure 3: Azure Database for PostgreSQL – Flexible Server access from peered VNET
Since both virtual networks are peered clients can directly connect with your Flexible Server instance via IP. However, you will notice that in this pattern DNS name resolution is not working.
Figure 4: Using Test-NetConnection Azure PowerShell cmdlet to test DNS name resolution.
The reason for this is that by default DNS name resolution is scoped to a virtual network. This means that any client in VNET2 is unable to resolve the Flexible Server FQDN in VNET1.
In order to resolve this issue, you must make sure clients in VNET2 can access the Flexible Server Private DNS Zone. This can be achieved by adding a virtual network link to the Private DNS Zone of your Flexible Server instance. The steps are:
- In Azure Portal navigate to Private DNS Zones and locate the Private DNS Zone of your Flexible Server instance. By default this is <servername>.private.postgres.database.azure.com, as you can see in Figure 5 image below:
Figure 5: Private DNS Zone in Azure Private DNS Zones blade in Portal
- Open this zone and navigate to virtual network links.
- Click add and enter a link name and select VNET2 as in the Figure 6 image below. Auto registration can be left unchecked and click ok.
Figure 6: Adding virtual network link to Private DNS Zone in Azure Portal.
Once the virtual network link has been created you are able to resolve your Flexible Server instance from any client in VNET2.
Figure 7: Successful test using Test-NetConnection Azure PowerShell cmdlet to test DNS name resolution.
NOTE: If you have clients in Region A and Flexible Server in Region B then you would need a global virtual network peering between both regions. You would follow same steps as above to make sure that DNS resolution is working.
Access using Custom DNS server in Hub and Spoke Network Model.
In this pattern the hub acts as a central point of connectivity to many spoke virtual networks. The hub can also be used as a connectivity point to your on-premises networks. The spoke virtual networks peer with the hub and can be used to isolate workloads. The benefits of using a hub and spoke configuration include cost savings, overcoming subscription limits, and workload isolation. In enterprises often a custom DNS server is deployed in the Hub VNET which is linked to the on-premises DNS server.
Figure 8: Network diagram showing access through custom DNS server in Hub and Spoke network.
In the diagram above shown in Figure 8:
- Flexible Server is deployed in a delegated subnet in Spoke-VNET1
- Spoke-VNET1 and Spoke-VNET2 are connected through the Hub-VNET.
- Azure Firewall is responsible for the routing.
- Client are deployed in a subnet in Spoke-VNET2.
- Spoke-VNET1 and Spoke-VNET2 have a customer DNS Server configured which is deployed in the Hub-VNET.
Since both spoke virtual networks are connected through the Hub virtual network clients can directly connect with your Flexible Server instance. However, you will notice that in this pattern DNS name resolution is not working.
In order to resolve this issue, you must perform the following steps:
- For the Custom DNS Server in the Hub VNET add a conditional forwarder for DNS domain postgres.database.azure.com domain.This conditional forwarder must point to the Azure DNS IP address: 168.63.129.16. as shown in Figure 9 below
Figure 9: Setting conditional forwarder IP address in custom DNS Server.
- As an alternative to a conditional forwarder, you can also configure a server-level forwarder to Azure DNS.
Figure 10: Setup of server-level forwarder in Azure DNS
- Add a virtual network link in the Private DNS Zone for Hub-VNET. This is described at pattern 2.
- If you also have clients on-premises which must connect to the Flexible Server FQDN then you would need a conditional forwarder in the on-premises DNS server pointing to the IP address of the Custom DNS server in Azure.
We are hoping that you find this blog article helpful and are always interested how you plan to use Flexible Server deployment options to drive innovation to your business and applications. Additional information on topics discussed above can be found in following documents:
- Azure Database for PostgreSQL – Flexible Server networking docs
- Hub and Spoke network topology in Azure
- Azure Private DNS Documentation
We’re always eager to get your feedback, so please reach out via email to Ask Azure DB for PostgreSQL.
Posted at https://sl.advdat.com/3Bwk7wH
