IIS Informant - 12 Jul 2000

This month, find answers to your questions about DNS naming, using CDO to email form results, mapping shares to a virtual directory, and the repercussions of turning off a default Web site.

Brett Hill

July 12, 2000

10 Min Read
ITPro Today logo in a gray background | ITPro Today

I'm trying to run my first Web server under Windows 2000. After I registered the domain with the InterNIC, I can access the site by IP address but not by DNS name. If I use a host-header-style setup in IIS, the site isn't even available by IP address. I'm using the default Web site. The Win2K domain is abc.com, but the registered DNS is xyz-web.com. Does the name difference have anything to do with it?

You can give your Web site a completely different domain name from your Win2K domain. In fact, you can make a good argument that the names need to be different so that users can't easily access your domain controller with less-than-helpful intentions. Because DNS is such a vital part of Win2K, naming a Win2K domain controller is much more important than it was with Windows NT 4.0.

Your problem is likely with the DNS server for your Web site. IIS administration books and training often overlook this problem, but the DNS server is clearly important to the effective operation of Web services. The first step to solving this problem is to register the domain. (If your Web site is http://www.abcdef.com, your domain is abcdef.com.) If you haven't registered a domain before, do so just to know what the process is. Prices range from $30 to $75 annually for the service. You can find a list of official registrars at http://www.internic.net/regist.html.

When you register a domain, you must provide the name and IP address of a primary and secondary DNS server. The primary DNS server is one that is "authoritative" for your domain, which means that it contains the Start of Authority record for your domain. Very often, this name server is the same one that contains the entries that associate your Web site with an IP address. In this case, the authoritative name server points to itself as the place for hosts in the domain to go for the IP address. Technically, the name server record points to itself.

Here's a quick overview of the process. Jane wants to place a $10,000 order with http://www.abcdef.com, so she types that address in her browser. (As the IIS administrator, you really want Jane to find the domain!) Typically, Jane's system needs to reference a DNS server to resolve http://www.abcdef.com to an IP address. Her system uses the DNS server that is set up in her TCP/IP settings. Informing Jane's TCP/IP setup of the IP address for a DNS server can be done manually, but generally, DHCP provides the DNS server address to a client computer. As it turns out, the DNS server that Jane is using has never heard of http://www.abcdef.com, so it can't provide an IP address. The DNS server now goes to work to resolve the name for Jane. The server queries other servers and, eventually, queries the DNS servers of the .com domains themselves (called root name servers). The .com root name servers contain the names and IP addresses of all authoritative name servers in the .com namespace. How does the DNS server know where to find the root name servers? The server names and IP addresses of the root name servers are well known and are installed with the DNS server.

Now, let's get back to our story. The root name server for the .com addresses provides the IP address of the authoritative name server that you provided for your domain. So, now the DNS server conducting the inquiry (the one that Jane's PC originally queried) asks the authoritative server for the IP address of a host called www in the domain abcdef.com. The querying DNS server receives the IP address of the Web server, which in turn hands the address back to Jane's computer. Her browser then connects with the Web server, and the company is $10,000 better off.

The great thing about DNS is that this process occurs quickly; your typical user has no idea it's going on, which is why you need to understand this process thoroughly. The definitive book on the topic is Paul Albitz and Cricket Liu, DNS and BIND (O'Reilly and Associates, 1998). Although the book focuses primarily on UNIX, DNS works the same in Windows, and the book is much easier to read than most technical books. It also helps you get a handle on what is different about Win2K DNS, and an understanding of the difference is essential to supporting Win2K networks. Go to http://www.dns.net for details about DNS.

So, now to your original question: What if this doesn't work? How can you tell what the problem is? Is it the Web server or DNS? To test DNS resolution, follow these steps:

  1. On the PC from which you're accessing the Web site, ping the Web site by name--in this case, www.abcdef.com. (If you're working behind a proxy server, this process is more complicated because you can't ping from there.)

  2. If the resulting IP address is the IP address of your Web server, your Web site is set up on the default Web site, and you aren't using host headers, then you should be able to enter the name in step 1 and access the Web site. Otherwise, carefully check your IIS setup for the site. Make sure the Web services are running. From your browser, try accessing the site by IP address to eliminate name resolution as a problem.

  3. If you received the wrong IP address, you have to update your DNS server. If you received the message Host not found, then your DNS server has no entry for your domain and can't find a DNS server that does. In this case, use ipconfig /all (Win2K or NT 4.0) or winipcfg (Windows 9x) to obtain the IP address of the DNS server you're using. (If you don't have one listed, that is most likely the problem.) Compare that address with the name server IP address that you registered as authoritative for your domain. If they aren't the same, go into your TCP/IP properties and enter the IP address of the authoritative DNS server; make sure this address is the first or only entry. (You might need to reboot your system depending on the OS you're using.)

  4. Ping the Web site again. If you still don't get the correct IP address, the problem is with the DNS server entries for your domain. You can take this one step further on a Win2K or NT PC by using Nslookup as follows:

    • At a command prompt, type nslookup. You'll connect with the first DNS server in your TCP/IP properties.

    • Type the complete name you're trying to find (e.g., www.abcdef.com). This process returns the correct address for the Web site.

Nslookup might work where Ping fails because some sites block ping to prevent Denial of Service (DoS) attacks of that nature. Nslookup is a great tool designed for querying the contents of a name server.

Another quick and easy test for DNS resolution is to use the HOSTS file to map the Web site to the correct IP address. When you do this, you take control of the name-resolution process and the client computer won't even use DNS (at least in Microsoft OSs using standard name resolution). This test confirms with certainty whether the Web server responds when properly accessed. If it works, then you definitely have a DNS-resolution problem.

I've set up an Active Server Pages (ASP) page to use Collaboration Data Objects (CDO) email to send the results of a form to a designated recipient. Everything works fine as long as the recipient isn't using an email address that is linked to the server's domain. For example, if the Web site is called http://www.b2bcommerce.com and I've set the form to send the results to orders@b2bcommerce.com, CDO email doesn't send the form. However, if I set the results of the form to go to orders@anywhere.com, the form goes successfully. What's wrong?

You can resolve this problem easily. Configure the local IIS SMTP server as follows:

  1. The local domain for the IIS SMTP server is the domain of the SMTP address (i.e., server.b2bcommerce.com). Note that this domain can be different from the Web address. Also note that the server name precedes b2bcommerce.com.

  2. Define a remote domain called b2bcommerce.com. In the remote domain, specify the name or IP address of the mail server that receives mail for b2bcommerce.com. In IIS 4.0, this server is called the route domain. In IIS 5.0, this server is called Smart Host (not the SMTP properties Smart Host, but a specific smart host for this particular routing domain). In the Win2K SMTP server, you can simply let the SMTP server use standard DNS lookup of the mail exchanger (MX) record to resolve the domain name and forward mail to that address.

In this setup, the SMTP server takes the message addressed to b2bcommerce.com and routes it to the remote server.

Be sure to define a DNS server for the IIS machine. A good place to check whether a DNS problem exists is in the Queues directory. If the SMTP service is trying to deliver messages, it will store those messages in the Queues directory with an .rtr extension. If .rtr files are associated with the unsent messages, examine the files for errors. A DNS lookup failure will say No path found from .

(Thanks to Wesley H. Peace, contributing author of Microsoft Exchange Server 5.5 Unleashed—SAMS, 1998—for this question and answer.)

I created a virtual directory and mapped it to a shared resource on a remote NT 4.0 server. Permissions on the remote folder are Everyone, Full Control for both NTFS and Share. For the virtual directory Network Directory Security Credential, I used the Anonymous account, IUSR_webserver. Afterwards, I received the error message Unable to enumerate files and directories, because the following error occurred: Logon failure: unknown username or bad password. Why am I receiving this error?

The error message you received means that IIS wasn't able to access the share that maps to the virtual directory with the credentials you provided. When you enter the Network Directory Security Credential, you're telling IIS, "When you access this folder, use this username and password," which means that the remote system must be able to authenticate that name and the user must have permissions to the folder. If you specify the IUSR account, that IUSR account must exist on both the IIS server and the remote system to which the virtual directory is mapped and have the same password.

The only exception is if your IIS server is on a domain controller (not recommended) and the remote system is part of the same domain. Consider using an account other than the IUSR account as the authenticating account for the virtual directory. That way, you can create the account on the remote system, assign it the permissions you require, and keep the administration of that account—which is used specifically for this purpose—separate from IUSR permissions.

I'm running NT 4.0 (PDC, one internal-addresses NIC, one registered-address NIC, Service Pack 6a—SP6a) with IIS 4.0, Microsoft Exchange Server 5.5 (SP2), and Microsoft Proxy Server 2.0 (SP1 and an open port 80 for Web page hosting). When I set up my first Web site as the default Web site, everything worked fine. Later, I added a second site and moved the first site from the default site. Both sites now use host headers. I then stopped the default Web site. I contacted my ISP to set up DNS, and I've properly registered the domains and primary DNS server.

Since I stopped the default Web site, no one behind the proxy server can access the Internet. When I stop those two sites and start the default site, everyone can access the Internet. Why can't I turn off the default Web site?

When you install Proxy Server, it loads as an Internet Server API (ISAPI) filter on the default Web site. As a result, you can't turn off the default Web site on the proxy server without effectively disabling the proxy server. I don't recommend having your proxy server also serve as your IIS server because that defeats one of the key purposes for having the proxy server, which is to prevent your Web server from touching the Internet and thereby increase security. You can, however, have multiple Web sites on the proxy server: Just don't disable the default Web site.

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like