Do you run several web sites with SSL certificates and multiple domain names? Do you test you web applications before deployment? Or you just hope that it all works after heroic system administrator puts the fix on the live server... Wouldn't it be wonderful if you could fully test your web sites in the development shop before deployment to production! Test all of it: virtual hosts, domain names, and SSL certificates? This article teaches you how to do it.

Why it is difficult to test web applications in house?
Let’s say you currently host a web site at http://www.mybigapp.com. If you fire up the browser and type in this URL you will access your production server. This is great. But, when developers have a new version ready for you to try out it will be installed on a test machine in the office. And everyone can try it out using IP address inside your office, say http://192.168.1.25, or http://testmachine1/. This setup is great as it allows everyone to test things out, but it has severe problems as well.

Some of the features, like SSL certificates, won’t work on the test web site. Browser will complain that certificate is invalid. Many automation tools will refuse to test the site for the same reason. This happens because domain name in the certificate (www.mybigapp.com) does not match the server name typed into the browser (192.168.1.25, testmachine1).

Many other features of your web site that rely on DSN will not work properly as well. DNS is involved in more places then you think. Any place that uses domain name is in jeopardy:

• SSL certificates
• hardcoded absolute URL’s
• redirect rules that use absolute URL’s
• <base> tags in HTML documents that requires absolute URL
• custom look-and-feel of your site that depends on a virtual host name domain name
• browser caching policy and cookies
• software load-balancing and fail-over

All of these problems make it difficult, if not impossible, to test web applications in your office before they are deployed in production.

Use DNS server to help your testing
This is where Domain Name Server (DNS) will come in handy. You usually think of DNS server only when you need to point a domain name (www.mybigapp.com) to a IP address of a server in a hosting center. Or, if you have a Microsoft Windows Domain, you probably have a DNS server installed in your domain controller.

But DNS can be effectively used for testing web applications. You can install a separate DNS server on you local network specifically for testing. This DNS server should be configured to temporarily point domain name www.mybigapp.com to your office test server at 192.168.1.25. From this point on, your testing team can use www.mybigapp.com name and will arrive to the test server, instead of production. All SSL certificates will now work properly - domain name in the browser matches domain name in the certificate.

Walkthroughs
This is how you would install a DNS server and configure it for the testing of your web applications:

• take any Windows 2000 Pro, XP Pro, 20003 Web Edition; DNS server as an optional component and can be installed from a control panel
• select a computer on your office network and install a DNS server on it (let’s say you picked 192.168.1.7); this computer can be a part of a domain at can itself use DNS server on a primary domain controller
• under the "Forward Lookup Zones" create a new zone with name "mybigapp.com"
• in the above zone add a host with a name "www.mybigapp.com" that points to IP address of the test server, i.e. 192.168.1.25
• this change will take couple of minutes to take effect

This is how you would access web sites on the production and test servers:

• login to a computer from where you would like to run a test
• fire up the browser, type in www.mybigapp.com - now you are looking at the pages on your production server
• go to TCP/IP properties and change a DNS server to 192.168.1.7
• fire up the browser, type in www.mybigapp.com - now you are looking at the pages on your test server