The Domain Name System

Importing and Exporting BIND Databases

The data for standard primary zones are stored in database files that are compatible with BIND, making it convenient for you to move zones between BIND and Windows 2000 DNS servers. If you need to work with BIND, you will need to understand the formats of these files.

A BIND database file is required for each zone. The formats are different for forward and reverse lookup zones, so we'll need to consider them separately.

Additionally, BIND stores information about root name servers in a zone named CACHE. The format of the CACHE database file is similar to the format of a forward lookup database, but we will look at the CACHE file separately because of its particular significance.

Importing Data from BIND

If you have copies of the database files for BIND, it is easy to import the data into a zone that is hosted on a Windows 2000 DNS server. Refer back to the discussion about creating primary forward and reverse lookup zones and in particular to Figure 3.21.

In that dialog box, you have the option of supplying the name of a zone database file. Simply copy the BIND database files to the directory %systemroot%\system32\dns on the Windows 2000 Server and supply the name of the file when running the New Zone Wizard. When the zone is started, it will be initialized with data from the database file you supplied.

When importing the file, remember that BIND database files are created manually using a text editor. Administrators will have different styles for formatting these files, and you should review the files before attempting to import them to Windows 2000. However, the Windows DNS service should support all the features of BIND, and properly formatted resource records should import to Windows 2000 without problems.

To force an existing primary zone to import data from a text database file, do the following:

1. Place the file in the directory %SystemRoot%\system32\dns.

2. Open the properties for the zone and on the General properties tab, edit the Zone file name field so that it matches the name of the database file that is to be imported (refer to Figure 3.27).

3. Open the properties pages for the server. On the Advanced tab, select From file in the field Load zone data on startup (refer to Figure 3.14).

4. Restart the DNS service, or right-click the zone name in the object tree and select Reload from the context menu.

5. Reset the value of the Load zone data on startup field if you want to store zone data in the Registry or in Active Directory.

The above procedure works only with primary zones. Secondary zones by definition obtain data from primary zones.

Exporting Data to BIND

As mentioned earlier, the data for standard primary and secondary zones are stored in BIND-compatible files. You will have to do more work when exporting to BIND than when importing to Windows 2000. Keep the following things in mind when exporting to BIND:

• Remove any resource records from the database files that BIND does not understand. In particular, remove any WINS resource records.

• Do not place copies of secondary zone database files on the DNS servers. Let BIND build its own database files by transferring the zone from a primary.

• You will need to configure suitable boot configuration files for each server. Boot files are not created by Windows 2000 and are beyond the scope of this chapter.

• Don't forget to set up the root CACHE database file.

---

Note

You can obtain an up-to-date copy of the root domain database file by using FTP to retrieve the file /domain/named.root from FTP.RS.INTERNIC.NET.

---

To force the Windows 2000 DNS service to update the text database files from its active database, do the following:

1. Right-click a zone name in the DNS Management Console object tree.

2. Select Update Server Data File from the context menu.

BIND Database File Formats

BIND database files are text files that are read when the name service is started. The name service on a BIND DNS server is called the Name Daemon. On UNIX systems, a daemon is a background process similar to a service on Windows 2000. The Name Daemon service is invoked using the command named.

The following sections review the formats of the database files for forward lookup, reverse lookup, and root cache zones.

Forward Lookup Database Files

The following listing is a simple database file for a forward lookup zone.

; Database file pseudo-corp.com.dns for pseudo-corp.com zone.
;   Zone version: 25
;
@            IN SOA dc1.pseudo-corp.com. administrator.pseudo-
corp.com. (
              25      ; serial number
              900     ; refresh
              600     ; retry
              86400    ; expire
              3600    ) ; minimum TTL
;
; Zone NS records
;
@            NS  dc1.pseudo-corp.com.
@            NS  dc2.pseudo-corp.com.
;
; Delegated sub-zone: paris.pseudo-corp.com.
;
paris          NS  dc2.pseudo-corp.com.
; End delegation
;
; Zone records
;
@            MX  10  mail1.pseudo-corp.com.
dc1           A  10.1.0.2
dc2           A  10.1.0.3
mail1          A  10.1.0.25
router         A  10.1.0.1
www           A  10.1.0.200
            A  10.1.0.201
            A  10.1.0.203
www1          A  10.1.0.200
www2          A  10.1.0.201
www3          A  10.1.0.203

If you understand two critical things about the database file, it is easier to relate the listing back to our work with the Windows 2000 DNS server:

• Any text that follows a ; on a line is ignored. This convention enables administrators to format the file and insert comments.

• The @ sign means "this zone," that is, the zone defined by this database file. It has the same meaning as the "(same as parent folder)" notation in resource records on the Windows 2000 DNS server.

Address resource records require little explanation. It is clear, for example, that

www           A  10.1.0.200

is a Host Address resource record that maps a hostname to an IP address. By convention, only the hostname is included in an address RR. The domain itself is implied. Fields in the database records are separated by whitespace (spaces or tabs). Typically, administrators supply enough spaces so that columns line up nicely.

To interpret resource records that contain an @ symbol, remember that @ means "this zone." For example,

@            MX  10  mail1.pseudo-corp.com.

means that mail1.pseudo-corp.com is a mail exchanger for pseudo-corp.com, because this zone database defines pseudo-corp.com.

The Start of Authority (SOA) RR makes use of both the conventions mentioned previously. First, because it begins with an @, the RR is known to apply to the zone that is associated with the current file.

Second, remember that all text between a ; character and the end of a line is ignored. In the SOA record, helpful comments were added to explain the purposes of the various parameters. Without the comments, the RR would look like this:

@            IN SOA dc1.pseudo-corp.com. administrator.pseudo-
corp.com. (25 900 600 86400 3600)

That isn't very clear unless you are experienced enough with BIND to remember the explanations of the settings.

Zone delegation requires at least two RRs: a Name Server (NS) and an Address (A) record. The following RRs are sufficient to delegate authority for paris.pseudo-corp.com:

paris          NS  dc2.pseudo-corp.com.

and

dc2           A  10.1.0.3

If the name server were not a host in the pseudo-corp.com zone, we would need to supply its FQDN with something like this:

name1.paris.pseudo-corp.com.   A  10.1.0.3

Note that this FQDN ends with a period to make it crystal clear that it ends with the root domain. Without the trailing period, it would be placed in the current domain, and the name would be interpreted as name1.paris.pseudo-corp.com.pseudo-corp.com. I warned you early in the chapter that there would be at least one instance where the root domain needs to be explicitly indicated with a trailing period, and this is it.

You shouldn't have much trouble relating the RRs in the text database file to the ones we have discussed. BIND database files aren't all that difficult to work with, when you know a few tricks.

Reverse Lookup Database Files

Here is an example of a BIND database file for a reverse lookup zone:

;
; Database file 1.10.in-addr.arpa.dns for 1.10.in-addr.arpa zone.
;   Zone version: 9
;

@            IN SOA dc1.pseudo-corp.com. administrator.pseudo-
corp.com. (
              9      ; serial number
              900     ; refresh
              600     ; retry
              86400    ; expire
              3600    ) ; minimum TTL

;
; Zone NS records
;

@            NS  dc1.pseudo-corp.com.
@            NS  dc2.pseudo-corp.com.
dc2.pseudo-corp.com.  A  10.1.0.3

;
; Zone records
;

1.0           PTR  router.pseudo-corp.com.
2.0           PTR  dc1.pseudo-corp.com.
25.0          PTR  mail1.pseudo-corp.com.
3.0           PTR  dc2.pseudo-corp.com.

The file isn't all that different from a forward looking database except that the bulk of the RRs are PTR records. To interpret the PTR records in the example, remember that the IP addresses for these hosts begin with 10.1. Therefore the RR

2.0           PTR  dc1.pseudo-corp.com.

is a pointer for host 10.1.0.2. (Remember that, for reverse lookup zones, the octets in the IP address appear in reverse order.)

There are a couple other things to note here. Notice that a hostname in a PTR RR is a FQDN with an explicit trailing period. Also notice that the database file includes a Host Address RR that enables the DNS server to locate host dc2, which is configured with a secondary copy of the zone.

The Cache Database File

The Cache zone was initially intended to designate frequently used RRs that should be loaded into the DNS server's cache when it was started. In time, however, the purpose of the Cache zone was limited to containing RRs pertaining to the root domain servers.

For the Internet root domain, the cache database contains entries like the following for each of the 13 root name servers:

; formerly NS.INTERNIC.NET
;
.            3600000 IN NS  A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.   3600000   A   198.41.0.4