App Proxy External URL stuck at NXDOMAIN for 4+ days - tenant DNS publish failure

Question

App Proxy External URL stuck at NXDOMAIN for 4+ days - tenant DNS publish failure

_da_asad.taj 0

We enabled Microsoft Entra Private Network on our tenant a few days ago and published our first Application Proxy app. The configuration appears correct, the connector is healthy, but the External URL has been returning NXDOMAIN in public DNS for 4+ days.

WHAT WORKS

Bootstrap endpoint <tenant-id>.bootstrap.msappproxy.net resolves cleanly from public DNS (Google 8.8.8.8 and Cloudflare 1.1.1.1)
Connector services (WAPCSvc, WAPCUpdaterSvc) running on Windows Server 2022 Azure Edition
Connector has no Event 12015 errors after a clean restart (DNS cache flushed first)
Outbound connectivity verified to login.microsoftonline.com, proxyregistration.msappproxy.net, scus-tm.msappproxy.net, etc.
Backend reachable via Private Endpoint on TCP 443
HTTP/2 disabled in WinHTTP per documented Server 2022 guidance
.NET 4.8, TLS 1.2, no outbound proxy

WHAT DOES NOT WORK

The following DNS lookups return NXDOMAIN from all public resolvers (8.8.8.8, 1.1.1.1, 168.63.129.16):

<app-prefix>-<tenant-prefix>.msappproxy.net (the published External URL)
<tenant-id>.nam.tenant.runtime.msappproxy.net (the runtime endpoint shown in the bootstrap CNAME chain)

APP CONFIG

Pre-authentication: Microsoft Entra ID
Internal URL: an Azure Web App with Private Endpoint in the same VNet as the connector
External URL: default msappproxy.net hostname (no custom domain configured yet)
Properties — "Enabled for users to sign in": Yes
Admin consent: granted (Microsoft Graph User.Read shows "Granted through Admin consent")
User assigned under Users and groups
Connector group: dedicated group containing the single Active connector
Connector region and tenant region: both North America

THINGS I HAVE TRIED

Restarted connector services after flushing local DNS — bootstrap connection now clean
Granted admin consent explicitly
Verified "Enabled for users to sign in" is Yes
Verified the External URL field in the portal matches what I am testing
Renamed the prefix once and reverted — both prefixes return NXDOMAIN
Ran the Diagnose and solve problems AI Self-Service troubleshooter — its conclusion was: "If the portal still shows that exact External URL and DNS still returns NXDOMAIN, this looks like a tenant/service-side issue and should be escalated."
Failed sign-ins in last 24 hours: 0 — confirms users are not even reaching pre-auth (consistent with DNS publishing failure rather than auth misconfig)

THE PATTERN

The bootstrap endpoint publishes correctly but the runtime endpoint and External URL never publish. This pattern suggests partial tenant provisioning where the bootstrap track completed but the runtime DNS publish job is stuck on the backend.

QUESTIONS

Is there anything else to verify on the tenant side that would block runtime endpoint publishing while bootstrap succeeds?
Has anyone seen this pattern before — bootstrap healthy but External URL persistently NXDOMAIN?
Is this something only Microsoft Support can unblock via backend re-provisioning?

Thanks in advance for any guidance.

Vinayteja Lellela 110 Reputation points Microsoft External Staff Moderator

2026-06-29T22:06:47.1133333+00:00
Hello @_da_asad.taj ,

This does sound very much like a service-side/tenant provisioning issue with the Application Proxy runtime DNS publication, since:

Your bootstrap endpoint resolves publicly and the connector is healthy

But the published External URL hostname (and the runtime endpoint in the bootstrap CNAME chain) returns NXDOMAIN from multiple public resolvers for 4+ days

And sign-ins are 0 failed, consistent with clients never reaching the pre-auth step (because DNS never resolves)

The only troubleshooting path we can confidently suggest here is around DNS publication/resolution failures, specifically patterns that come from missing/unlinked DNS zones, missing A records, or DNS forwarder/override behavior. However, your case appears to be public DNS NXDOMAIN, not “private endpoint resolves incorrectly,” and the provided docs don’t include Application Proxy’s internal runtime DNS job diagnostics.

What to verify (closest DNS-related checks from the provided docs)

Even though this is Application Proxy (not Private Endpoint DNS), these are still the most relevant DNS failure categories mentioned in the docs:

Confirm there isn’t any DNS “shadowing”/conflicting zone behavior

The private-link DNS troubleshooting guidance calls out “duplicate or conflicting zone names” where a customer-managed DNS zone can shadow an Azure Private DNS zone, causing NXDOMAIN or wrong answers.

In your case you’re testing public resolvers, but it’s still worth confirming you’re not testing through a resolver path that might be authoritative/filtered in a way you don’t expect.

Look for “missing record / stuck publish” behavior

The docs explain scenarios where an expected A record is missing or stale, and where propagation/record creation can take time.

Your “bootstrap works but runtime endpoint + External URL NXDOMAIN” pattern strongly resembles partial record publication (i.e., bootstrap path succeeded, runtime record path didn’t).

Can you please update us if the action plan provided was helpful?

Should there be any follow-up questions or concerns, please let us know and we shall try to address them.

If these answer your question, click "Upvote" which may be beneficial to other community members reading this thread.
Vinayteja Lellela 110 Reputation points Microsoft External Staff Moderator

2026-07-02T17:22:10.5666667+00:00

Hello _da_asad.taj, following up to see if you had a chance to check the above response and if it was helpful. Please let me know if you have any questions.
Vinayteja Lellela 110 Reputation points Microsoft External Staff Moderator

2026-07-03T17:19:19.7766667+00:00

Hello _da_asad.taj, following up to see if you had a chance to check the above response and if it was helpful. Please let me know if you have any questions.

1 answer

Your answer

Vinayteja Lellela 110 Reputation points Microsoft External Staff Moderator

2026-07-02T17:22:10.5666667+00:00

Hello _da_asad.taj, following up to see if you had a chance to check the above response and if it was helpful. Please let me know if you have any questions.
Vinayteja Lellela 110 Reputation points Microsoft External Staff Moderator

2026-07-03T17:19:19.7766667+00:00

Hello _da_asad.taj, following up to see if you had a chance to check the above response and if it was helpful. Please let me know if you have any questions.

Answer 1

Hi _da_asad.taj,

Thx for sharing urs issue here at Q&A portal.

If the default msappproxy.net External URL is still NXDOMAIN after 4+ days, while the connector is healthy and bootstrap DNS resolves, this looks more like App Proxy runtime DNS publishing stuck on the service side than a connector/backend/auth issue.

Since users never reach pre-auth and there are no failed sign-ins, auth config prob isn’t the blocker. The request is dying before Entra can even see it. I’d open a Microsoft Entra / App Proxy support case and include tenant ID, app object ID, connector group, External URL, region, UTC creation time, and DNS results from 8.8.8.8 / 1.1.1.1. Ask them to check whether the tenant runtime endpoint and app hostname were published in backend DNS.

Nothing else on ur connector will fix NXDOMAIN for the public External URL. This needs backend re-publish / tenant provisioning check from MS.

Rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

and at my blog https://ctrlaltdel.blog/