I'm trying to set up a Private Endpoint on an Azure App Service to connect it to an Azure Virtual Network in the same subscription - I'm pretty sure it's all set up correctly based on other Private Links that we have working fine in our environment, but this is the first App Service we've provisioned with Private Link that uses the new(ish) "Unique Default Hostnames" feature:
(Basically, the default hostname for the app service has a system-generated hash appended so the same fqdn can't be land-grabbed by an attacker after you've deleted the service because they'd get a different hash on their default domain)
The short version of the problem is that doing an nslookup of our web app's default hostname looks like it's giving an incorrect CNAME:
C:\> nslookup -debug myapp-xxxxxxxxxxxxxxxx.northeurope-01.azurewebsites.net. ... snip ... ------------ Got answer: HEADER: opcode = QUERY, id = 2, rcode = NOERROR header flags: response, want recursion, recursion avail. questions = 1, answers = 1, authority records = 0, additional = 0 QUESTIONS: myapp-xxxxxxxxxxxxxxxx.northeurope-01.azurewebsites.net, type = A, class = IN ANSWERS: -> myapp-xxxxxxxxxxxxxxxx.northeurope-01.azurewebsites.net canonical name = myapp-xxxxxxxxxxxxxxxx.northeurope-01.privatelink.azurewebsites.net ttl = 60 (1 min) Note myapp-xxxxxxxxxxxxxxxx.northeurope-01.azurewebsites.net is the default Azure-assigned domain name - the App Service is called myapp in the portal and the -xxxxxxxxxxxxxxxx suffix is generated by the "Unique Default Hostnames" feature, as is the northeurope-01 domain part.
What I'm suspicious about is the CNAME value myapp-xxxxxxxxxxxxxxxx.northeurope-01.privatelink.azurewebsites.net - it looks to me like the northeurope-01 and privatelink are the wrong way round, which means the name cannot be resolved.
If I manually perform an nslookup on myapp-xxxxxxxxxxxxxxxx.privatelink.northeurope-01.azurewebsites.net (with the privatelink and northeurope-01 in the same order as other resource types use) it resolves to the correct address, so I'm pretty sure my environment is set up correctly.
Is this a bug in Azure where the CNAME is being generated incorrectly?
I can provide more details of our network / dns environment if that helps - it's pretty complicated (including custom dns servers, azure resolvers, private dns zones and conditional forwarders) so there could be an issue in our environment somewhere I've not been able to track down, but I'm wondering primarily if this can be reproduced elsewhere and / or whether it's a known issue with Private Link and App Services that use "Unique Default Hostnames"...
