A private endpoint works from inside the VNet but on-prem users still hit the public IP. Why, and how do you fix it?

Azure example

mystore.blob.core.windows.net
  CNAME mystore.privatelink.blob.core.windows.net
    inside a VNet linked to privatelink.blob.core.windows.net  -> A 10.50.2.4
    anywhere else (public DNS)                                 -> public IP

1. Create the private DNS zone privatelink.blob.core.windows.net, link it to the hub VNet, and let the private endpoint register its record there.
2. Deploy Azure DNS Private Resolver with an inbound endpoint in the hub (or a DNS forwarder VM that uses 168.63.129.16).
3. On-prem DNS: conditional forwarder for blob.core.windows.net to the inbound endpoint IP. Microsoft recommends forwarding the public zone name, not the privatelink name, so the CNAME chain is followed inside Azure.

168.63.129.16 itself is only reachable from inside Azure, which is why on-prem cannot forward to it directly.

AWS equivalent

An interface endpoint with private DNS creates a hidden private hosted zone for the service name in that VPC. On-prem forwards the service domain to a Route 53 Resolver inbound endpoint. For endpoints shared from a central VPC, turn private DNS off on the endpoint, create your own private hosted zone for the service name with an alias to the endpoint, and associate that zone with every spoke VPC.

Design rule

One private DNS zone per privatelink name for the whole organisation, linked to the VNets or VPCs that need it. Duplicate zones in different hubs give different answers depending on where you ask.