search

dmauser / PrivateLink

Content and Labs on Azure Private Link
293 stars 75 forks source link

Solution #2 in section 4.1 may not work #6

Closed Vallentyne closed 3 years ago

Vallentyne commented 3 years ago

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 commented 3 years ago

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

Vallentyne commented 3 years ago

Windows

dmauser commented 3 years ago

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 commented 3 years ago

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.