Server ACL fail to consider the hierarchical nature of DNS.

The _Server Access Control List_ room state event and functionality announced by matrix-org/matrix-spec-proposals#1383 fails to implicitly consider sub-domains of a domain entry in the list.

When an administrator desires to ban a server named `foo.com` from a room, setting an ACL to deny `foo.com` still allows for cost-free evasion by an attacker who creates the domain `evading.from.foo.com`. While the current ACL system respects globular expressions to ban `*.foo.com`, such an expression fails to match `foo.com` and thus two entries in the ACL list are required for every original entry desired.

This is very much a legitimate security vulnerability because it's counter-intuitive: it requires special knowledge to set an effective ACL; users will very likely be ineffective in administering matrix rooms and mitigating attacks. Numerous instances of this mistake are already evident in the wild, and they will continue to be.

#### Solution

The solution is to simply equate `foo.com` with `*.foo.com` (additional example: `from.foo.com` with `*.from.foo.com` but not `foo.com`) which is perfectly acceptable given the hierarchical nature of the DNS sub-domain scheme. **There is no legitimate reason that a sub-domain of a banned domain should not match the ACL.**

#### Conclusions

This oversight is likely due this specification's development without feedback, bypassing the standard process under the guise of security and imminent threat. This hasteful and secretive course was unnecessary when considering the following facts:
<sub>1. This feature requires *all* servers participating in a room to upgrade and support it.
2. This feature is still vulnerable to the `m.room.server_acl` event itself being state-reset out of the room and neutralizing its function entirely.</sub>

Review the server ACL behavior announced by matrix-org/matrix-spec-proposals#1383, focusing on the m.room.server_acl event and its domain matching rules. Compare the documented handling of foo.com, *.foo.com, and subdomains, then confirm that the specification clearly defines the intended matching behavior and examples.

Written by the indexing model from the issue text.