Azure Application Gateway Default DNS Suffix

Question

What is the correct way to configure an Azure Application Gateway to be able to handle requests which use a host header with only a hostname (i.e. not a fully qualified domain name) due to clients relying on their DNS search suffix list to handle this.

Detail

We have an Azure Application Gateway which is configured with a Private IP to act as a load balancer for a variety of internal websites / web applications.

Since we're handling multiple sites on this app gateway, I've configured multi-site listeners, which rely on the HTTP/1.1 Host Header to correctly route requests to the relevant backend.

Many of these sites have FQDNs which are on our primary domain suffix; e.g. reporting.domain.example.com. Because our primary domain is in our client device's search suffix list, this means that normally they'd be able to type reporting and have DNS resolve this to reporting.domain.example.com, taking them to the correct place. However, the browser doesn't send the DNS resolved FQDN, but sends the user entered hostname in the host header value. This means that my listener won't get the full name it expects.

I can work around this; creating a listener configured with the hostname without the DNS suffix to capture requests which arrive this way; and I can even handle HTTPS as we have an our own trusted certificate authority (i.e. AD Certificate Services), so can issue certificates which include both FQDN and the short name form in their SAN list.

However, I found an oddity after setting up a few sites... with listeners configured like below:

• listener example1.domain.example.com -> redirects to an external site
• listener example1 -> redirects to listener example1.domain.example.com
• listener example1-test.domain.example.com -> sits over a backend pool

I found that requests made to https://example1-test.domain.example.com were being redirected to the external site configured on listener example1.domain.example.com.

I tested with Chrome's Developer Tools' Network > Disable Cache option checked to ensure I wasn't being affected by cached 301s, double checked the app gateway's configuration to ensure I'd not mapped the listener to the wrong request routing rule, or configured the rules incorrectly, and deleted and recreated the listeners and rules in case something had become corrupted; but with no joy.

When I changed the hostname of the example1 listener to XXXexample1 I found that example1-test.domain.example.com started working as expected.

I've not found any documentation on this setup, so don't know if it's a bug, if what I'm trying is unsupported, if the listener isn't using a string but some form of pattern matching/regex equivalent, or if there's some other official way to handle this scenario instead of the method I "discovered".