Why does a VM still resolve a storage account publicly after a private endpoint was added?

A storage private endpoint and its DNS record exist. A VM in a connected network still resolves the ordinary blob hostname to a public address. The VM uses a custom DNS server, while another VM using the intended Azure resolver gets a private address. The application configuration has not changed. Which part of the DNS chain should be investigated?

Start with the custom resolver path. A private zone and VNet link do not make every custom DNS server consult that zone automatically. Compare the queried resolver, forwarding rules and the network where Azure private-zone resolution happens. Check the applicable private-zone link and record as well.

Keep the ordinary storage hostname in the application. Do not replace it with an IP or a privatelink hostname. After repairing the forwarding path, repeat the lookup from the failing VM and then perform an authorized blob operation with the runtime identity. The example is solved when both private resolution and service access are demonstrated.

The DNS server has cached the public answer. Should I delete the private zone and recreate it?

No. Confirm the forwarding configuration first and account for the cached record TTL. Recreating a correct zone adds disruption without addressing the resolver that supplied the answer.

A private DNS result is only one checkpoint. If the next result is an authorization error, investigate storage data permissions independently instead of changing the DNS configuration again.

Why does a VM still resolve a storage account publicly after a private endpoint was added?

Sources & further reading

2 answers

Your perspective belongs here.

0 question comments