Note: this document is targeted at the network operations group within MIT.
Alfresco virtualization works as described here.
Request description
Assume 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.
...
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 control(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 Thus we will not incur problems such as those described in RFC 1535. 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.