The official solution is documented here: MS Docs: Create ILB ASE - DNS Configuration

You need to have DNS entries for your ASE so that the deployment task can reach it; but if you have an internal only ASE, those entries aren't created in public DNS, and MS don't manage private DNS.

MS propose creating the DNS entries in your internal DNS:

Create Zone {ASE Name}.appserviceenvironment.net

• Type: Primary Zone
• Store the zone in AD: True
• Zone Replication: To all DNS servers in the domain
• Zone Name: {ASE Name}.appserviceenvironment.net
• Allow only secure updates: true

Create A Record under {ASE Name}.appserviceenvironment.net

• Name: *
• IP: {ASE's Private IP}

Create A Record under {ASE Name}.appserviceenvironment.net

• Name: *
• IP: {ASE's Private IP}

Create Child Zone under {ASE Name}.appserviceenvironment.net

• Name: scm

Create A Record under scm.{ASE Name}.appserviceenvironment.net

• Name: *
• IP: {ASE's Private IP}

However, whilst awaiting the DNS creation I tried a workaround which turned out to be sufficient... it's a hack, but in some ways feels cleaner than impacting the organisation wide DNS...

Add the below script to your pipeline, ahead of the deployment task:

- script: |
    sudo -- sh -c -e "echo '{ASE's Private IP}    {ASE Name}.appserviceenvironment.net' >> /etc/hosts";
    sudo -- sh -c -e "echo '{ASE's Private IP}    scm.{ASE Name}.appserviceenvironment.net' >> /etc/hosts";
    sudo -- sh -c -e "echo '{ASE's Private IP}    {AppName}.scm.{ASE Name}.appserviceenvironment.net' >> /etc/hosts";
  displayName: 'Fake DNS entries required for deployment'

The official solution is documented here: MS Docs: Create ILB ASE - DNS Configuration

You need to have DNS entries for your ASE so that the deployment task can reach it; but if you have an internal only ASE, those entries aren't created in public DNS, and MS don't manage private DNS.

MS propose creating the DNS entries in your internal DNS:

Create Zone {ASE Name}.appserviceenvironment.net

• Type: Primary Zone
• Store the zone in AD: True
• Zone Replication: To all DNS servers in the domain
• Zone Name: {ASE Name}.appserviceenvironment.net
• Allow only secure updates: true

Create A Record under {ASE Name}.appserviceenvironment.net

• Name: *
• IP: {ASE's Private IP}

Create A Record under {ASE Name}.appserviceenvironment.net

• Name: *
• IP: {ASE's Private IP}

Create Child Zone under {ASE Name}.appserviceenvironment.net

• Name: scm

Create A Record under scm.{ASE Name}.appserviceenvironment.net

• Name: *
• IP: {ASE's Private IP}

However, whilst awaiting the DNS creation I tried a workaround which turned out to be sufficient for the pipeline's needs...

Add the below script to your pipeline, ahead of the deployment task:

- script: |
    sudo -- sh -c -e "echo '{ASE's Private IP}    {ASE Name}.appserviceenvironment.net' >> /etc/hosts";
    sudo -- sh -c -e "echo '{ASE's Private IP}    scm.{ASE Name}.appserviceenvironment.net' >> /etc/hosts";
    sudo -- sh -c -e "echo '{ASE's Private IP}    {AppName}.scm.{ASE Name}.appserviceenvironment.net' >> /etc/hosts";
  displayName: 'Fake DNS entries required for deployment'

HOWEVER; the above fix only fixes the pipeline's deployment.

The FQDN for the app service is still not present; and the IP alone won't work since all apps on the ASE will have the same IP / we need hostname resolution. In our case we had an AppGateway in front of the app service; so you could pick the app service you're after from the list... but that's resolved to an FQDN, which then fails as the AppGateway can't resolve that FQDN to an IP... So you do need your DNS to be updated.

Whilst testing the service / awaiting DNS changes, our developers just updated their local device's hosts files to work around that issue: {ASE's IP} {appServiceName}.{ASE Name}.appserviceenvironment.net