On-prem systems can't resolve cloud names and vice versa
Route 53 Resolver, Azure Private DNS Resolver, and Cloud DNS managed zones with inbound/outbound forwarders are the right layer. Every cloud has it, naming differs.
Try this first
- 1AWS: Route 53 Resolver with inbound endpoint (on-prem -> AWS), outbound endpoint (AWS -> on-prem) plus forwarding rules per domain.
- 2Azure: Azure Private DNS Resolver with inbound and outbound endpoints. Combine with Private DNS zones for cloud services.
- 3GCP: Cloud DNS Inbound DNS forwarding for on-prem -> GCP, Outbound forwarding via Cloud DNS managed zone forwarding rules.
- 4Configure over your VPN or Direct Connect / ExpressRoute / Interconnect, not over public internet. DNS over public internet is a security mistake.
- 5Test bidirectional: nslookup from on-prem to cloud resource and the other way. Don't forget reverse lookup if you want SSH by name.
When to bring us in
For a hybrid setup with multiple on-prem locations, conditional forwarding and split-DNS, this really is a network-architect job. Half-done is worse than undone here.
See also
- Everyone logs in with the AWS root accountRoot is for emergencies and billing. Day-to-day work belongs in IAM users or SSO.
- Every developer has AdministratorAccessAdministratorAccess everywhere is convenient now, painful later. Start with role-based policies.
- Everyone has individual IAM users with their own passwordIdentity Center (formerly AWS SSO) links to your IdP and issues temporary credentials per session.
None of the above fits?
Describe your situation below. We pass your input plus the steps you already saw to our AI and return tailored next-step advice. If it's too risky to DIY, we'll say so.
Or skip the DIY entirely
Our Managed IT clients do not look these things up. One point of contact, a fixed monthly price, resolved within working hours.