I was troubleshooting this issue on an Azure App Service (ASE) and found the 404 was actually a 404.63.0 which translates into “Site not found: Hostname lookup failed, we are probably under attack”. The interesting thing was that it was only reproducible randomly and after I sat an hit the F5 or refreshed the page over and over again. I have mentioned in many of my articles (here and here for example) that 404 are some of the most confusing issues because most think a 404 is File Not Found, but really a 404.0.2 is that. 404 has many sub-status codes and you must find that one to debug 404s, unless the file really isn’t there, then you just put it there.
In this case, the 404.63.0 was triggered because it breached/triggered a dynamic IP security rule, see here for the details. You will find in that article that there is a denyAction called NotFound and it will return a 404 to the client.
There are also some child elements denyByConcurrentRequests and denyByRequestRate, the names intuitively describe their purpose. Nonetheless, I add them here:
- denyByConcurrentRequests – Specifies that certain remote clients will be blocked based on the number of requests received over time
- denyByRequestRate – Specifies that certain remote clients will be blocked based on the number of concurrent HTTP connection requests from clients.
In the situation I was in that triggered me writing this article was that the issue could only be reproduced randomly, but almost always after 10 refreshes. When that happened, IIS was instructed to return this 404 based on the configured denyByRequestRate configuration.
Although I mention this happened on an ASE, it is possible to configure dynamic IP security on the multi-tenant environment and if your rule is hit then you would get the same. FOr sure you can configure this on a stand-alone IIS server.