Router Hostname and DNS Settings

During the initial System Configuration Dialog, we gave our router a hostname of toronto-1. This can be changed using the hostname command. For example, to change the hostname of this router to cisco2501, enter the following from global configuration mode:

toronto-1(config)#hostname cisco2501
cisco2501(config)#

Notice that the command prompt name immediately changes to cisco2501. The hostname associated with the router is there to give you perspective on which router you are connected to. Unless you have an entry set up on a DNS server that maps this name to one of the router’s IP addresses (or appropriate host file entries), you still won’t be able to telnet into the router using its hostname.

By default, a Cisco router will always assume that any unrecognized command is the name of a host that you wish to initiate a telnet session with. Because of this, it will attempt to resolve the name to an IP address using DNS. For example, consider what happens when I enter “helpme” at the prompt and press enter.

cisco2501#helpme
Translating "helpme"...domain server (255.255.255.255)
% Unknown command or computer name, or unable to find computer address
cisco2501#

If you want to avoid this frustrating and somewhat annoying action, you can always configure the router to not perform a DNS lookup on unrecognized commands using the no ip domain-lookup command.

cisco2501(config)#no ip domain-lookup
cisco2501(config)#^Z
cisco2501#helpme
Translating "helpme"
% Unknown command or computer name, or unable to find computer address
cisco2501#

You will probably get to a point where you’ll want to configure a router to resolve names, since these are generally easier to remember (and to input) than IP addresses. If you decide to do this, you have two choices – you can either configure your router to use DNS, or you can use a locally configured hosts table. If you’re familiar with the HOSTS file from UNIX or Windows environments, this is almost exactly the same – a group of static name-to-IP address entries that you manually define.

To configure a router to use a local hosts table, you will need to be in global configuration mode. In the example below, I have created entries for 2 different routers, named accra and montreal, using the ip host command.

cisco2501(config)#ip host accra 192.168.1.45
cisco2501(config)#ip host montreal 192.168.36.2
cisco2501(config)#^Z
cisco2501#show hosts
Default domain is not set
Name/address lookup uses static mappings
Host Flags Age Type Address(es)
accra (perm, OK) 0 IP 192.168.1.45
montreal (perm, OK) 0 IP 192.168.36.2

The show hosts command is used to view the hosts table. The table shows us that the entries are permanent, along with hostnames and associated IP addresses. To be honest, creating a hosts table on each an every router would be painful – you are much better off using DNS if it’s available.

Configuring a router to use a DNS server to resolve hostnames isn’t much more difficult. Just remember that entries for the hosts and their associated IP addresses need to be entered in DNS prior to the router being able to resolve them. There are a couple of steps involved in setting up a router to query DNS. As a first step, we need to reinstate the ip domain lookup command that we turned off earlier.

cisco2501(config)#ip domain-lookup
cisco2501(config)#ip name-server 192.168.1.100
cisco2501(config)#ip domain-name 2000trainers.com

So what just happened? Well, we reinstated domain lookup to begin with. The second step set the IP address of the DNS server that the router will query. The final command set the domain name of the router to 2000trainers.com. This domain name will be appended to hostnames when we don’t provide a fully qualified domain name (FQDN). For example, an attempt to resolve the hostname accra would be sent to the DNS server as a request to resolve accra.2000trainers.com.

Domain Renaming and Repositioning

In the Windows 2000 version of Active Directory, it was not possible to rename domains without demoting all domain controllers, which effectively destroyed the domain. In Windows Server 2003, domains can be renamed, as long as the forest in which they exist are configured to the Windows Server 2003 forest functional level. Of course, this means that you cannot rename a domain that includes either Windows 2000 or Windows NT 4.0 domain controllers, since the Windows Server 2003 forest functional level only supports Windows Server 2003 domain controllers. The tool to rename Windows Server 2003 domains is named RENDOM, and is found in the Valueadd\Msft\Mgmt\Domren folder on the Windows Server 2003 CD.

Along the same lines, Windows Server 2003 also allows you to rename individual domain controllers with a new computer name. In Windows 2000 Active Directory, this was only possible if you first used DCPROMO to demote a domain controller back to a member server, changed the name, and then re-promoted it. Renaming a domain controller is only possible if a domain is configured to the Windows Server 2003 domain functional level.

Renaming a Windows Server 2003 domain controller is handled differently than the traditional method (via the System tool in Control Panel). Instead, the NETDOM command line utility is used to handle the domain controller renaming function. For example, the series of commands to rename a domain controller from server1.company.com to database.company.com would be:

C:\>netdom computername server1.company.com /add:database.company.com

C:\>netdom computername server1.company.com /makeprimary:database.company.com

Then, after rebooting the server:

C:\>netdom computername database.company.com /remove:server1.company.com

Finally, Windows Server 2003 also supports the ability to reposition domains within an Active Directory forest. For example, imagine that you originally implemented each domain as its own forest, and then decided that you instead wanted to change the structure that such all domains fell into the same DNS namespace, as part of a single tree. This is now possible, but only if the forest is configured to the Windows Server 2003 functional level. Although that does present a limitation, the ability to reposition domains is a great feature, especially if you managed to inherit responsibility for a forest that was not well designed in the first place.

In the same manner as renaming domains, domain repositioning in Windows Server 2003 Active Directory environments is also accomplished by using the RENDOM utility.

Exchange, DNS, and Internet Email

As most of you know, I haven’t been churning out the articles lately. I am in a little bit of a slump, and decided to do a light article this week to help me get back into the swing of things. I decided that one of the best places to start would be with one of the most frequent problems I see people having with Exchange 2000. The question that I probably see the most relates to setting up Exchange 2000 to access the internet. What I am going to talk about in this article is how to setup DNS to allow your Exchange 2000 server to access the internet, as well as how to use Nslookup to troubleshoot DNS settings. Obviously, I can’t cover all possible configurations, but I am going to try and cover the most basic configuration.

I am going to go with the understanding that most of you already have your Exchange Server installations completed. If not, then this isn’t the article that will cover that. For installing Exchange, take a look at one of my earlier articles. Now once you have Exchange 2000 installed, there isn’t much else you need to do on the Exchange side. Exchange is tightly integrated with Active Directory, but more importantly, it is very tightly integrated with IIS as well. This integration allows Exchange 2000 to connect to the internet without requiring any connectors to be installed or configured. This one is a little different, because previous versions of Exchange required a connector of some type to be configured. For example, Exchange 5.5 required an Internet Mail Service Connector (IMS) in order to access the internet.

Now there are a couple of different ways that we could configure DNS for our Exchange 2000 server. For example, I might be running DSL, with a firewall like Proxy 2.0 or ISA Server in place. This would mean that we would have a public IP on the external network card of the firewall. Now, if we were running our own DNS server, we could simply put the appropriate Host (A) and Mail Exchanger (MX) records into our DNS database. Now, when a client queried our DNS server, the record for our Exchange 2000 server would be returned, and the client would be able to communicate with our server. This is a simple configuration from the standpoint of DNS, although it would require additional work in order to get the Exchange Server communicating from behind the firewall. For additional information on how to configure this, see Q276388 and Q308599.

However, judging from the questions that I am getting, the majority of you aren’t setting up your servers in this type of environment. The majority of the questions that I am seeing are centered around small companies that are running a single Exchange 2000 server, and running their own DNS servers for internal purposes, but using an ISP for external name resolution. Although this situation is a little more complicated than our previous example, it is by no means impossible. Probably the biggest problem facing most people is a lack of understanding on how DNS works. For this, I recommend reading DNS and BIND, by Paul Albitz and Cricket Liu. You can find this book just about any place that sells books on technology. Another good resource would be the Windows 2000 help files, as well as the Windows 2000 Resource Kit.

Now lets get back to our problem. We have our Exchange 2000 Server installed, we have our internal DNS working, taking care of Active Directory and all its needs. So how do we configure it to allow our internal clients to be able to send email out to the internet, and also to allow internet users to send email to our internal users?

The first thing that we need to take a look at is how do we get our email out to the internet? In this case, setting up our internal DNS server to forward requests that it can’t handle to our ISP’s DNS server should do the trick. So what I would need to do would be to go into the DNS MMC, right click on the DNS server object, and go to properties, and then select the Forwarders tab. I would type in the address or addresses of my ISP’s DNS server(s), clicking add after each one. Now my DNS server will simply send requests that it can’t resolve out to my ISP’s DNS Server. This will allow my clients to get their email out to the internet, but at this point, I am only halfway done. I still need some way to give users access to my Exchange server. The trick here is that my Exchange server is running on my internal network, probably running on a Private IP address. So let’s take a look at how we can accomplish this task.

As a first step, we have to add the appropriate MX and A records to our ISP’s DNS Server. In this case, the records would point to the public IP for our company, typically the external interface of our firewall. Now, we would need to use something like Network Address Translation (NAT) in order to convert the incoming request and redirect it to our Exchange server. In my earlier example using ISA server, publishing Exchange from behind the ISA server allows you to accomplish this task with a minimal of effort, because ISA will forward the requests for Exchange to the appropriate address, allowing external clients access to our internal Exchange server.

Given that we have configured everything correctly, our internal clients should be capable if sending and receiving both internal and internet email. But how do we know that we setup DNS correctly? Enter Nslookup. Nslookup is a troubleshooting utility that allows us to query a DNS database for the presence of appropriate records, amongst other things. Now, for internal DNS, we can simply open up the DNS MMC console and verify that we have correctly configured the Forward and Reverse Lookup Zones. This is easy enough, because we are in charge of these zones, we manage, create and delete them. But what about our ISP’s DNS database? How do you know that they have correctly configured your A and MX records. The answer would be to do a simple query of their DNS database using Nslookup. From Windows NT 4.0, 2000, and XP, simply drop to a command prompt and type in Nslookup

Once you hit enter, you can now query the DNS database. In my case, I have typed in that I am looking for an MX record. The second option tells the Nslookup utility what domain name I am looking for. In this case, it is my business domain, Bellcs.com. The screen would look like this;

Figure

You can also see from looking at the second screen shot that I am querying my ISP’s DNS server, which is 4.2.2.2. However, this ISP isn’t authoritative for this particular domain name, as you can see from the reply that has been returned. It does show that I do have a configured Mail Server, as well as the Name Servers for my domain.

So this is how I can see what is in my ISP’s DNS database, without having access to the physical DNS server. Obviously, there is a lot more to Nslookup than what I have shown here. For more information about this utility, simply type Nslookup and press Enter. Then type help and press Enter. You can also lookup Nslookup in Windows 2000 Help, or online at Technet.

That should just about