Private Endpoints and Multi-Cloud DNS

In hybrid and multi-cloud environments, services often need to communicate privately across Azure and AWS. Ensuring that private endpoints resolve correctly requires a clear understanding of DNS, identity, and authentication.

This post explains how private DNS works in Azure and AWS, the role of conditional forwarding, and network requirements for accurate private endpoint resolution, using the domain bear.local as an example.

1. DNS Domains and Private Endpoints

Azure Private Link

• Private endpoints in Azure are exposed through Azure Private DNS zones (e.g., privatelink.*.windows.net).
• These zones are only resolvable via Azure DNS infrastructure or explicit DNS forwarding.

AWS PrivateLink

• AWS PrivateLink exposes endpoints through Route 53 Private Hosted Zones, attached to VPCs.
• These zones are resolvable only within associated VPCs or through Route 53 Resolver endpoints.

Key Point: There is no automatic cross-cloud DNS resolution. Azure private DNS cannot be resolved from AWS without explicit forwarding, and vice versa.

2. Identity vs Authentication

It is important to differentiate identity and authentication in multi-cloud scenarios:

• Identity: Represents who the user or service is. This can be managed in Microsoft (Azure/Entra) or AWS. Even if the same person or service exists in both platforms, each identity system is separate.
• Authentication: Verifies that identity. If your organization uses federation (e.g., ADFS or Azure AD Federation), authentication is handled by the federated service. Domain-joined devices in bear.local authenticate via this federated service, even if the identity originates in Microsoft or AWS.

Implications:

1. DNS resolution is independent of authentication. Resolving bear.local does not depend on how a user authenticates.
2. Identity informs access and authorization, but not DNS resolution.
3. Federated authentication ensures consistent login flows, even if identities exist in multiple cloud platforms.

3. Child Domains and Conditional Forwarding

There are two approaches for extending DNS across clouds:

Option A – Child Domain

• A child domain (e.g., aws.bear.local) could be created within bear.local.
• Only if client devices or servers need to join the child domain should this be considered, this would require direct authentication, also remember child domain must be synchronized with Entra (Azure AD) using Azure AD Connect.
• This is only required if devices or servers need to authenticate directly to the child domain.

Option B – Conditional Forwarding (Recommended)

• More commonly, a conditional forwarder is used for cross-cloud DNS resolution.
• A DNS server authoritative for bear.local can forward queries for aws.bear.local to the AWS Route 53 Resolver, and for Azure subzones to Azure DNS Private Resolver.
• The corresponding private DNS zones must exist in each cloud to resolve private endpoints.
• This approach does not require creating a child domain and separates DNS resolution from authentication.

4. DNS Traffic and Firewall Requirements

For DNS resolution to function correctly:

1. Client → DNS Server:

• UDP and TCP port 53 must be allowed from clients to the DNS server.
• UDP/53 handles normal queries; TCP/53 handles larger responses and zone transfers.

1. DNS Server → Cloud Resolver:

• Forwarded DNS queries are sent to the cloud resolver (Azure Private DNS or Route 53 Resolver).
• Both TCP and UDP port 53 must be allowed from the DNS server to the resolver.
• No additional firewall rules are needed between the client and the cloud resolver — only the DNS server hosting the forwarder requires access.

Proper forwarding ensures private endpoints resolve correctly. Misconfigured DNS or blocked ports may result in public IP resolution.

5. Multi-Cloud DNS Resolution Rules

1. Origin matters: DNS queries must originate from a server capable of reaching the cloud’s private DNS resolver.
2. Conditional forwarders are required: Each cloud’s private DNS zones must be reachable via forwarding paths.
3. No automatic cross-cloud resolution: Private endpoints in Azure cannot be resolved from AWS without explicit forwarding, and vice versa.

6. Best Practices and Considerations

6.1 DNS Caching

DNS queries may be cached at both client and server levels. Even with correctly configured conditional forwarders, stale cache entries can result in public resolution instead of private endpoints. It is recommended to set appropriate TTL values and clear caches when updating private DNS zones.

6.2 Redundancy and High Availability

Deploy multiple DNS servers with conditional forwarders in each cloud and on-premises to avoid single points of failure. This ensures that if one DNS server becomes unavailable, queries to private endpoints continue to resolve correctly.

6.3 Split-Horizon DNS

This setup creates split-horizon DNS, where the same domain (bear.local) may resolve differently depending on the source of the query (on-prem, Azure, or AWS). This behavior is normal in multi-cloud architectures and should be clearly documented to prevent operational confusion.

6.4 Security and Access Control

Only allow DNS traffic from authorized clients and servers. Conditional forwarders and cloud resolvers should remain within trusted networks and never exposed to the public internet. Monitoring DNS traffic for misconfigurations or unauthorized access helps maintain security.

6.5 Naming Conventions

Maintain consistent domain and subdomain naming for clarity and management simplicity. Examples include bear.localfor the primary forest, aws.bear.local for AWS-specific conditional forwarding, and azure.bear.local for Azure-specific zones. Consistent naming reduces errors and simplifies troubleshooting.

Conclusion

In multi-cloud environments, private endpoints in Azure and AWS are only resolvable within their respective clouds or through explicitly configured DNS forwarding paths. Identity and authentication are separate concerns: identity determines who the user or service is, and authentication, often federated through services like ADFS or Azure AD, verifies that identity. Creating child domains is only necessary if devices or servers require direct domain-joined authentication, whereas conditional forwarding provides a straightforward way to resolve private DNS zones across clouds without additional domain infrastructure.

Properly allowing TCP and UDP traffic on port 53 between DNS servers and cloud resolvers is essential to ensure queries reach the correct endpoints. Without accurate DNS paths and forwarding, clients may fall back to public DNS resolution, potentially exposing private endpoints to the public network. 

By carefully configuring DNS resolution, organizations can maintain secure and reliable connectivity to private endpoints in a multi-cloud environment.