Computer names ending in .local have always been understood to be non-public and internal. At one time it was common to use this ending on test machines in development environments. However, the Internet standards have developed a different specific use for names ending in .local and it should not be used for anything else.
Managed workstations, servers, and other Windows computers on the Yale network are typically assigned the name of the Yale AD domain (yu.yale.edu) as a default suffix in the network configuration panels:
If you have a Yale laptop, but you have taken it home and you enter a simple unqualified hostname in a URL or network file name, then this suffix is appended. You type \\hatter\party\teapot.jpg and Windows looks for a computer name hatter.yu.yale.edu.
However, you may be at home and on you home network there are other machines that are not part of the Yale AD. If hatter is a home computer (or a VM on a virtual network your laptop can access), and it runs Windows, or is a Mac with Bonjour, or is a Linux computer running avahi-daemon, then appending .local to the hostname prevents Windows from appending any DNS suffix and tells the system “this is the name of a computer directly connected to my local network.”
Therefore, if instead you ask for \\hatter.local\party\teapot.jpg the system will broadcast a message to all the directly connected computers “is any machine here named hatter” and if it gets back a response it will use that computer.
Therefore, the “.local” end should only be used as a suffix to an simple hostname in the form “hostname.local”. If you have several computers or VMs running linux, it is a good idea to always “sudo apt install avahi-daemon” if it isn’t already installed, and use the hostname.local expression whenever you reference another directly attached computer or VM.