Private endpoint DNS: keep the service hostname and prove the resolver path
A private IP in a portal blade is only one part of the connection. Trace the hostname from the workload to the linked private zone.
0 reputation · 2h ago
A private IP in a portal blade is only one part of the connection. Trace the hostname from the workload to the linked private zone.
0 reputation · 2h ago
A private endpoint can exist and still be unused by an application. The application connects to a hostname, and DNS decides which address it receives. Treat the endpoint, zone records, VNet links and resolver forwarding rules as one path. Changing the application to a private IP hides the broken part of that path and creates another configuration to maintain.
Record the exact service hostname from application configuration. Resolve it inside the affected workload environment and compare the result with a machine in a network known to have access. For Azure Blob Storage, keep the normal account.blob.core.windows.net hostname. Azure’s DNS chain can lead to a private address when the appropriate private zone is visible. The application should not replace the service hostname with a privatelink hostname.
A public result from outside the VNet is not automatically wrong. Split DNS intentionally permits different answers for different network contexts. The useful question is whether the production workload sees the intended private address and has a route to it.
Verify that the private zone contains the record corresponding to the endpoint and that the necessary VNet link exists. With custom DNS, check the conditional forwarding path and where Azure’s private-zone resolution occurs. A VNet link alone does not force an arbitrary custom DNS server to consult that zone.
Record the resolver address as well as the answer. If two machines receive different answers, compare their DNS configuration, network placement and cache state before editing records. Repeat the lookup after the relevant TTL or a controlled local cache refresh. Do not remove unrelated zone records while diagnosing one service.
Once the name resolves privately, test the required service port from the workload. Then inspect the service response. A timeout suggests a different layer from a clear authorization failure. Storage data-plane roles, network rules and the choice of storage subresource still matter. A blob endpoint does not automatically provide private access to every other storage service.
Validate the completed change with a real, minimal application operation using its runtime identity. Keep TLS hostname verification enabled. Document both the DNS result and service result so a future operator can tell a resolver regression from a permission regression.
1,100 reputation · 2h ago
It can conceal the forwarding or zone-link problem and will not track endpoint changes. Keep the supported hostname, repair the resolver path and remove any temporary override after verification.