Solution #2 in section 4.1 may not work

[Vallentyne]

In my testing, using an FQDN name for the conditional forwarding on premises required to use the privatelink name, not the real FQDN. In my testing this configuration (conditional forwarding set to real FQDN, which forwarded to custom DNS server in Azure) got the correct private response the first time, and then the public address every query after. If the privatelink name is used for the conditional forwarder, then every query works as intended.

[dmauser]

Thanks for your insights. Question: which DNS Server are you using? Windows or Bind?

[Vallentyne]

Windows

[dmauser]

Do you have your if Windows DNS using Forwarders or RootHints?
The reason I am asking this is because there's some considerations. In your case privatelink FQDN will technically work only when you use RootHints but not using Forwarders. See: https://github.com/dmauser/PrivateLink/tree/master/DNS-Integration-Scenarios#41-which-conditional-forwarder-zone-should-be-used
The only possibility to conditional forwarder to privatelink.core.blob.windows.net work is if DNS A on the picture above does direct external resolution to Internet Root Hints, it will be able directly to get privatelink CNAME and able to process the local conditional forwarder.

[Vallentyne]

Ah ok, I see that distinction now. Thanks for the clarification, that makes sense. So, external non-Azure lookups for this scenario would actually require an upstream DNS that could do regular name resolution, assuming the primary DNS server did not use Root Hints.