Domain Name System (DNS) planning is critical for any cloud environment, and it is important for management and compute workloads in VMware Cloud on AWS to function properly. The article discusses some of the DNS strategies for VMware Cloud on AWS and considerations.
DNS Configuration in VMware Cloud on AWS
Let us first discuss the DNS configuration aspects, before looking at the topologies. To get started with the DNS configuration, refer the operations guide on how to Create a Logical network and Configure DNS for management & workload VMs. Google DNS servers are set up initially when the SDDC is first deployed.
Important NSX-T Tier 1 Gateways (MGW and CGW) in VMware Cloud on AWS only act as forwarders, relaying the queries from VMs to the actual DNS servers specified. The devices also cache the responses, thus improving performance.
DNS servers configured under the Management Gateway (MGW) DNS Forwarder will be used by the management components such as vCenter to resolve the on-prem FQDNs. Features such as HLM or Site Recovery may not work until customer managed DNS servers are configured here, as the management VMs using Google DNS by default cannot resolve the on-prem resources.
There are three ways to setup IP addresses for the workloads –
- Inbuilt NSX DHCP Server
- Customer managed DHCP server (Directly or via NSX DHCP Relay Feature)
- Static
DNS servers configured under Compute Gateway (CGW) DNS Forwarder are used by the workload VMs connected to the inbuilt NSX DHCP enabled segments. As shown below, DHCP can be enabled for logical networks. VMs attached to such networks can become DHCP clients and receive IPs from the NSX Edge.
An alternative to the inbuilt DHCP is the customer managed DHCP server, in which case the DHCP options including the DNS IPs are handed out by the latter.
DNS can also be set directly in the compute virtual machines statically, in which case the DNS IPs configured in the portal will not be used. On the other hand, the DHCP Client VMs attached to the segments using the inbuilt DHCP server will always send the DNS queries to the CGW, leveraging the DNS IPs configured in the portal.
DNS Service IP address
The MGW & CGW Tier 1 Gateways listen for the DNS queries on the DNS Service IP shown in the DNS page. The DHCP workloads display this Service IP as the DNS server, and not the actual DNS IPs configured in the portal. If so desired, the DNS Service IP can also be configured as the DNS server in the VMs with Static IP. The VMs will then send the queries to NSX Edge Gateway, which then forwards on to the DNS IPs configured in the portal. This method might be used for uniformity and to keep cloud DNS management in a single pane for both DHCP and static workloads.
Internal only DNS
The DNS Servers fields in the VMware Cloud on AWS portal will not accept mixed mode of private and public DNS. This is because both the DNS servers are used for the name resolution and it is expected both the servers can resolve the target domain names uniformly. A probable reason a user might look to configure this is to work with the internet in addition to the private domain names. A better approach for this would be to configure external DNS servers capable of resolving public domains as forwarders in the internal only DNS server.
Let us now look at some of the DNS topologies.
1. On-Prem DNS servers
In this configuration DNS servers would reside on-prem, servicing the virtual machines in VMware Cloud on AWS SDDC remotely over IPsec VPN or Direct Connect. This setup might be suitable for a customer with an existing on-prem DNS infrastructure and can get started quickly by leveraging it. Since the VMs must send DNS queries back to on-prem, the configuration is dependent on the network connectivity.
Requirements
- IPsec VPN or Direct Connect (Private VIF) to on-prem or a remote environment such as Colo; Subnet with DNS server allowed or advertised over VPN or Direct Connect
- Both VMware Cloud on AWS (for static configuration) and On-Prem Firewall must allow DNS traffic (UDP/53 & TCP/53). DNS forwarder IP is automatically allowed for DNS queries in an auto-plumbed rule.
- Both primary and secondary DNS servers should be reachable and provide consistent results
Configuration
DNS servers are configured in VMware Cloud on AWS portal under Networking & Security > DNS section as explained initially.
Including the interface IP in the Policy VPN
In the case of CGW, if the DNS servers are only reachable over the Policy based IPsec VPN, the DNS Service IP (named ‘CGW DNS Network’) should be included in both ends of the tunnel as mentioned in the instructions. This is required for workloads using the listener IP as the DNS so that the DNS queries can be forwarded to the remote DNS servers without getting dropped by IPsec. This requirement is not needed for static IP configuration.
2. Local DNS servers
In this model DNS servers would reside in one of the logical networks, in compute segment of the VMware Cloud on AWS SDDC. This approach may need additional servers in the cloud SDDC but could avoid DNS traffic back and forth to on-prem. The proximal DNS servers can also provide reliable name resolution by not depending on the vagaries of the network connection.
Requirements
- IPsec VPN or Direct Connect (Private VIF) to on-prem, subnet with DNS server allowed or advertised over VPN or Direct Connect (Optional - only if syncing with on-prem AD/DNS)
- On-Prem Firewall allowing DNS traffic (Optional - only if syncing with on-prem AD/DNS)
- Management Gateway must allow DNS traffic (UDP/53 & TCP/53) for management workloads to communicate with the DNS in the compute segment
- Both primary and secondary DNS servers should be reachable and provide consistent results
Configuration
DNS servers will be configured in the same manner as previous in the VMware Cloud on AWS portal. The management and compute segments can communicate directly without any additional routing configuration. There are two possible models in this topology:
- Local DNS server not connected elsewhere
- DNS server syncing with on-prem AD/DNS infrastructure
If there is an AD/DNS infrastructure on-prem, placing local AD/DNS servers in the SDDC could be a preferred method for increased availability and performance since workloads are catered locally.
3. DNS server in AWS
Users can also leverage DNS servers in AWS. This could be in the form of EC2 instance or Amazon DNS services. This type is useful if the Amazon DNS infrastructure is already being used. This can also be used if on-prem DNS is not available and the user does not want to manage DNS servers in the SDDC.
Requirements
- EC2 instance or AWS DNS server IP residing in a connected VPC as described here to take advantage of Cross-VPC connectivity
- IPsec VPN or connectivity through Direct Connect is required if the DNS instances are in a remote VPC
- VMware Cloud on AWS Firewall and AWS Security group / Network ACLs allowing DNS traffic
Configuration
The IP address of the EC2 instances running in the AWS VPC can be configured as DNS IPs in the VMware Cloud on AWS portal. The IPs can also be configured directly in the virtual machines statically. The Edge can forward the queries to the DNS servers over Cross-ENI.
Route53
The SDDC VMs can leverage both the Private and Public hosted zones of Route53. For the private zones associated with the linked VPC, the VPC DNS IP (IP address at the base of the VPC network range "plus two" or second IP of the VPC subnet) can be configured in the VMware Cloud on AWS portal if found suitable for the use cases. Refer the link for Private zones considerations. For more control and flexibility, DNS strategies described in the AWS documentation for an on-prem environment can be followed for VMC as well. For example, this blog post explains setting up unified name resolution using Unbound.
For the Public zones, the nameservers are listed under Route53 > Hosted Zones > Name Servers section. The VMware Cloud on AWS portal only accepts valid IPs, so get the IP addresses of these name servers using simple tools such as dig and nslookup. According to AWS these IP addresses rarely change.
If the AWS Directory services are used for the SDDC workloads, the DNS IPs provided by these services can also be used. Confirm the reachability of the DNS IPs before configuring them in the VMware Cloud on AWS portal or in the workloads. For example, Microsoft AD services deploy DNS servers in two different AZs for high availability, but both should be reachable over Cross-ENI (if linked VPC is used) with the firewall, security group and routing configured correctly.
The article focuses on DNS, but the deployment models can also be considered for other systems such as Windows Active Directory.
