Two different 404 pages — one reveals which paths Akamai blocks at the edge
Most 404s on war.gov return a 98 KB DotNetNuke-styled error page with the full site chrome. But `/Admin/`, `/Install/`, `/Login.aspx`, and `/Login` return the 1245-byte raw Microsoft IIS 7 stock 404 — gray header, Verdana, “Server Error”. That tells you the path is intercepted at Akamai / the edge before the DNN app ever sees the request.
404 size alone is enough to fingerprint which paths are filtered at the CDN versus app layer. Belt-and-suspenders blocking on `/Admin/` etc. implies recent security hardening (and confirms war.gov runs on Microsoft IIS + DotNetNuke, despite the `Server: AkamaiGHost` masking header).
Side by side
Evidence
Probing war.gov with curl:
``` HTTP=404 SIZE=1245 /Admin/ ← IIS 7 stock 404 (edge-blocked) HTTP=404 SIZE=1245 /Install/ ← IIS 7 stock 404 (edge-blocked) HTTP=404 SIZE=1245 /Login ← IIS 7 stock 404 (edge-blocked) HTTP=404 SIZE=1245 /Login.aspx ← IIS 7 stock 404 (edge-blocked)
HTTP=404 SIZE=98417 /humans.txt ← DNN-styled 404 (app-reached) HTTP=404 SIZE=98411 /UAP ← DNN-styled 404 (app-reached) HTTP=404 SIZE=98410 /api ← DNN-styled 404 (app-reached) ```
The stock IIS 404 contains:
``html
<title>404 - File or directory not found.</title>
...
<div id="header"><h1>Server Error</h1></div>
<h2>404 - File or directory not found.</h2>
``
…served with no Akamai cache headers and no DNN chrome. The DNN-styled 404 is 80× larger and includes the full site nav, footer, and meta keywords.
Combined with finding robots-discloses-dnn-tree (below), it’s now public knowledge that war.gov is IIS + DNN behind Akamai.