Not neccessarily. IIS could also serve as a reverse proxy/load balancer, with a Kestrel installation behind it. (If I'm not mistaken the response header is only set in static resource responses.)

Interesting, I thought kestrel was supposed to be way faster than IIS. Wonder why they stuck with IIS after going through all this.

Current: Windows Server 2016 + http.sys + homegrown managed layer replacement for System.Web.

Near future: Windows Server 2019 + http.sys + ASP.NET Core

Medium future: Windows Server 2019 + Kestrel + ASP.NET Core

You are not supposed to expose kestrel to the open internet. It should always run behind a reverse proxy like nginx or, in this case, IIS.

Microsoft has changed thier guidance. Check out the different verbiage between the 1.x tab and the 2.x tab.

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/se...

I'm sure they are using Kestrel behind IIS.

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/se...

Kestrel needs a reverse proxy in front of it for SSL termination etc. https://docs.microsoft.com/en-us/aspnet/core/fundamentals/se...

Doesn't need on for SSL; needs a reverse proxy if you want to do port sharing (many apps on port 80/443 switched by host header) or Windows Auth.

You can also build your reverse proxy using Kestrel.

Though IIS is more battle tested so they may be using that as front line server for such a high profile service as Bing

Is it even wise to design a system that uses un-encrypted backend traffic? The Snowden revelations did demonstrate that intelligence services are snooping on those.

Not over an actual network; but localhost or in-process it should be fine? Though the in-process IIS hosting is ASP.NET Core 2.2 as it got bumped from the 2.1 release https://github.com/aspnet/IISIntegration/issues/878

ok but then it is not much of a load balancer.

Meant for port sharing; multiple apps or subdomains switching either on host header or path; as you can't have multiple processes listening on the same port (80/443) on the same machine. Or changing which is run based on the path

That's no longer a requirement with the latest release of .net core.