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.
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.
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.
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:
Figure 2: Azure Database for PostgreSQL – Flexible Server access within same VNET
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:
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:
Figure 5: Private DNS Zone in Azure Private DNS Zones blade in Portal
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.
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:
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:
Figure 9: Setting conditional forwarder IP address in custom DNS Server.
Figure 10: Setup of server-level forwarder in Azure DNS
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:
We’re always eager to get your feedback, so please reach out via email to Ask Azure DB for PostgreSQL.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.