Contoso Retail has a hybrid network: a campus on-premises network connected to an Azure hub VNet via an ExpressRoute private peering. Network team must allow on-premises DNS clients to resolve Azure Private DNS zones (for private endpoints and custom private zones) without opening DNS to the internet. They want to use Azure Private DNS Resolver. Which configuration achieves inbound resolution of on-premises queries into Azure DNS using the Private DNS Resolver?

The Azure Private DNS Resolver's inbound endpoint is designed for this scenario. It provides a private IP address within a specified Azure VNet (in this case, the hub VNet) that on-premises DNS servers can use as a conditional forwarder. Queries from on-premises clients are then forwarded over the ExpressRoute private peering to this private IP, allowing the Private DNS Resolver to resolve Azure Private DNS zones. The incorrect options are: Deploying an inbound endpoint with a public IP is unnecessary and less secure, as ExpressRoute private peering provides a private connection. Creating an Azure DNS private zone alone doesn't provide a mechanism for on-premises clients to query it directly; a resolver or forwarder is needed. Conditional forwarding from on-premises to the hub VNet using a Site-to-Site connection is not the primary mechanism for Private DNS Resolver and ExpressRoute. Deploying a Linux BIND VM is a manual, less scalable, and more complex solution compared to the managed Azure Private DNS Resolver. Publishing its public IP is incorrect for an ExpressRoute private peering scenario.