|
|
DNS, like most everything else in WS03, is administered with an MMC snap-in, as shown in Figure 8-11. The DNS MMC snap-in can be opened by choosing Start | Administrative Tools | DNS.
Figure 8-11: The DNS MMC
The DNS MMC lists three components in the left pane under the name of your computer: Event Viewer, Forward Lookup Zones, and Reverse Lookup Zones.
The Event Viewer section includes the DNS Events portion of the regular event viewer. This makes the DNS MMC snap-in your one-stop shop for DNS management. The management options for the Event Viewer section mirror the options in the regular event viewer.
The Forward Lookup Zones section list all of the computer's Forward lookup zones for regular DNS domain entries (A, SRV, MX, and so on).
Here's how to create a forward lookup zone:
Open the DNS MMC snap-in.
Right-click Forward Lookup Zones in the left pane, and choose New Zone from the pop-up menu.
The New Zone Wizard opens. Click Next.
Choose the type of zone you want to create, and then check the box to Store In Active Directory (if available).
Type in the zone name.
Choose the name of the file you want to use (if not AD).
Choose whether or not to allow dynamic updates.
Click Finish.
Now that you have created a forward lookup zone, you can create some records. The Address record is the most common type, so we'll start with that:
Open the DNS MMC snap-in.
Right-click the zone to which you want to add records, and choose New Other Records. You'll see a list of all the record types you can put in this zone.
Choose the record type you want to add. For this example, choose Host(A).
Click Create Record. The New Resource Record window appears.
Type in the name of the host. If you're creating a web site, more often than not, you'll choose WWW as the name of the host.
Type in the IP address of the host.
If the reverse lookup zone exists, and you want to update the reverse entry, check the box, and it will be automatically updated.
Click OK.
Click Done to close the Resource Record type window.
Reverse lookup zones contain the IP address to name mappings that allow clients to find the name associated with an IP address. This helps close the loop with name resolution, because you can resolve a name to an IP address with a forward lookup, and resolve that IP address back to a name with the reverse lookup. This is important for enabling the server to verify clients and servers, because forward and reverse lookup zones are administered separately. Someone can represent to be a certain name, but since reverse addresses are delegated separately, you can't fake the reverse. If they don't match up, it may be a bad thing.
Tip | It's not necessarily a bad thing, however, if reverse and forward addresses don't match up. Clients of an ISP often use generic reverse lookup names. This comes into play for commercial domains and especially for e-mail. Many e-mail servers will reject mail if the sender's e-mail server doesn't match up correctly with forward and reverse DNS. |
Let's look at an example of how this works. Let's say that someone is representing to be mail.someisp.com and their IP address is 55.56.57.58. You check the reverse mapping and it turns out that IP belongs to spamalot.badmail.com. It's a pretty safe bet that there's something wrong. This is where reverse DNS comes into the picture.
Reverse lookup zones are similar to forward lookup zones, with a couple of important differences. All IP addresses are part of one domain called in-addr.arpa. This domain is authoritative for all IP address to name lookups. These domains are delegated through IP address blocks. For example, for the class C IP block of 192.168.0.0 / 24 (192.168.0.0 - 192.168.0.255), the reverse lookup zone in DNS would be 0.168.192.in-addr.arpa. This is because the reverse zones are designated backward. The network number portion of the IP address makes up the zone, and the host (node) numbers make up the PTR records.
Here are some examples:
IP Block | Subnet Mask | Reverse Zone |
---|---|---|
10.0.0.0 | 255.0.0.0 | 10.in-addr.arpa |
145.162.0.0 | 255.255.0.0 | 162.145.in-addr.arpa |
Reverse DNS is delegated by an IP block, from the top block on down to the block you are using. This means that class A addresses are delegated from the first octet, class B addresses are delegated from the second octet, and class C addresses are delegated from the third octet.
Let's trace this through the path reverse DNS takes to resolve a name from IP:
A client wants to find out who a certain IP address is-say, 55.66.77.88. The client asks the DNS server 'Who is 88.77.66.55.in-addr.arpa?'
Since this is a class A address, start with the first octet. The DNS server will start by asking the root servers 'Who is 88.77.66.55.in-addr.arpa?'
The root server responds that it doesn't know, but 0.0.0.55.in-addr.arpa is delegated to MongoISP.
The DNS server then asks MongoISP's DNS server 'Who is 88.77.66.55.in- addr.arpa?'
MongoISP's DNS server responds that it doesn't know, but it does own 0.0.0.55.in-addr.arpa and has delegated 0.0.66.55.in-addr.arpa to MidTierISP.
The DNS server then asks MidTierISP's DNS server 'Who 88.77.66.55.in- addr.arpa?'
MidTierISP's DNS server responds that it doesn't know, but it does own 0.0.66.55.in-addr.arpa and has delegated 0.77.66.55.in-addr.arpa to HomeTownISP.
The DNS server then asks HomeTownISP's DNS server 'Who 88.77.66.55.in- addr.arpa?'
HomeTownISP's DNS server responds that it knows exactly who that is: it belongs to mail.somebody.com.
Because they are delegated from the root name servers on down, reverse delegations must be accomplished through 'official' processes. This means that the root server tells the client the next server to go through in the name resolution. Since each server down the line has to be officially designated as the proper server for that reverse DNS zone, it's much harder to fake a designation.
If you're interested in diving into reverse DNS further, consult RFC 2317, entitled 'Classless IN-ADDR.ARPA Delegation.'
This is a complicated process, because delegating uses the octet level of the IP address, especially if the subnet mask doesn't fall along clean subnet lines. However, you can delegate any subnet you want.
For example, the reverse DNS zone for the 192.168.0.128 / 26 subnet is 128/26.0.168.192.in-addr.arpa. The 128 tells you to start on that subnet, with a 26-bit subnet mask. As you can see, it can get pretty involved.
Let's step through the process of creating a reverse lookup zone.
Open the DNS MMC snap-in.
Right-click the server on which you wish to create the zone, and then choose New Zone.
Select the type of zone you want to create-for this example, choose Standard Primary (Not in AD).
Choose to create a Reverse Lookup Zone.
Type in the network ID of the zone you want to create. For this example, use 192.168.0. Notice how it doesn't allow you to type in the fourth octet? That's because you can't do a reverse DNS zone with that octet. In fact, if you want to create a classless (subnetted) reverse zone, you need to type in the name, instead of using the Network ID portion of the wizard.
You can then choose to create a zone with the given filename, choose a new one, or choose to use an existing file. Keep in mind that if you create a classless zone, a forward slash is not a valid character for Windows filenames. Use the dash (-) instead. The benefit to using an existing file is that you can use an already set up DNS file with all the records.
Choose whether or not you want to allow dynamic updates. If you are not using an AD integrated zone, you cannot allow only secure dynamic updates. Again, this is because you can't set ACLs on standard zones. You can, however, allow dynamic updates from any client.
Click Finish, and you're done.
Now that you have created a zone, you can create records inside it. For this zone, all you really care about are PTR records and delegations.
After you've created the reverse zone, you can add the PTR records. Here's how to add the reverse lookup records:
Highlight the zone in which you wish to create the records.
Choose Action | New Pointer (PTR).
Type in the host portion of the IP Address in the text box.
Type in the host name.
Click OK.
You now have a PTR record for your host.
Now let's walk through delegating a reverse lookup zone in DNS:
Highlight the reverse lookup zone for which you want to create a delegation.
Choose Action | New Delegation.
Type in the number of the subnet you want to delegate. For example, if you have the 10.10.0.0/16 subnet, and you wish to delegate 10.10.5.0/24, you would type 5.
Click Next.
Add the name(s) of the DNS servers you want to host the zone by clicking the Add button.
Click Next.
Click Finish to exit the wizard.
You have created a delegation to that name server for this zone. You also need to create that zone on that server. What the record here does is point a client to that name server for resolution as the client resolves a DNS name.
|
|