ABSTRACT

This whitepaper is intended to give an overview of

Azure DNS service, integration aspects of hybrid
networking with on-premises and cloud
infrastructure, technical considerations, and
scenarios for SAP on Azure deployments.

Konstantin Popov, Evren Buyruk

Sr. Technical Specialist, SAP on Azure, Microsoft
SAP on Azure Sr. Cloud Solution Architect, SAP on Azure, Microsoft

DNS integration whitepaper

Version: 1.0 Release date: 08.09.2021

Tabel of contents
Disclaimer ................................................................................................................................................ 2
Introduction............................................................................................................................................. 2
Azure DNS overview, capabilities, limitations ......................................................................................... 2
Azure provided DNS ............................................................................................................................ 3
Azure DNS private zones ..................................................................................................................... 4
Azure custom DNS ............................................................................................................................... 7
SAP on Azure. DNS integration scenarios................................................................................................ 9
Scenario 1. SAP on Azure. Azure provided DNS and/or Azure private zones ..................................... 9
Scenario 2. SAP on Azure. Hub-spoke architecture........................................................................... 10
Scenario 3. SAP on Azure. Integration with SAP RISE/STE/HEC on Azure ......................................... 11
Conclusion ............................................................................................................................................. 12

1
Disclaimer
The content of the document doesn’t provide exhausting and comprehensive information about
Microsoft Azure DNS service. For the latest product information please follow Azure DNS
documentation | Microsoft Docs.
The content is only valid on the date it was released. Authors don’t take responsibility and
accountability of any misinterpretation of the design patterns, and potential service, features, and
function changes, which are part of the described topic.

Introduction
Planning and designing architecture patterns for SAP deployments always covers different parts of the
infrastructure and services components like compute, storage, network, security, interfaces etc.
Amongst this, domain name resolution (DNS) concept and integration with existing infrastructure plays
an essential role in this process. Before going deeper with Azure DNS and how it works, we want briefly
to touch and explain one of the most key areas in Azure networking - Virtual Network or VNet, which
is observed throughout this content. Azure Virtual Network (VNet) is the fundamental building block
for your private network in Azure. VNet enables many types of Azure resources, such as Azure Virtual
Machines (VM), to securely communicate with each other, the internet, and on-premises networks.
VNet is similar to a traditional network but brings additional benefits of Azure's infrastructure such as
scale, availability, and isolation. All resources in a VNet can communicate outbound to the internet, by
default. External services can communicate inbound to a resource by assigning a public IP address or
a public Load Balancer. Customers can also use public IP or public Load Balancer to manage Internet
outbound connections. Having explained about Azure virtual, let’s now come back to the DNS topic
and go deeper into it. DNS works as a phonebook for the computer networks, which translates human
readable names into IP addresses of the services and compute resources that have to communicate
with each other. DNS is also a pivotal function for encryption and cross system communication.

Modern software, including SAP, exchange data and communicate using various protocols and APIs
(application programming interface), leveraging DNS names. Therefore, without having a proper and
robust DNS service, it would not be possible for systems to connect to each other. Most of the
customers’ SAP deployments include different SAP applications (e.g. S/4HANA, BW/4HANA, PI, EWM,
Solution Manager etc.) communicating with one another and other 3rd party software using different
interfaces like RFC, BAPI, Webhooks, HTTP/s and others. Hence, it’s particularly important to properly
design DNS infrastructure for any SAP on Azure deployment, that will be a baseline for cross-system
communication and integration.

There are different options how DNS can be designed and implemented for SAP on Azure, which will
be described in this whitepaper.

This document gives an overview of Azure DNS service, available features, and limitations. It provides
several examples on common patterns for Azure DNS deployments design, and integration with
customers on-premises networks, and other Hyperscalers clouds.

Azure DNS overview, capabilities, limitations

Like every other DNS service, Azure DNS provides a name resolution service (from a DNS record to IP
address) by way of leveraging Microsoft Azure infrastructure. By default, this service provides
Microsoft customers with capability to manage DNS records via their own credentials, APIs, tools and
even billing.

2
While planning a target DNS and networking concept, various aspects, like scope of solution (private,
public or both), security and integration should be kept in mind. Microsoft Azure DNS is not an
exception here. Let’s quickly recap which capabilities Azure DNS provides (status as of the date of this
document release). In general, Azure DNS supports two types of name resolution scenarios:

• Azure Public DNS - manages records and provides name resolution for internet-facing
domains. When Azure DNS is leveraged , there are certain restrictions to consider. One of
the restrictions is around the procurement of a domain , for this companies should use 3rd
party registrars like GoDaddy, Domain.com or similar, then delegate your domain (e.g
contoso.com) to Azure DNS for records management.
• Azure Private DNS - provides a reliable and secure DNS service for your Azure virtual networks.
Supports all common DNS record types.

In most cases, due to the nature of SAP environments, being business critical systems, processing
companies’ confidential information, SAP systems are deployed within the VNets, that by default don’t
have direct internet exposure (inbound and outbound). In addition, the enterprise landing zone for
SAP on Azure often designed even in a more sophisticated, protected, and secure way, by using
services like Azure Application Gateway, Azure firewall and/or 3rd party NVAs, security monitoring and
management tools. However, this is a topic of another article on how to architect secure SAP
environments in the cloud. Later in this document, we will focus on Azure Private DNS scenarios, rather
than on public Azure DNS.

Azure Private DNS provides three capabilities to operate and organize DNS resolution services within
Azure environment.

1. Azure provided DNS

2. Azure DNS private zones
3. Custom DNS

Let’s take a look at all those options.

Azure provided DNS

Upon creation of Azure VNet address space, the Azure provided DNS service is deployed by default for
every Azure VNet and provides only basic authoritative DNS capabilities which automatically manages
DNS zone names and records. In this scenario customers don’t have a control over the DNS zone names
and records. For more flexibility, e.g. bringing customers managed DNS zone and records, customers
should use either Azure private Zones or build up customer-managed DNS servers/services (custom
DNS), which are described in this chapter.
The diagram below shows how the VMs can talk to each other using a hostname or Azure provided
fully qualified domain name (FQDN) record.

3
 Name resolution withing a single VNet using Azure provided DNS

Features and Benefits:

• Simplicity in administration and management. Name resolution service with no deployment,
no configuration or no high-availability required.
• Azure auto generates fully qualified DNS names (FQDN) for the VMs within the VNet address
space.
o Virtual machines get a FQDN record from a zone *.internal.cloudapp.net. Example: VM
with a name/hostname vm-1 will have DNS name vm-1.internal.cloudapp.net
o Internal DNS server IP address within the VNet is always 168.63.129.16. It’s not
routable and can be reached only by the VMs belonging to the VNet
• Ability to use VM’s host names, rather than working with auto-generated names.
Example: vm-1 and vm-2 are deployed in a VNet, they have corresponding IP addresses
10.0.1.10 and 10.0.1.20. vm-1 can talk to vm-2 and vice versa by using a hostname (same a
VM name) or a FQDN record vm-2.internal.cloudapp.net.
Constraints & Limitations:

• Internal DNS service is restricted to support VMs deployed in Azure VNet address spaces
and is not capable of resolving entities outside of the Azure VNets.
• Azure provided DNS suffix (internal.cloudapp.net) cannot be modified
• Not possible to make any change or add, delete records
• WINS and NetBIOS are not supported.
In the light of the SAP deployments this approach fits fine for building up temporary SAP environments
like educational, training or sandbox systems, which don’t have to be integrated into the customers’
own network namespaces or just provide temporary access to new systems for evaluation purposes
(e.g. fast deployments using SAP Cloud Application Library). It’s a great out of the box solution with
zero maintenance and operations efforts.
More details about Azure provided DNS is available at this link Name resolution for resources in
Azure virtual networks | Microsoft Docs

Azure DNS private zones

This service provides a reliable, secure, more flexible, and comprehensive DNS resolution capabilities
for virtual networks. It’s a platform managed solution which could be configured for a virtual network
without a need of deploying custom DNS servers or using external providers. By using a custom domain
name, customers can design their virtual network architecture to meet their requirements.

4
As a first step, at least one Private DNS zone should be created, and a custom domain assigned to it
(e.g. contoso.com). Upon creation of a Private DNS zone more virtual networks could be linked with
the created private zone to resolve multiple domains.
While linking a VNet to a private zone, VM auto-registration could be enabled. This allows Azure to
automatically register and maintain VMs hostname records for the specified network. When a virtual
machine is created or deleted, Azure DNS will automatically create or erase the records within the
private zone.
Note: It is worthwhile to note that, while a virtual network can be linked to multiple zones for name
resolution purposes, there is a limitation to link a virtual network to only one private zone should the
VM auto- registration option is selected. This private zone becomes a registration zone for this virtual
network. However, a VNet could be linked to multiple zones for resolution purposes.
Below is a graphical representation of private zones to VNets relationship.

Private zones to VNet hierarchy

The following diagram exhibits a general overview of the name resolution process using Azure DNS
private zones, when the VMs are deployed within the same virtual network. When a VM needs to

5
resolve a name it sends a query to Azure DNS private zones service, if the requested name is registered,
DNS will respond to the VM an IP address of target VM.

Name resolution at a single VNet within a custom domain (contoso.com) using Azure private DNS

Because of Azure DNS private zones stretch across VNets, it allows to design name resolution service
for decentralized network patterns, like Hub-Spoke, using common domain name for all relevant
virtual networks. The next diagram showcases a scenario when two virtual networks are registered at
the same DNS private zone (contoso.com). Once VNet peering (or another connectivity) is established
the virtual machines can resolve names across virtual networks and communicate with each other
using fully qualified domain names from a custom domain. In fact, the name resolution would work
even without a need of VNet peering, however, a certain connectivity channels between virtual
networks allow the VMs to be linked up.

Name resolution across VNets within a custom domain (contoso.com) using Azure private DNS

Features & Benefits:

• Cloud platform provided DNS service

• No need to build, run and operate custom DNS servers (like BIND, AD Domain Services)
• DNS resolution spans across virtual networked that are linked for registration or resolution
with the private zone
• Custom domains and private IP spaces
• Supports all types of DNS records (A, AAAA, CNAME, MX, PTR, SOA, SRV, and TXT)

6
 • When a virtual network is linked with an Azure DNS private zone as a registration VNet, the
DNS lookup will return two records. One from a custom domain (e.g. vm.contoso.com) and the
other from an internal domain (e.g. vm.internal.cloudapp.com), which is coming by default
from Azure provided DNS service
Constraints & Limitations:
• Azure DNS limits are applied
• Conditional forwarding and zone transferring are not supported
• A VNet could be linked to only one zone for VM registration
• Reverse DNS works only for private IP space in the linked network
For SAP on Azure projects, Azure DNS private zones suites very well for the following scenarios and
gives tangible benefits:

• For customers who have a holistic and cloud-first approach of their IT strategy. This gives an
opportunity to leverage platform managed service for name resolution, at the same time
releasing the efforts of managing custom developed DNS solutions
• For customers who require certificate-based encryption and single sign on capabilities with
custom domain
• Non-disruptive native integration into existing enterprise landing zone, which follows the
concept of using Azure DNS private zones

Microsoft recommends all customers to share their current and future mode of operations via
Microsoft’s and partners’ conducted assessment workshops. Throughout those workshops, respective
experts ensure all aforementioned limitations are communicated before the deployments are
initiated. For example, if a customer’s landing zone architecture implies to have centralized custom
DNS servers within a Hub virtual network, which requires to use of conditional forwarding or zone
transfer capabilities.

More information available at What is Azure Private DNS? | Microsoft Docs

Azure custom DNS

When features and functions given by Azure DNS or Azure private zones cannot fulfil customers’
requirements for more complex DNS architecture, integration with customers networks (especially
talking about globally distributed networks and users), enhanced security capabilities (e.g DNSSEC),
then Azure provides an ability to use custom DNS server, which customers can build and run either
within Azure virtual network or leverage external 3rd party providers.
This is one of the examples on how to resolve Azure provided DNS records outside of Azure virtual
network using DNS forwarder VM deployed in each relevant VNet. This allows to reach out to the Azure
VMs by a FQDN with internal.cloudapp.net suffix. DNS forwarder is required, because Azure provided
DNS service is not routable outside of its virtual network.

7
 Resolving Azure provided FQDNs outside of Azure leveraging DNS forwarder VM

For any other capabilities like conditional forwarding, zone transfer (full transfer- AXFR or incremental
- IXFR) or DNSSEC (DNS security extensions), customers should build up or integrate with a custom DNS
infrastructure. From the virtual network configuration point of view, it’s only needed to specify IP
address of the DNS servers, which are serving the network. Those DNS’s IPs should be, of course,
routable, and accessible from the virtual network. The DNS provider could be any of solution that is
capable to do name resolution. For example (but not limited to):

• On-prem DNS infrastructure

• Linux BIND on Azure VMs
• Active Directory Domain Services on Azure VMs
• Azure Active Directory Domain Services
• Cloud-based DNS services (e.g. CloudFlare)

This diagram shows a simplified DNS integration scenario with existing on-premise DNS infrastructure.

On-premise DNS services integration with Azure custom DNS servers

8
Complex SAP deployments, integrated with existing on-premise infrastructure solutions, in most cases
will require custom DNS approach

For more recent updates and detailed information, please refer to Azure DNS documentation:

SAP on Azure. DNS integration scenarios

This chapter describes a few common scenarios of SAP application deployments on Microsoft Azure
cloud infrastructure with schemas, diagrams, and a description. It’s not intended to provide exhaustive
details and all possible options for running SAP environments and DNS integration capabilities. Despite
the existence of SAP on Azure best practices, most of the SAP deployments and customers’
requirements are unique, therefore some customer implementations could be using elements or
references of provided examples.

Scenario 1. SAP on Azure. Azure provided DNS and/or Azure private zones
In this scenario SAP systems are deployed in Azure Virtual Network, the VNet is linked with Azure
private zone into a domain *.sap.contoso.com. On-premises locations (central IT and offices) have
centralized DNS infrastructure (e.g. Active Directory Domain services, DNS server, BIND or another).
Customers’ DNS servers are using conditional forwarding for the following zones:
*.internal.cloudapp.net and *.sap.contoso.com to forward resolution request to DNS forwarder VM,
located in Azure VNet. This allows to resolve names of SAP services running in Azure by leveraging
Azure provided DNS and Azure private zones. Both DNS forwarder VM and SAP instance IPs must be
configured to be routable from the source originating clients located on customer premises.
For SAP systems to resolve on-premise resources, it’s necessary to maintain local DNS host files
(/etc/hosts or C:\Windows\System32\Drivers\etc\hosts) on the VMs or configure conditional
forwarding to on-prem DNS servers.

SAP on Azure using Azure provided DNS and/or Azure Private zones

Next diagram shows how to leverage Azure provided DNS and Azure private zones for SAP
deployments to have more control over communication between SAP systems, implement enhanced

9
security governance and billing management, by placing different workloads across several VNets
and/or subscriptions.

SAP on Azure using Azure provided DNS and/or Azure Private zones across VNets/Subscriptions

Scenario 2. SAP on Azure. Hub-spoke architecture

SAP landscapes are often segregated by workload purposes (Productive, Quality assurance,
Development, Training, Sandbox etc..), business areas/units and/or application types (S/4HANA, ERP,
CRM, EWM, CAR, BW/4HANA etc.). Hence, customers would like to leverage industry best practices in
organizing resources management, network isolation, and security governance. This is a more
comprehensive design for deploying resources in Azure by leveraging Hub-spoke network architecture
pattern. It’s a more scalable, granular, and secure way of architecting network and security
infrastructure in Azure.

SAP on Azure using Hub-spoke architecture with custom DNS

10
Design specifics:
• Hub VNet contains key networking and security services like Virtual network gateway
(ExpressRoute or VPN), Azure Bastion service (for VM access & administration), Azure
Application Gateway (L7 load balancer and web application firewall) and Azure Firewall or 3rd
party Network Virtual Appliance (NVA)
• Transitive routing between Spoke VNets via Azure Hub VNet using User-defined routes (UDRs)
• Spoke virtual networks are configured to use custom DNS service from the local network. The
IP addresses of the on-premise DNS servers are specified at the Spoke VNets level.

Scenario 3. SAP on Azure. Integration with SAP RISE/STE/HEC on Azure

SAP provides customers managed cloud services such as S/4HANA Cloud, private Edition, HANA
Enterprise Cloud/HEC or SAP’s business transformation offering - SAP RISE, significantly leveraging
Hyperscale cloud infrastructure to deploy, operate and run SAP estate in the cloud. For customer who
already leverage Microsoft Azure for any workloads, having SAP applications in Azure managed by SAP
within RISE, STE or HEC, is very logical, reasonable, and beneficial approach. Integration of customer-
owned networks with Cloud-based infrastructure and providing a seamless name resolution concept
is a vital part of a successful project implementation.
This diagram describes one of the common integration scenarios of SAP owned subscriptions, VNets
and DNS infrastructure with customer’s local network and DNS services. In this setup on-premise DNS
servers are holding all DNS entries and capable to resolve DNS requests coming from all sources (on-
premise clients, customer’s Azure services and SAP managed environments).

DNS integration between SAP RISE/STE/HEC on Azure and on-prem DNS

Design description and specifics:

• SAP RISE/STE/HEC on Azure is delivered to end customers from an SAP-owned Azure tenant.
This means that only SAP has a full control over the deployed resources such as subscriptions,
VNets, Resource groups, VMs and other Azure components and services that constitute SAP’s
managed cloud offerings
• Custom DNS configuration for SAP-owned VNets
• 2 VMs in the RISE/STE/HEC Azure VNet hosting DNS servers
• Customers must provide and delegate to SAP a subdomain/zone (e.g. *hec.contoso.com)
which will be used to assign names and create forward and revers DNS entries for the virtual

11
 machines that run SAP managed environment. SAP DNS servers are holding a master DNS role
for the delegated zone
• DNS zone transfer from SAP DNS server to customer’s DNS servers is the primary method to
replicate DNS entries from RISE/STE/HEC environment to on-premise DNS
• Customer-owned Azure VNets are also using custom DNS configuration referring to local on-
premise DNS servers.
• Optionally, customers can setup up a DNS forwarder within their Azure VNets to forward DNS
requests coming from Azure services to SAP DNS servers that are targeted to the delegated
zone (*hec.contoso.com).

Alternatively, DNS zone transfer from SAP DNS servers could be performed to a customer’s DNS
servers located in Azure Hub VNet (diagram below). This is applicable for the designs when
customers operate custom DNS solution (e.g. AD DS, BIND) within their Hub VNet.

Important to note, that neither Azure provided DNS nor Azure private zones does not support DNS
zone transfer capability, hence, cannot be used to accept DNS replication from SAP RISE/STE/HEC
DNS servers.

DNS integration between SAP RISE/STE/HEC on Azure, custom DNS in Hub VNet and on-prem DNS

Conclusion
Modern hybrid IT architecture requires deep analysis and planning in networking and security areas.
Especially for large enterprises, who operate globally. This complex environment may include
resources, distributed across the globe and different premises like customers‘ data centers, Hyperscale
clouds, managed service providers, edge locations (e.g. manufacture buildings, warehouses etc.) or
even vessels and other mobile places.
Azure DNS, like every other cloud service, is rapidly growing and being developed to enrich current
features with more state-of-the-art functionality. Therefore, it will get most of the functions that
customers demand to design and protect their environments, and in some cases could be capable to
replace commodity DNS services. We recommend each customer to consider Microsoft and Microsoft
partner enabled technical assessment sessions in which networking and security requirements are
thoroughly investigated to provide robust enterprise scale landing zones for their SAP workloads.
Thanks for reading and keep your eye on tracking Azure DNS service development.

12