Skip to content

Latest commit

 

History

History
78 lines (45 loc) · 6.43 KB

README.md

File metadata and controls

78 lines (45 loc) · 6.43 KB

Integrate Platform as a Services with Virtual Networks (part 3)

Introduction

In nowadays Microsoft provides a wide range of publicly available Platform as a Services in Azure. As was discussed in previous parts, Private Endpoints and Service Endpoints allows to expose/limit access PaaS privately. Main limitation for both solutions is an absence of On-Premises access.

This document gives an example of how a self-hosted DNS forwarder can be used for exposing Private Endpoint's DNS. This allows to use such forwarder for On-Premises access.

Theoretical Part

DNS

Computers on a network can find one another by IP addresses. To make it easier to work within a computer network, people can use a Domain Name System (DNS) to associate human-friendly domain names with IP addresses, similar to a phonebook. A DNS can also associate other information beyond just computer network addresses to domain names.

In other words, DNS is a directory of easily readable domain names that translate to numeric IP addresses used by computers to communicate with each other. For example, when you type a URL into a browser, DNS converts the URL into an IP address of a web server associated with that name.

Authoritative vs Recursive

There are two name server configuration types:

  • Authoritative - to resource records that are part of their zones only. This category includes both primary and secondary name servers.
  • Recursive - offer resolution services, but they are not authoritative for any zone. Answers for all resolutions are cached in a memory for a fixed period of time, which is specified by the retrieved resource record.

Although a name server can be both authoritative and recursive at the same time, it is recommended not to combine the configuration types. To be able to perform their work, authoritative servers should be available to all clients all the time. On the other hand, since the recursive lookup takes far more time than authoritative responses, recursive servers should be available to a restricted number of clients only, otherwise they are prone to distributed denial of service (DDoS) attacks.

Azure Private DNS zone

Azure Private DNS provides a reliable, secure DNS service to manage and resolve domain names in a virtual network without the need to add a custom DNS solution. By using private DNS zones, you can use your own custom domain names rather than the Azure-provided names available today. Using custom domain names helps you to tailor your virtual network architecture to best suit your organization's needs. It provides name resolution for virtual machines (VMs) within a virtual network and between virtual networks. Additionally, you can configure zones names with a split-horizon view, which allows a private and a public DNS zone to share the name.

To resolve the records of a private DNS zone from your virtual network, you must link the virtual network with the zone. Linked virtual networks have full access and can resolve all DNS records published in the private zone. Additionally, you can also enable autoregistration on a virtual network link. If you enable autoregistration on a virtual network link, the DNS records for the virtual machines on that virtual network are registered in the private zone. When autoregistration is enabled, Azure DNS also updates the zone records whenever a virtual machine is created, changes its' IP address, or is deleted.

Practical Part

As was stated in the Introduction, this document gives an example of using a DNS forwarder (aka Recursive DNS) for sharing Azure private and/or on-premises private DNS zones. For that purpose will be used CoreDNS running as an Azure Container Instance.

For the environment deployment following ARM template will be used. It deploys multiple resources, which could be grouped to:

  1. PaaS itself, which in this example is a storage account
  2. Resources used for exposing the public resource privately (NIC, private endpoint, private DNS zone)
  3. DNS Forwarder, which is just a container instance, used for private endpoint's resolve (by forwarding all incoming requests to a VNet with linked private DNS zone). It's configuration you can check here
  4. Virtual Machine, which will be used to resolve the PaaS privately (using Private Endpoint) and publicly using Custom Script extension.

You start the deployment by using any prefferable way (Powershell, CLI etc.) or by clicking the button below:

NOTE: 'With Dns Forwarder' option should be true

Result

After the deployment is completed, you can check VM's Custom Script executions output:

Summary

As shown in the previous section, Private Endpoint allows to expand a service to a VNet as read-only Network Card. For on-premises workloads to resolve the FQDN of a private endpoint a DNS forwarder is needed. As in this demo for a DNS forwarder CoreDNS container instance were used, you can use the same approach to work with Private Endpoints from On-Premises:

Related Information