Note: this document is targeted at the network operations group within MIT.
Request description
Assume our Alfresco virtualization server is named VIRTUALFRESCO.MIT.EDU with the IP address 18.92.1.237, although these details are obviously subject to change.
We would like VIRTUALFRESCO.MIT.EDU to be a wildcard subdomain where every name at or under this level will resolve to 18.92.1.237. For example, this may correspond to a zone entry of
*.virtualfresco.mit.edu IN A 18.92.1.237
Or (if wildcards are not easily supported by MIT DNS) it may be desirable to delegate name resolution within the subdomain to another nameserver under NIST's (or a trusted group's) control. In any case, the net effect is that virtualfresco.mit.edu, foo.virtualfresco.mit.edu, bar.foo.virtualfresco.mit.edu, quux.baz.bar.foo.virtualfresco.mit.edu, etc., will all resolve to the same IP address.
Because this will be semi-permanent, the TTL should probably be set fairly high.
Impact
Note that no machines other than the virtualization server itself will reside in this subdomain. Thus, there is no chance for a machine to fall prey to the spoofing attack described in RFC 1535, which seems to be the main objection to the use of wildcard (sub)domains. Also note that there will be no MX record for this subdomain. Thus, there is no chance for the introduction of the problems mentioned in RFC 1537. It seems that such a wildcard subdomain will be a relatively benign introduction to MIT's DNS.
Use
This will be used for Alfresco virtualization as described here. In short, the virtualization server will use the information contained in the virtual hostname as metadata used to condition its response. It allows the server to serve up different versions of the same web site.