Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
cancel
Showing results for 
Search instead for 
Did you mean: 
mark_ma
Product and Topic Expert
Product and Topic Expert
updated date: 22.Mar.2023

DNS plays the ‘phone book’ role in the internet world. As multi-cloud setup has become more and more prevalent for enterprise customers. The Integration of customer-owned on-premise networks with cloud-based infrastructures to provide a seamless domain name resolution experience is vital to customers’ enterprise landscapes.

This blog targets on guide for AWS

Link to guide for Azure: here

Link to guide for GCP: here

Problem Description


In this article, we are addressing such scenarios, where SAP RISE PCE customers have their SAP workloads hosted on SAP managed cloud environment (on Azure, AWS, GCP, or SAP Data Center), while might also have one or both of: their own on-premise data centers, and their own hyperscalers (Azure, AWS, or GCP) subscription. And each network environment has its own DNS setup. Chaos might occur if domain names or IP ranges were not properly routed.

Thereby, we are proposing a reference architecture for such scenarios to resolve DNS requests coming from all sources (SAP RISE PCE managed environments, on-premise data center DNS servers, and customer’s own hyperscalers DNS services), with disaster recovery been considered.



Terminologies and Abbraviations


DNS: short for Domain Name System. It translates between domain names (like *.ecs.sap.com) and IP addresses (like 192.168.1.1 in IPv4, 2400:cb00:2048:1::c629:d7a2 in IPv6) in both ways.

DNS Zone Transfer: [SAP RISE PCE preferred] one of the mechanisms to replicate DNS databases across a set of DNS servers. SAP RISE PCE recommends this because of: its high availability; it provides redundancy and higher SLA, especially for DR scenarios; it can establish reliable status monitoring. The disadvantage is: DNS Notifiers should be in place to ensure the full DNS TTL Delay.

DNS Conditional Forward (or so-called ‘IP Forward’): DNS servers that only forward queries for specific domain names. The advantage is, if no outbound traffic from SAP RISE PCE is necessary, customers do not have to configure their own DNS for their inbound traffic. The disadvantages are: customer OP DNS may suffer delay due to forward cache (but configurable); also due to forward cache, failover could take more time; limited status monitoring.

Zone Delegation: a process of assigning authority over a domain or subdomain to different DNS servers to keep records updated. The advantage is: customers can manage OP DNS through SAP RISE PCE as a single point. The disadvantages are: configuration is onerous.

Consensus / Prerequisites



  • Only server-side DNS servers are been considered in this reference architecture, client-side DNS (if any) are not been addressed here

  • Disaster recovery on customer’s data center is not been considered

  • Network connections for pairing virtual networks or connecting on-premise networks with the cloud (like VPC peering, VNet peering, VPN, .etc), and other network components (like load balancer, .etc.) are not been addressed in this reference architecture. Separate reference architectures will be created in later blog series.

  • SAP RISE PCE DNS servers are seen as resources.

  • DNS services on customer’s own hyperscalers are seen as services, and customers should ensure HA/DR been enabled on service level

  • In DR cases, we call it by zone, instead of region, since RISE customers can may deploy SDDR (different zones within the same region), or LDDR (in different regions)

  • In SDDR, a virtualized DNS server deployed within each zone. In LDDR, a virtualized DNS server cluster (contains 2 DNS servers for HA) deployed within each zone. There are SAP tools doing syncronization in between DNS servers (clusters).

  • The offerings by hyperscalers (Azure, AWS, and GCP) are based on the services’ general availability of hyperscalers providers’ (Microsoft, Amazon, and Google) official documentation online, as of this blog’s publishing date of time The offerings by SAP RISE PCE are based on SAP ECS service guidance as of this blog’s publishing date of time


Architecture Design























customer’s AWS subscription



DNS zone transfer

(RISE PCE preferred)


  • AWS DNS is a server (cluster) deployed on AWS EC2 (see Fig. 1 and Fig. 2)


DNS conditional forward

  • Route53 resolver based on Route53 is used to integrate DNS from another peered VPC (eg. RISE DNS on SAP-managed AWS VPC), OP network that is connected to AWS with AWS Direct Connect, a VPN, or a network address translation (NAT) gateway. See Fig. 3 and Fig. 4.

  • dedicated inbound endpoint and outbound endpoint are been deployed to connect each peered VPC or connected OP network

  • IP forward is applied to do information exchange with RISE DNS and OP DNS

  • in DR case, Route53 setup is shared by 2 VPCs from main zone and DR zone

  • In DR case, Route53 can be used to configure DR mechanism



SAP RISE PCE subscription



  • RISE DNS (cluster) is been deployed within the same virtual private cloud as SAP-managed VMs

  • RISE DNS shares information with OP DNS through DNS zone transfer

  • In DR case, a DNS (cluster) is deployed in each zone, the 2 DNS (clusters) share the same information with SAP tool in sync



customer’s data center



  • OP DNS can optionally share some information with RISE DNS through DNS conditional forward




Fig. 1: Reference architecture for DNS integration when customer’s AWS DNS is server on AWS



Fig. 2: Reference architecture for DNS integration with DR considered when customer’s AWS DNS is server on AWS



Fig. 3: Reference architecture for DNS integration when customer’s AWS DNS is AWS service



Fig. 4 Reference architecture for DNS integration with DR considered when customer’s AWS DNS is AWS service



Disclaimer



  • SAP takes no responsibility for managing and operating customers’ own data center, nor for customers’ own hyperscaler subscription

  • RISE customers should provide corresponding DNS information, with regard to SAP ECS guidance

  • RISE customers should be aware of the pros and cons of the selected DNS integration approach


Acknowledgment to contributors/reviewers/advisors:


Ke Ma (a.k.a. Mark), Senior Consultant, SAP IES AI CoE / RISE Cloud Advisory RA group

Kevin Flanagan, Head of Cloud Architecture & Advisory, RISE Cloud Advisory, EMEA North

Richard Traut, Cloud Architect & Advisor, RISE Cloud Advisory

Darrell Lee, Cloud Architect & Advisor, RISE Cloud Advisory

Luc DUCOIN, Cloud Architect & Advisor, RISE Cloud Advisory

Sven Bedorf, Head of Cloud Architecture & Advisory, RISE Cloud Advisory, MEE

Jyothi Prakash Lakshmi, Network Engineer, SAP ECS

Frank Gong, Digital Customer Engagement Manager, SAP ECS




Marcelo Morais, Cloud Architect & Advisor, RISE Cloud Advisory
Extended Reading:
Join our RISE with SAP community here