Newly deployed instances are not responding. Looks like a DNS issue.

[scale-tone]

Deploying this code to a newly created Static Web App instance. Tried deploying via both Azure Portal and CLI. Results are the same: the instance is created, the deployment workflow succeeds, the instance looks healthy in the portal, but the app's root URL does not respond (fails with ERR_CONNECTION_TIMEOUT):

Tried two regions: centralus and westeurope. No difference.

nslookup on the newly created DNS name (nice-wave-04a90fd10.1.azurestaticapps.net) looks weird:

C:\projects\github\cognitive-search-static-web-apps-sample-ui>nslookup nice-wave-04a90fd10.1.azurestaticapps.net
Server:  sahhgw.home
Address:  10.0.0.138

Non-authoritative answer:
Name:    nettvern-info.telenor.net
Address:  148.123.15.44
Aliases:  nice-wave-04a90fd10.1.azurestaticapps.net

Compare this with result for my previously created, healthy instance:

C:\projects\github\cognitive-search-static-web-apps-sample-ui>nslookup lively-sand-033e9ec03.azurestaticapps.net
Server:  sahhgw.home
Address:  10.0.0.138

Non-authoritative answer:
Name:    waws-prod-am2-0ab44d07.cloudapp.net
Address:  40.118.40.109
Aliases:  lively-sand-033e9ec03.azurestaticapps.net
          azurestaticapps.trafficmanager.net
          msha-am2-0.staticsites-prod-westeurope.p.azurewebsites.net
          waws-prod-am2-0ab44d07.sip.p.azurewebsites.windows.net

Doing nslookup nice-wave-04a90fd10.1.azurestaticapps.net from a GitHub codespace produces different results:

@scale-tone ➜ /workspaces/az-messaging-demo (main ✗) $ nslookup nice-wave-04a90fd10.1.azurestaticapps.net
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
nice-wave-04a90fd10.1.azurestaticapps.net       canonical name = azurestaticapps1.trafficmanager.net.
azurestaticapps1.trafficmanager.net     canonical name = msha-slice-1-am2-1.msha-slice-1-am2-1-ase.p.azurewebsites.net.
msha-slice-1-am2-1.msha-slice-1-am2-1-ase.p.azurewebsites.net   canonical name = waws-prod-am2-8b19502a.sip.p.azurewebsites.windows.net.
Name:   waws-prod-am2-8b19502a.sip.p.azurewebsites.windows.net
Address: 51.124.12.35

Requesting that '51.124.12.35' address results in 404:

Deployment workflow is here.

To Reproduce

• Deploy the app instance as described here.
• Try to navigate to the app's root page.

[simonaco]

thank you for reporting @scale-tone, I was able to reproduce and our engineering team is investigating the issue.

[scale-tone]

Thanks @simonaco , but:

• How much global is the outage?
• Azure Status/Service Health is very much green, don't see any mentions of this there still. How do we track the progress?
• Any estimations?

[simonaco]

@scale-tone , my colleagues from India, UK, and Spain can access https://nice-wave-04a90fd10.1.azurestaticapps.net and https://victorious-grass-0b0ef9c1e.1.azurestaticapps.net/ which I created to repro. So it seems like it's only certain regions that are affected so far.

We reported a customer incident and will keep you posted here with progress. If you'd like direct feedback please create an ICM and we can track it there as well.

[pvbchak]

@scale-tone, Is sahhgw.home a custom DNS resolution server. Given nslookup from GitHub workspace resolves as expected, we suspect it is an issue with sahhgw.home DNS resolution server.

"Requesting that '51.124.12.35' address results in 404:" would never work with old / new Static Web Apps. It is by design.

[scale-tone]

Is sahhgw.home a custom DNS resolution server.

@pvbchak , assuming this was a question, not sure what you mean by "custom" DNS server. "sahhgw.home" is my WiFi router that I'm connected to Internet through.

[pvbchak]

@scale-tone, ISP or company can setup DNS servers and can control how DNS resolution works. Given "nice-wave-04a90fd10.1.azurestaticapps.net" is not resolving correctly (on your machine), we suspect it is the issue. Can you please try adding mapping from nice-wave-04a90fd10.1.azurestaticapps.net to 51.124.12.35 in Windows hosts file (Please see steps in https://www.freecodecamp.org/news/how-to-find-and-edit-a-windows-hosts-file/). Please note this is not a permanent solution and do not recommend doing it for all Static Web Apps

[miwebst]

After diving further into this, it turns out that the ISP had blocked the domain due to phishing concerns. We believe this is happening as new SWA's may have the '.1.azurestaticapps.net' subdomain. This new subdomain is a side effect of architectural improvements and for the most part should be transparent to interactions with SWA.

If you are hitting SSL_PROTOCOL_ERROR or hitting DNS issues when reaching the default hostname of your SWA, you may need to contact your ISP to allowlist your domain as they may have incorrectly flagged it.

We will keep this issue open so others may comment if they are hitting similar issues with their ISPs.