Archive for May, 2010

Note the following applies to Windows Vista, but is probably easier on MacOS/Linux.

Is your hosts file becoming monstrous?  Do you have an alias or shortcut to your hosts file because you edit it so often?  Tired of manually adding every subdomain and domain you work on?

I was too when I thought there must be a better way.  And there was.

The general idea is this: by installing a local DNS nameserver in BIND, we can set up local development domains that look like regular domains on the internet. For real domains, we’ll just forward the requests on to a real nameserver.  This gives us a couple more benefits: 1) we can use the local nameserver as a caching nameserver to speed up DNS queries (in theory, I have not actually done this), and 2) we can choose to use any DNS service we wish, i.e. OpenDNS, or Google DNS.

Here are the steps.

  1. Follow these instructions on installing and configuring BIND and configuring a zone for your local domain.
    1. I installed BIND to C:\Windows\system32\dns.
    2. Here is my named.conf in its entirety.

      options {
          directory ";c:\windows\system32\dns\zones";
          allow-transfer { none; };
          forward only;
          forwarders {
              //; // OpenDNS
    ; // Google DNS
          query-source address * port 53;
      logging {
          channel queries_log {
              file "c:\windows\system32\dns\var\queries.log";
              print-severity yes;
              print-time yes;
          category queries { queries_log ; };
      zone "work.local" IN {
          type master;
          file "work.local.txt";
      key "rndc-key" {
          algorithm hmac-md5;
          secret "xxxxxxxxxxxxxxxxxxxxxxxx";
      controls {
          inet port 953
              allow {; } keys { "rndc-key"; };
    3. I created a zone file for my development domain work.local following this zone file example. Here is the zone file in its entirety.  Note the CNAME wildcard record.

      $TTL 86400
      @	IN SOA (
      			86400 )
      @		NS
      	IN A
      ns1	IN A
      www	IN A
      *	IN CNAME	www
  2. Start or restart the BIND service.
  3. Configure you network connection to use as your primary nameserver, instead of DHCP.  My IPv4 properties look like this:

    Set DNS nameserver to
  4. Flush the Windows DNS cache by running:

    C:\> ipconfig /flushdns
  5. Test BIND by pinging  If you have errors, you can uncomment the logging block in named.conf.
  6. Once that is working, create a VirtualHost in Apache for your development domain.  Thanks to VirtualDocumentRoot, we can map any number of subdomains to project roots.  Here is my VirtualHost block.

        ServerAlias *.work.local
        VirtualDocumentRoot "C:/_work/%1"
        <Directory  C:/_work>
            Options Indexes FollowSymLinks Includes ExecCGI
            AllowOverride All
            Order allow,deny
            Allow from all
  7. Start or restart Apache.
  8. Create a directory in C:\_work, for example, C:\_work\awesomeapp.  Create a test index.html file in that directory.
  9. You should now be able to go to in your browser and see your index.html file!

Now, you should be able to repeat step 8 for any new website you create!  No editing of hosts files, no bouncing the webserver!  Just create the project directory and it’s immediately available.

One other important note: Firefox has its own DNS cache independent of the OS.  For sanity, restarting Firefox resets its DNS cache. You can also permanently disable DNS caching in Firefox.

Well, it only took me 18 months, but I finally got around to cleaning up and publishing the Phing filters we use to automatically transform a static site into one that implements many of Yahoo’s Exceptional Performance Rules.  These filters, together with the Apache configurations in the README, implement the process outlined in this talk from php|works 2008:

To see it in action, first create an VirtualHost pointing to the mysite directory in the project as the web root.  Then run:

% phing optimize

which creates a parallel site in a build directory.  Point your VirtualHost to the new build directory to see the same site with the performance transformations.

You could run this Phing task in a continuous integration process as part of deployment.  You could run it at production deployment time, but it’s probably a good idea to run it at staging time in case it flubs on some CSS or HTML syntax that it is not expecting.

Note that there are other miscellaneous Phing tasks in that github project.  I threw these in there in case they could be of use to other Phing users.