Best practice for Online workload private DNS resolution #1970
-
|
For workloads under the Online archetype and subscription vending line. What is the best practice for handling centralized private DNS resolution with private DNS zones and a DNS private resolver in the hub. I believe the idea of the Online archetype is for it to be isolated from the hub. To reduce the exposure. However Is it acceptable to hoist the policy for automatically deploying DNS zone groups up to the landing zone management group from the corp one? Then allow connectivity to the hub purely for DNS resolution and block all other traffic with NSG etc. Or is it more typical for workloads in the online archetype to use there own local private DNS zones. In that case I suppose the best practice for interacting with resources such as storage, sql on the off cases they need direct access from a human is via Bastian / jump box. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
Hey @jamie-oconnell, as you say typically online is an isolated island from all other vNets outside of the workload. So to handle DNS resolution we'd typically promote the online workload having its own private DNS zones for the zones it needs and then creating Private Endpoints to access the services in other workloads it needs. Ive also seen this pattern used to access a set of DNS servers in the hub for DNS resolution back to on premise and attaching a private endpoint to the LB, to avoid vNet peering and to enhance security. Hope that helps |
Beta Was this translation helpful? Give feedback.
Hey @jamie-oconnell, as you say typically online is an isolated island from all other vNets outside of the workload.
So to handle DNS resolution we'd typically promote the online workload having its own private DNS zones for the zones it needs and then creating Private Endpoints to access the services in other workloads it needs.
Ive also seen this pattern used to access a set of DNS servers in the hub for DNS resolution back to on premise and attaching a private endpoint to the LB, to avoid vNet peering and to enhance security.
Hope that helps