The component that does the host resolving is EPiServer.Web.Routing.Internal.VirtualPathHostResolver. As you see is it placed in an internal namespace so it is not inteded to be extended and hence are any extensions to it nothing that we officially support.

With that said one option is to Intercept that type and then in your interceptor for the method GetVirtualPathHost you can check if the current request is on the internal domain then return the HostDefinition for that domain else you just delegate the call to the default implementation of VirtualPathHostResolver.

Alright, thanks Johan!

I've been looking into exactly that path, but as it is internal I've avoided it.
Will try it out now though.

Any plans on making this an official extension point?

Edit:

Hmm, it doesn't look like the VirtualPathHostResolver is instantiated via the container.
The instance passed to DefaultContentRoute looks to be created using the constructor directly (using Episerver 10.10.4).

Any ideas?

Not really answering your question, but some thoughts that might take you to a solution for your problem:

• Can you use a culture for the internal domain that is not used for the public site? If public site is using "en" as culture, you could bind internal domain to "en-US" and publish all internal pages in that culture/language.
• Or, let IIS rewrite the incoming urls from publicdomain.com/internalpages to internaldomain.com/internalpages. User would get redirected for every link though.
• Or, let IIS rewrite the urls in the outgoing response (https://docs.microsoft.com/en-us/iis/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing).

Thanks for your input!

For our case the additional language would not be good enough, there are too many languages and content items (both CMS and Commerce).

I looked into some URL rewriting before diving deep into possible Episerver workarounds, but left it after some headaches.
The internal features are spread around the normal content structure and is not grouped under e.g. /internalpages, so inbound rewriting could prove hard.
Outbound rewriting could possibly work. There is the issue of some URL:s being output as data-tags for use in scripts and similar which could be problematic. 
We also have a multisite solution, each having their own set of language specific domains and I think it would be quite a lot of configuration to maintain.

I have an upcoming discussion with the customer regarding alternative solutions to the internal domains.
Hopefully we can find some other approach to this without wrecking their routines. 
It would clearly be preferable maintaining "Episerver standard" and not relying on these workarounds, especially in the long run.

After talking with the customer, the decision was taken to solve it using outbound rewrites.
There is maintanence involved and maybe some gotchas but the customer is aware of it.

The following rule seems to do the trick and we have quite a few of these now, one per culture specific domain per site.

<rewrite>
  <outboundRules>
    <rule name="IntranetEN" preCondition="IsHtml" patternSyntax="ECMAScript">
    <match filterByTags="A" pattern="(?:http(?:s)?://)?www\.external-hostname\.com(.*)" />
    <action type="Rewrite" value="http://internal-hostname{C:1}/en{R:1}" />
    <conditions>
      <add input="{HTTP_HOST}" pattern="internal-hostname(\.internal-domain)?" />
    </conditions>
    </rule>
    <preConditions>
      <preCondition name="IsHtml">
        <add input="{RESPONSE_CONTENT_TYPE}" pattern="text/html" />
      </preCondition>
    </preConditions>
  </outboundRules>
</rewrite>

I still would wish I could have solved this in Episerver though. :)

Thanks for your input Erik and Johan!