Why can't I access SharePoint by UNC path?

The short answer is that URLs don't support spaces, and UNC paths do. You're probably copying the URL into Windows Explorer, so just replace each %20 in your path with a space and you should be off to the races.

This:

http://moss.mysite.com/Shared%20Documents/

Becomes:

\\moss.mysite.com\Shared Documents\

If your SharePoint site is on a port other than 80, drop the port number from the UNC path.

This:

http://moss.mysite.com:2112/Shared%20Documents/

Becomes:

\\moss.mysite.com\Shared Documents\

If that fails, drop to a command prompt and try pinging the server:

ping moss.mysite.com

No response? Something is probably screwed up with DNS. Though you may be able to hit the site in your browser, there may be a redirect going on and it isn't fully configured in DNS. This redirection may be because the "true" web application has a different name or port.

What's the best practice? Give each of your web applications its own IP address with it's own port 80. The only time you use a different port should be when you enable SSL and traffic flows on 443. One application, one IP. You're already maintaining a list of host headers or ports, so get rid of those, get yourself a block of private addresses (I hear they're free), and save yourself more than a few headaches in configuring DNS, routing, and security.

Security? For sure. Who wants user traffic running on anything but standard ports? I don't. If I'm limiting database traffic, I don't want to be doing inclusions and exclusions for 50 applications by port number, I want each to have a big fat IP address to allow or disallow.

DNS is what you use to name applications, not host headers. Why not host headers? "You cannot use Host Headers as the primary means of identifying a web site when using SSL. I don't care what else you've heard, this is the case. . . . Therefore, regarding your configuration, do what you like as long as you don't use host headers on the same site that you require SSL."