SCM Access: Client DNS and HTTP Failures¶

1. Summary¶

Use this playbook when a browser cannot open Kudu/SCM for one or several apps. Start at the affected client, not inside the application. App-to-dependency DNS failures belong in DNS Resolution in VNet-Integrated Apps.

For publicNetworkAccess defaults, main/SCM policy evaluation and approved private-only cutover, use Private Endpoint and Access Restriction Decisions. This page owns per-client connection evidence and probes.

Separate a browser name-resolution failure from an HTTP rejection on a different attempt. Neither observation supplies the missing evidence for the other. Multiple affected apps suggest checking shared paths; membership in one subscription does not establish a subscription-wide platform failure.

Verification boundary: public-source review dated above; client probes and Azure reproduction NOT_RUN. There is no customer incident, captured diagnostic output, or established root cause on this page. Hypotheses start NOT_TESTED; unavailable discriminating evidence remains INCONCLUSIVE. Source verification is not live execution.

flowchart TD
    A[Identify client, attempt and exact SCM hostname] --> B{Name resolves on that client path?}
    B -->|No| C[Inspect resolver, proxy DNS and private records]
    B -->|Yes| D{TCP and TLS complete?}
    D -->|No| E[Inspect route, VPN, proxy and certificate evidence]
    D -->|Yes| F{Who generated the HTTP response?}
    F --> G[Correlate proxy or App Service response]
    G --> H[Check applicable access rules and authentication]
    H --> I{Evidence distinguishes a cause?}
    I -->|No| J[INCONCLUSIVE; collect only missing evidence]
    I -->|Yes| K[Apply a scoped correction and repeat the same test]

Apply the stages to the actual connection path. An explicit proxy can return an HTTP CONNECT rejection before TLS to SCM completes. Record which hop produced the response; neither proxy connectivity nor TLS to a proxy establishes TLS to SCM. If the response origin cannot be corroborated, record it as Unknown.

2. Common Misreadings¶

3. Competing Hypotheses¶

H5 is not the default explanation when H1-H4 lack data. More than one hypothesis can apply to different attempts.

4. What to Check First¶

1. Record the exact hostname launched by Advanced Tools, target slot, hosting mode and client alias. Use the actual SCM endpoint from Kudu Overview; do not manufacture an ASE or slot hostname from a multitenant example.
2. Reuse existing screenshots and probe results when they already identify the same client, target and time. Ask only for missing dimensions or a justified fresh comparison.
3. Compare main and SCM names from the affected client path. For the documented multitenant default-hostname configuration, the private DNS system contains A records for <app-name>.privatelink.azurewebsites.net and <app-name>.scm.privatelink.azurewebsites.net, both resolving to the intended private endpoint IP. These are DNS records, not replacement browser URLs. See the private endpoint DNS guidance.
4. Inspect public network access, the default/private endpoint choice, SCM rule inheritance, separate rules and unmatched-rule behavior read-only. Check scmIpSecurityRestrictionsUseMain ("Use main site rules"): when enabled, SCM uses the main-site restrictions; otherwise inspect SCM's own rules and unmatched action instead of assuming the main-site result applies (see SCM restrictions and the site configuration reference). Private-endpoint ingress is not evaluated against site access restrictions. ILB ASE has a different default endpoint model; consult access restrictions before interpreting publicNetworkAccess.
5. Investigate authentication only after establishing the relevant endpoint path. For Kudu browser access using Microsoft Entra authentication, the assigned built-in or custom role over the application scope must include Microsoft.Web/sites/publish/Action. This is necessary for that authentication path; it does not establish DNS, network reachability or a successful sign-in. Use least privilege rather than granting Owner to test connectivity. See Kudu permissions.

Do not change app-side WEBSITE_DNS_SERVER to repair workstation name resolution. A probe from Cloud Shell, WSL, a jump host or the app container may use a different resolver/proxy path from the failing browser; label that vantage point rather than presenting it as the same test.

5. Evidence to Collect¶

Use one row per attempt, with UTC collection time in private incident records. Use aliases and relative ordering when publishing an example.

Collect one row per attempt in this matrix. Leave a cell blank or Unknown rather than inventing a value; this template contains no observed results.

Classify the DNS answer as NXDOMAIN, timeout or no answer, public address, intended private-endpoint address, other answer, or Unknown. Record TCP and TLS separately and use Unknown or not reached when the observation does not establish that stage. Keep exact timestamps, hostnames and addresses in restricted records; publish aliases and relative ordering only.

Bounded client probes¶

The following Bash example is for an approved shell on the affected client. Replace the placeholder. Do not run it from another machine and silently treat the result as browser evidence.

SCM_HOST='<scm-hostname>'
dns_rc=0
nslookup -timeout=5 -retry=1 "$SCM_HOST" || dns_rc=$?
printf 'dns_exit=%s\n' "$dns_rc"
curl_rc=0
curl --disable --silent --show-error --output /dev/null \
    --connect-timeout 10 --max-time 30 \
    --write-out 'http=%{http_code} remote_ip=%{remote_ip} total_seconds=%{time_total}\n' \
    "https://${SCM_HOST}/" || curl_rc=$?
printf 'curl_exit=%s\n' "$curl_rc"

This invocation supplies no SCM credentials or browser cookies and does not follow redirects; it is not the authenticated browser session. Preserve approved proxy and CA settings: if they came from the disabled configuration file, supply only those approved settings explicitly and record the resulting path. Without --fail, curl can exit 0 for HTTP 401 or 403, so a zero curl exit means the transfer completed, not that SCM authorization succeeded. A 401, 403 or redirect is not automatically an authenticated-browser failure. A reported HTTP code of 000 means no HTTP response code was obtained; it is not a server status. Check the accompanying error. Do not add --insecure, export tokens, or bypass a corporate proxy to make the probe green. A shell using different proxy settings remains a different path.

Store output in approved restricted storage. DNS responses, peer addresses, HAR files, URLs, headers and cookies may expose sensitive details. Publish only reviewed, sanitized excerpts; never attach raw authentication material. Command option definitions are in the curl manual.

6. Validation and Disproof by Hypothesis¶

[Not Proven] Recovery after several simultaneous changes cannot isolate which change mattered. If the failing request cannot be correlated, state INCONCLUSIVE rather than assigning another client's HTTP response to it.

7. Likely Root Cause Patterns¶

8. Immediate Mitigations¶

Use an already authorized private client path while its owner repairs an evidenced DNS or routing defect. Change only the implicated record or access rule with approval and a rollback record, then repeat the same client/target test. Do not broadly expose SCM, disable TLS verification or restart every app because several names fail from one workstation.

9. Prevention¶

Maintain separate main/SCM reachability checks from intended client networks, with DNS and HTTP outcomes recorded independently. Track private DNS ownership and client proxy assumptions alongside access configuration. Keep an evidence-request checklist so investigators do not repeatedly ask for already supplied results.

See Also¶

• Playbooks
• Private Endpoint and Access Restriction Decisions
• Kudu Overview
• Networking Operations
• Windows Kudu Diagnostics
• Outbound DNS Investigation

Sources¶

• Kudu service and permissions
• Private endpoints and SCM DNS
• App Service access restrictions
• curl command manual