App Crash with Wild Card SSL

[OpenSpacesAndPlaces]

What kind of configuration can you put in to place to prevent wildcard ssl redirects if the website goes down.
Particularly if HSTS is enabled.

Like if I was using IIS the bindings still catch even if the app goes down, but with YARP it seems that it can fall through and then with HSTS enabled you might have a permanent redirect to a bad DNS.

[Tratcher]

but with YARP it seems that it can fall through

What does that mean? It sounds like you're using Kestrel as the server with YARP, and want to compare its binding behavior to IIS?

When a Kestrel server instance goes down it stops responding on the IP, you never even reach the TLS part of the handshake. What the client does next is up to them, they'll either retry, or try a backup IP, but even a backup IP shouldn't affect HSTS.

[OpenSpacesAndPlaces]

I have a few more details finally.

So there is a default domain binded to the IP of the server that's needed for some kind of security scan use-case.
With IIS, the website binding is never "lost", so the app crashing never causes a fallback scenario to happen.
But since as you correctly state, "When a Kestrel server instance goes down it stops responding on the IP, you never even reach the TLS part of the handshake." - the server is falling back to this default IP binding.

[Tratcher]

There shouldn't be. How do you have the binding reservations setup in netsh.exe?

[OpenSpacesAndPlaces]

They're weren't specifically bound with netsh - they already existed from GUI setup in the DNS administrative tools.
Is there a powershell/cmd command to run to show what you need?

[Tratcher]

cmd netsh http show servicestate is the best way to see the state of the system. You can manually filter by port and then compare the results with your service up and down.

[OpenSpacesAndPlaces]

I found it pretty quickly:

    URL group ID: F800000040000001
        State: Active
        Request queue name: Default SNI
        Properties:
            Max bandwidth: inherited
            Max connections: 4294967295
            Timeouts:
                Entity body timeout (secs): 120
                Drain entity body timeout (secs): 120
                Request queue timeout (secs): 65535
                Idle connection timeout (secs): 120
                Header wait timeout (secs): 0
                Minimum send rate (bytes/sec): 0
            Authentication Configuration:
                Authentication schemes enabled:
            Number of registered URLs: 2
            Registered URLs:
                HTTPS://*:443/
                HTTPS://DEFAULT.EXAMPLE.DEV:443/

                and
                
                 URL group ID: CD00000040000001
        State: Active
        Request queue name: MySite
        Properties:
            Max bandwidth: inherited
            Max connections: 4294967295
            Timeouts:
                Entity body timeout (secs): 120
                Drain entity body timeout (secs): 120
                Request queue timeout (secs): 65535
                Idle connection timeout (secs): 120
                Header wait timeout (secs): 0
                Minimum send rate (bytes/sec): 0
            Authentication Configuration:
                Authentication schemes enabled:
            Number of registered URLs: 2
            Registered URLs:
                HTTPS://MySite.EXAMPLE.DEV:443

[Tratcher]

Thinking about this more, I realized IIS has a process model where one process owns the queue and keeps it active (W3SVC), while another actually runs your app and processes the requests (worker process). https://blogs.iis.net/thomad/the-iis-process-model-features. That's why the queue isn't release when your app shuts down, W3SVC is still running.

Attaching to an existing queue is supported by AspNetCore's HttpSys server, but queue management like W3SVC is something you'd have to do yourself.
https://github.com/dotnet/aspnetcore/blob/07d728b517005ec655925d83bd7b66538145be81/src/Servers/HttpSys/samples/QueueSharing/Program.cs#L27