Answers: <p>So it seems my problem was based on a false premise that the Azure Private DNS Zone to link to a Private Endpoint for App Services which use Unique Default Hostnames had to be one of:</p>
  <ul>
  <li><code>&lt;region&gt;.privatelink.azurewebsites.net</code></li>
  <li><code>privatelink.&lt;region&gt;.azurewebsites.net</code></li>
  </ul>
  <p>when what's actually needed is the <em>same</em> Azure Private DNS Zone as for app services that <strong>don't</strong> use Unique Default Hostnames - i.e.:</p>
  <ul>
  <li><code>privatelink.azurewebsites.net</code></li>
  </ul>
  <p>What happens then is 2 records get automatically registered in the Azure Private DNS Zone:</p>
  <div class="s-table-container"><table class="s-table">
  <thead>
  <tr>
  <th>Name</th>
  <th>Type</th>
  <th>Value</th>
  </tr>
  </thead>
  <tbody>
  <tr>
  <td>mywebapp-&lt;hash&gt;.&lt;region&gt;</td>
  <td>A</td>
  <td>&lt;private endpoint ip&gt;</td>
  </tr>
  <tr>
  <td>mywebapp-&lt;hash&gt;.scm.&lt;region&gt;</td>
  <td>A</td>
  <td>&lt;private endpoint ip&gt;</td>
  </tr>
  </tbody>
  </table></div>
  <p>And this zone then resolves the fqdn</p>
  <ul>
  <li><code>mywebapp-&lt;hash&gt;.&lt;region&gt;.privatelink.azurewebsites.net</code></li>
  </ul>
  <p>and everything just works.</p>
  <p>I've submitted a PR to the azure docs repo to add specific information about DNS configuration for app services that use Unique Default Hostnames to help anyone else who might otherwise fall down the same rabbit-hole as I did...</p>
  <p><a href="https://github.com/MicrosoftDocs/azure-docs/pull/124485" rel="nofollow noreferrer">https://github.com/MicrosoftDocs/azure-docs/pull/124485</a></p>
  
Answers: CC BY-SA 4.0
Answers: 2024-09-23T18:40:56.183Z
Answers: 2024-09-23T18:48:40.137Z
Answers: 2024-09-23T18:48:40.137Z
Answers: mclayton
Body: <p>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, <em>but</em> this is the first App Service we've provisioned with Private Link that uses the new(ish) &quot;<strong>Unique Default Hostnames</strong>&quot; feature:</p>
  <p><a href="https://techcommunity.microsoft.com/t5/apps-on-azure-blog/public-preview-creating-web-app-with-a-unique-default-hostname/ba-p/4156353" rel="nofollow noreferrer">https://techcommunity.microsoft.com/t5/apps-on-azure-blog/public-preview-creating-web-app-with-a-unique-default-hostname/ba-p/4156353</a></p>
  <p>(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)</p>
  <p>The short version of the problem is that doing an nslookup of our web app's default hostname <strong>looks</strong> like it's giving an incorrect CNAME:</p>
  <pre><code>C:\&gt; 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:
      -&gt;  myapp-xxxxxxxxxxxxxxxx.northeurope-01.azurewebsites.net
          canonical name = myapp-xxxxxxxxxxxxxxxx.northeurope-01.privatelink.azurewebsites.net
          ttl = 60 (1 min)
  </code></pre>
  <p>Note <code>myapp-xxxxxxxxxxxxxxxx.northeurope-01.azurewebsites.net</code> is the <strong>default</strong> Azure-assigned domain name - the App Service is called <code>myapp</code> in the portal and the <code>-xxxxxxxxxxxxxxxx</code> suffix is generated by the &quot;Unique Default Hostnames&quot; feature, as is the <code>northeurope-01</code> domain part.</p>
  <p>What I'm suspicious about is the CNAME value <code>myapp-xxxxxxxxxxxxxxxx.northeurope-01.privatelink.azurewebsites.net</code> - it looks to me like the <code>northeurope-01</code> and <code>privatelink</code> are the wrong way round, which means the name cannot be resolved.</p>
  <p>If I manually perform an nslookup on <code>myapp-xxxxxxxxxxxxxxxx.privatelink.northeurope-01.azurewebsites.net</code> (with the <code>privatelink</code> and <code>northeurope-01</code> 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.</p>
  <p>Is this a bug in Azure where the CNAME is being generated incorrectly?</p>
  <p>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 <em>could</em> be an issue in our environment somewhere I've not been able to track down, <em>but</em> 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 &quot;Unique Default Hostnames&quot;...</p>
  
Tags: <azure>
Title: Using Azure Private Link with an App Service that uses a "Unique Default Hostname" returns wrong CNAME?
UserDisplayName: mclayton
ThreadText: # Using Azure Private Link with an App Service that uses a "Unique Default Hostname" returns wrong CNAME?
  
  (Asked by: username_0 on 2024-09-11)
  
  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:
  
  <https://techcommunity.microsoft.com/t5/apps-on-azure-blog/public-preview-creating-web-app-with-a-unique-default-hostname/ba-p/4156353>
  
  (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"...
  
  **Tags:** azure
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2024-09-23. Score: 0 | Accepted answer
  
  So it seems my problem was based on a false premise that the Azure Private DNS Zone to link to a Private Endpoint for App Services which use Unique Default Hostnames had to be one of:
  
  * `<region>.privatelink.azurewebsites.net`
  * `privatelink.<region>.azurewebsites.net`
  
  when what's actually needed is the *same* Azure Private DNS Zone as for app services that **don't** use Unique Default Hostnames - i.e.:
  
  * `privatelink.azurewebsites.net`
  
  What happens then is 2 records get automatically registered in the Azure Private DNS Zone:
  
  | Name | Type | Value |
  | --- | --- | --- |
  | mywebapp-<hash>.<region> | A | <private endpoint ip> |
  | mywebapp-<hash>.scm.<region> | A | <private endpoint ip> |
  
  And this zone then resolves the fqdn
  
  * `mywebapp-<hash>.<region>.privatelink.azurewebsites.net`
  
  and everything just works.
  
  I've submitted a PR to the azure docs repo to add specific information about DNS configuration for app services that use Unique Default Hostnames to help anyone else who might otherwise fall down the same rabbit-hole as I did...
  
  <https://github.com/MicrosoftDocs/azure-docs/pull/124485>
  
  
  ---
  
  