Ambiguity of using '.' as a separator in the site directory name might have security implications? In a Drupal installation, which is served through the web server's default server config (i.e. it gets any request for an otherwise unknown domain) I have a settings file at DRUPAL_ROOT/sites/example.com.au/settings.php.

This site is normally requested as http://example.com.au/, but what's given that the request gets to the server (and the user agent may not follow the directives of DNS here), what's to prevent it being served as a response for http://example.com/au/ or http://example/com/au/?

The testing I've done suggests something blocks this from working (I get a redirect to the install page), but I want to be clear on what's going on, and to be sure that it's reliable.  

If accessing a drupal installation through divisions of the domain name and path other than the expected one is possible, then there would be security implications.

EDIT:

In response to @tenken:

From https://api.drupal.org/api/drupal/sites!example.sites.php/7

This file allows you to define a set of aliases that map hostnames, ports, and pathnames to configuration directories in the sites directory. These aliases are loaded prior to scanning for directories, and they are exempt from the normal discovery rules. See default.settings.php to view how Drupal discovers the configuration directory when no alias is found.

It's not perfectly clear, but that sounds like the directory in the sites file will will still be used if a request arrives with a domain name that was not anticipated, in which case the problem remains.
Your virtual host rules are as secure as you've written them. If you want complete control on what URLs map to what multi-site installations then use the sites.php placed in sites/sites.php of your sites folder to explicitly set what URL(s) go to which Drupal installation using PHP.

The sites.php file resolves the URL -> site mapping after the webserver directs traffic to Drupal.

EDIT

Drupal can be run in multi-site or standalone. This is accomplished on how you configure your webserver. The "problem" you're describing is you want to use multi-site but not have Drupal try to discover invalid site addresses. This is purely dependant on how you setup your webserver.

An example of how to setup Apache for multisite might be:

&lt;VirtualHost *:80&gt;
  ServerName example.com
  ServerAlias *.example.com
  DocumentRoot /var/www/example.com
&lt;/VritualHost&gt;


This will resolve example.com to the docroot and any subdomain site at *.example.com -- including "invalid" subdomains which may not exist and attempt to route to an invalid url as you've described. This is by design by Drupal when using multi-site installation.

How might this be fixed for Apache? By fixing Apache vhost entries to limit what valid domains the virtual host is used for. This is not necessarily fixable via Drupal (although I still like using sites.php personally).

For instance we can change our virtualhost to the following:

&lt;VirtualHost *:80&gt;
  ServerName example.com
  ServerAlias site1.example.com abc.example.com xyz.example.com example
  DocumentRoot /var/www/example.com
&lt;/VritualHost&gt;


This revised Apache virtualhost routes example.com and exactly 4 subdomains and no others to the docroot. No other domain traffic will be routed to this drupal installation from the webserver.

A similar technique should be available for most webservers. Your virtual host rules are as secure and as organized as you've written them for your own production servers. I use Nginx as a proxy for Apache on a few websites, and Nginx as the sole webserver for at least 1 site, but I haven't had to try to solve this problem myself using only Nginx (but I'm familiar with the Apache solution above).