Direct URL to local file via the host file

OSX does have a /etc/hosts file but it first uses directory services to find hosts. These are maintained via the dscl command

This web page provides examples of use to maintain the lookups.

Essentially, you just need to run the following command in Terminal:

sudo dscl localhost -create /Local/Default/Hosts/sitename.com IPAddress 127.0.0.1

The DNS is the wrong tool for this job.

Let's deal with some silliness first:

Do I have to have yet another computer on all the time…?

No. This isn't the 1950s. Computers can run more than one server at once. Many Unices have been happily doing that, including running their own fully fledged resolving proxy DNS servers, as standard — out of the box — since the 1980s. Use the always-on computer that you say that you already have.

Setting up a DNS server is the next step when one wants to distribute a hosts file to multiple machines. That is, after all, pretty much the reason that the DNS came about in the first place. So a blinkered answer to your question

Must I set up an independent DNS server on my network and make sure all my local computers use it?

is "Yes.". That's what one does to scale up serving such data to an entire LAN.

However, the DNS is the wrong tool for the job that you want to do. I know that it may have seemed like a whizz-o idea to set up a hosts file with lots of names in it and block advertisements that way, but it's not scalable — as you've already discovered and as others discovered back in the 1980s — and (even if modified to use a content DNS server) it's not appropriate. It's not granular enough, and it's a layering violation.

• It's a layering violation because you aren't stopping your WWW browser from fetching content via HTTP/HTTPS. Instead you are changing the name→address mappings that everything on your machines use. So you are changing the mappings for SMTP, IMAP, POP, FTP, HTTP, NTP, CIFS, … and everything else that looks up domain names and maps them to IP addresses. For those guests on your LAN who might want to do things other than WWW browsing with the domain names that you've unilaterally deemed to be "advertising", things are royally screwed up. You are attacking the situation at the wrong layer. The name→address mapping layer is not the one to muck around with. The HTTP/HTTPS layer is.
• It's not granular enough because you'll find, once you've been doing this long enough, that the advertisers are wise to you. Perhaps the most blatant example of how this is problematic is that there's at least one web bug served up by Google whose URL has the domain name www.google.com. Block that using your sledgehammer-to-walnut approach, and you've blocked yourself off from pretty much the whole of Google. There are many other instances of the same thing, where the pop-up/pop-under scripts, first-party cookie injectors, web bugs, and other nasties are served up from the same domains as desirable content. I suggest a trawl through the database employed by adzapper — many of whose entries use regular expressions to match only some URLs of a domain — to see how widely this happens nowadays.

The right tool for this job is a proxy HTTP server, a PAC script, or an in-browser tool.

There are two choices of right approach, both of which operate at the HTTP layer and both of which have a finer granularity than entire domains:

• Tell one's WWW browser directly where to send its HTTP/HTTPS transactions for undesirable content. One often does this with a PAC script, and there are many people who publish PAC scripts for zapping advertisements that one can build upon. (John R. Lo Verso's script has been around for over half a decade.) One puts the list of regular expressions into the PAC script, and tells the WWW browser where to load the script from. The WWW browser itself retargets its HTTP/HTTPS transactions, without any need to alter DNS service, without any need to mess around with additional/replacement equipment, and without affecting other protocols, other softwares, and other people's work.

  A plug-in that blocks advertising by redirecting/handling the HTTP transactions is effectively the same approach. The WWW browser process itself does the work, and nothing outwith it is affected.

• Run a proxy HTTP server that has a set of pattern matching rules for a redirect/rewrite mechanism, and direct all WWW browsers to send their HTTP traffic through it. (This has the added benefit that one can, if one wants, then impose more draconian restrictions on HTTP traffic at the borders of one's LAN, since all traffic should originate from the back end of the proxy HTTP server.) Adzapper and Privoxy are two of several proxy HTTP servers available for this purpose. Instead of the WWW browser retargetting its WWW traffic, the proxy HTTP server does it. With some clever proxy HTTP servers one can do all sorts of tricks.

For nearly a decade, I used the first approach myself. Its disadvantage is that WWW browser handling of PAC scripts is fairly dodgy, even today. It's easy to make a script that won't work on all WWW browsers, the failure modes are atrocious (RealPlayer's in-built WWW browser hangs/crashes if presented with an incorrect PAC script, for example.) and the interactions between PAC scripts and the WWW browsing protection mechanisms employed by some anti-malware tools are often less than stellar. Nonetheless, it's an approach that I can vouch from experience will work, as long as one is very careful, across a wide range of WWW browsers running on various platforms.

For plug-ins, the disadvantages are similar. One has to ensure that every WWW browser has the plug-in, and it is rarely the case that one plug-in is available for all kinds of WWW browsers on all platforms.

I now use the second approach. It has the advantages, compared to PAC scripts and plug-ins, of being entirely browser-neutral, and only requiring debugging in one place (rather than in multiple WWW browsers of different types, including all of the built-in WWW browsers in tools like media players, hypertext help systems, desktop gadgets, automatic software update tools, and so forth).

Use the right tool for the job. The DNS is not that tool here.