Let's configure the first of Movie U.' S name servers.
How to configure a DNS Stub Zone in Windows Server. Stub Zones are a DNS feature introduced in Windows Server 2003. A Stub Zones. Click Next on the Zone File. When a Stub Zone is configured it will contain an entire list of Name Server (NS) records from the other domain. These records are referred to as “Glue A records”. One of the advantages to using a Stub Zone over a Secondary is the transfer of records only includes the glue A record (see Figure 1), where as a Secondary will transfer the entire zone database (see Figure 2).
We'll use the DNS console for most of this process, so start it up if you haven't already done so. You don't have to run the DNS console on the machine running the name server, but for now it's easier if you do. You'll also need to have Administrator privileges to use the DNS console; otherwise, you'll only be able to start the application, not manage any name servers with it. 4.4.1 Adding a New Server to the DNS Console The first step is configuring the DNS console to manage the primary master name server for your zone. The primary master for a zone?also called just the primary?stores information about the zone on its disk.
You make all changes to your zone on the primary master. Select Action Connect To DNS Server and specify where the name server you want to manage?the primary master?is running. As you can see in Figure 4-9, you can choose either the local machine or specify a name server running somewhere else. If the name server isn't local, enter its name or IP address. Leave the box checked, which causes the DNS console to immediately contact the server to obtain its status and a list of any zones it might already be authoritative for. Specifying the location of a name server to manage The DNS console adds an icon in the left pane for that name server, as in Figure 4-10.
The DNS console with a new server It's important to understand what we just did here. We told the DNS console about a name server for it to manage and it added that name server to its configuration. The DNS console did not start the name server on the target machine. If the name server isn't already installed and running, the DNS console can't manage it and will complain with the message, 'The server is unavailable.
Would you like to add it anyway?' Selecting Connect to DNS Server adds that name server to the list of servers the DNS console knows about. As you might expect, selecting the server and choosing Action Delete (or just pressing the Delete key) removes the server from the DNS console's configuration but doesn't change anything on the name server itself. The server will still be running?you can use Connect to DNS Server to add it, and you'll be right back where you started. 4.4.2 Creating a New Zone Now it's time to create the movie.edu zone. Select the name server on the left where you want to create the zone. (There's only one server now, terminator, but the DNS console could know about multiple servers.) Choose Action New Zone.
You'll see the New Zone Wizard, as in Figure 4-11. New Zone Wizard, first window To continue, click Next. In the next window (see Figure 4-12), you have three choices for the type of zone: Primary zone, Secondary zone, and Stub zone. For now, choose Primary zone and click Next. Notice that the option to store this zone's data in Active Directory is greyed out. Microsoft calls this feature Active Directory integration and we'll talk about it more in Chapter 8. New Zone Wizard, second window Now you need to choose whether this is a forward- or reverse-mapping zone, as shown in Figure 4-13.
Movie.edu is, of course, a forward-mapping zone, so make that selection and click Next. New Zone Wizard, third window Getting tired of all these windows yet? In the next one, shown in Figure 4-14, type the domain name of the zone, which is movie.edu.
New Zone Wizard, fourth window Now you need to specify the file that will hold all the zone information, as shown in Figure 4-15. New Zone Wizard, fifth window The zone file, also called a zone datafile, is the zone's permanent storage location. It's the file on the name server's disk where all the information about the zone is stored: it contains all the zone's resource records. Other name servers require you to edit the zone datafile to make changes to the zone, but the DNS console allows you to avoid editing the file by hand. As a result, you probably won't see the zone datafiles very much. We'll talk about their format later in this chapter.
Even if you won't be looking at it often, you need to specify a zone datafile name when you create a zone. The server expects these files to be in%SystemRoot% System32 DNS. Microsoft's suggested naming convention uses the domain name of the zone followed by the.dns extension. (Notice that the DNS console has filled in the filename based on the zone name.) You can name the zone file whatever you want, but as long as the DNS console fills in the field for you, we recommend sticking with its suggestion. You may be familiar with other naming conventions, such as db.
Followed by the zone's domain name (e.g., db.movie.edu). In fact, that's the recommendation in our sister book, DNS and BIND. In the case of the DNS console, however, it's best to go along with Microsoft's default.dns extension. When you've entered a filename (or left the automatically chosen name alone), click Next to display the window shown in Figure 4-16, which asks you to choose this zone's policy for dynamic updates.
Dynamic updates are a relatively recent extension to the DNS protocol that we describe in detail in Chapter 11. Briefly, they allow another entity?such as a domain controller or a DHCP server?to update the contents of a zone by sending a message to the name server over the network. The alternative (and traditional) way to make changes to the zone involves using the DNS console as we're about to describe. As you might guess, allowing just anyone to send messages to your name server to change your zone is a significant security risk! That's why the DNS console asks you up front, when creating the zone, how you want to handle dynamic updates. Some Windows components, such as domain controllers and DHCP servers, use dynamic updates to keep DNS information up to date, so it's possible you'll want to enable this feature eventually.
But for now, check the third option, Do not allow dynamic updates, to leave dynamic update disabled while we set things up. New Zone Wizard, sixth window Click Next and you'll see the confirmation window shown in Figure 4-17.
New Zone Wizard confirmation window Click Finish to create the zone. If we double-click on terminator in the left pane, then double-click on Forward Lookup Zones and select the movie.edu zone, we see a window like the one pictured in Figure 4-18. The DNS console has created the zone and a few resource records. Let's talk about them one by one.
The DNS console with a new zone 4.4.2.1 The SOA record The first record displayed is the start of authority, or SOA, resource record for the movie.edu zone. It's a little tricky to see that the name of this record is really movie.edu, since the DNS console displays (same as parent folder) in the Name column. You need to look at the domain name selected in the left pane to know the domain name of this resource record. The SOA record indicates that this name server is the best source of information for the data within this zone.
Our name server is authoritative for the movie.edu zone because of the SOA record. An SOA record is required in each zone, and there can be one, and only one, SOA record in a zone. Double-click the SOA record to view its details. You'll see a window like the one in Figure 4-19. The movie.edu SOA record Let's skip that first field, Serial number, for now?don't worry, we'll cover it later in the chapter?and go on to the next field.
The second field is the name of the primary master name server for this zone. (You may hear it called the MNAME field, which is its official name.) The third field contains the email address of the person in charge of the zone (to turn this field into an email address, you replace the first dot with an at sign, @).
The DNS console defaults to a username of hostmaster, but in other zones you might see root, postmaster, or administrator as the email address. Name servers won't use these names?they are meant for human consumption. If you notice a problem in someone's zone, you can send an email message to the listed email address. Most of the remaining fields are for use by secondary name servers (also known as slave name servers) and are discussed when we introduce secondary name servers later in this chapter. For now, assume these are reasonable values. 4.4.2.2 The NS record The next record is an NS (name server) resource record.
There should be one NS record for each name server authoritative for the zone. Like the SOA record, NS records are attached to the zone's domain name. In our example, the NS records are attached to movie.edu. Right now there's only one name server (the primary master), but as we configure secondary name servers, we'll add NS records. The DNS console created an NS record for terminator because it's a name server?the primary master name server?for movie.edu.
4.4.2.3 The A record The final automatically created record is an address record or A record. Address records fulfill the main purpose of DNS: they provide name-to-address mapping. Each A record maps a domain name, like terminator.movie.edu, to an IP address, like 192.249.249.3. Every NS record needs a corresponding A record in some zone. Think about it: an NS record says, 'To find out information about this zone, go to this name server.' To use the NS record, you need the IP address of the name server it specifies.
In this case, the name of the name server, terminator.movie.edu, is contained in the movie.edu zone we just created, so the DNS console automatically created the A record for terminator.movie.edu to specify its IP address. When you create a new zone, the DNS console creates an address record for the primary name server. It uses the hostname configured in the primary master's DNS configuration. Note that some abbreviating is going on in the DNS console's display. The DNS console displays only terminator, but the fully qualified domain name of this host is terminator.movie.edu.
The DNS console normally displays a relative (that is, abbreviated) domain name on the right, so you have to look at what zone or domain is selected on the left to construct the fully qualified domain name. And recall that when records are attached to the name of the zone (which is the case for the SOA and NS records here), the DNS console displays the somewhat cryptic phrase (same as parent folder) in the Name column. You're probably anxious to add resource records for the rest of your zone, but it's best to create the reverse-mapping ( in-addr.arpa) zones first.
4.4.3 Creating a New Reverse-Mapping Zone Zones like movie.edu handle mapping names to addresses using A records. But mapping addresses back to names?reverse mapping?is just as important.
As you may recall from Chapter 2, a special portion of the namespace, the in-addr.arpa domain, is designated for reverse mapping. There's one domain name in in-addr.arpa for every possible IP address, and PTR (pointer) records attached to a domain name provide the actual reverse mapping. Just think of a PTR record as the opposite of an A record. So after we create movie.edu, we're not done. Has two /24 networks, 192.249.249/24 and 192.253.253/24.
We need to create the corresponding in-addr.arpa zones for reverse mapping with the DNS console: 249.249.192.in-addr.arpa and 253.253.192.in-addr.arpa. The process for creating an in-addr.arpa zone is the same as that for creating any other zone. Select terminator in the left pane and choose Action New Zone. Follow the prompts in the New Zone Wizard as we did earlier, except this time choose Reverse lookup zone in the third window.
Figure 4-20 shows the fourth window of the New Zone Wizard when creating a reverse-mapping zone. Specifying the network number or name of a reverse-mapping zone We specified the network number (see the selected field), and the DNS console automatically calculated the zone name (see the grayed-out field). Click Next and the wizard concludes as shown earlier.
Select the newly created zone in the left pane to see its contents in the right pane. Note that, just as it did with the movie.edu zone, the DNS console automatically creates the SOA record and an NS record. For Movie U., we'll repeat this process to create the 253.253.192.in-addr.arpa zone.
You create in-addr.arpa zones according to the networks you have. Usually there's one in-addr.arpa zone per /24 (or smaller) network. Larger networks are often broken into several in-addr.arpa zones to make management easier. The zones usually correspond to subnets. This topic is covered in more detail in Chapter 10. 4.4.4 Adding Resource Records Now that we've created Movie U.'
S zones, we can add information about all its machines. Each machine requires two resource records: an A record in the movie.edu zone to provide name-to-address mapping and a PTR record in the appropriate in-addr.arpa zone to provide address-to-name mapping. Adding the A record is intuitive, but it's easy to forget about the PTR record. The DNS console makes the job easier with the New Host command, which creates an A record and a PTR record in one pass. Select a forward-mapping zone (like movie.edu) and choose Action New Host (A). Enter the name of the host and its IP address.
To create the PTR record as well, you also need to check the Create associated pointer (PTR) record box. The window looks like the one in Figure 4-21. The New Host window You'll notice that we typed a relative domain name ( robocop) and not a fully qualified domain name ( robocop.movie.edu).
The DNS console is being helpful here and saving you some typing: it appends the domain name of the zone selected in the left pane (i.e., the zone that you're adding the new host to) to create a fully qualified domain name as shown. 4.4.4.1 Aliases Looking back at Movie U.'
S host table in the beginning of the chapter, you'll see that some hosts have aliases. (The aliases are any additional names after the first one listed.) For example, terminator is also known as bigt. A special resource record called the CNAME record is used to make an alias. The name of this record is confusing because CNAME is short for canonical name, which means the 'real' name of the host.
But a CNAME record doesn't make a canonical name; it makes an alias. All other types of records make a canonical name. We recommend thinking of it this way: CNAME records point to canonical names while other record types make canonical names. To create an alias, select the zone to which you want to add the record on the left, and choose Action New Alias (CNAME). You'll see a window that looks like the one in Figure 4-22.
Creating a CNAME record The input shown in Figure 4-22 will generate an alias from bigt.movie.edu to terminator.movie.edu. The Fully qualified domain name (FQDN) field shows the full name of the alias, which resides in the current zone. But the name that the alias points to (labeled Fully qualified name (FQDN) for target host) can point anywhere, to any domain name. We could alias bigt.movie.edu to www.whitehouse.gov if we wanted to. An important note, however: if you leave off the domain in the canonical name field, the zone's domain name is not appended automatically.
You should always enter a fully qualified domain name in the last field. It's important to know that the name server handles CNAME records in a different manner than aliases are handled in the host table. When a name server looks up a name and finds a CNAME record, it replaces the alias with the canonical name and looks up the new name.
For example, when the name server looks up bigt.movie.edu, it finds a CNAME record pointing to terminator.movie.edu. Then it looks up terminator.movie.edu, and its address is returned.
One thing you must remember about aliases like bigt is that they should never appear in the data portion (that is, on the right side) of a resource record. Stated differently, always use the canonical name ( terminator) in the data portion of the resource record. Notice that the NS records use the canonical name. Sometimes you can use an A record to get the effect of an alias. Suppose you have a router, like wormhole, and you want to check one of the interfaces.
One common troubleshooting technique is to ping the interface to verify that it is responding. If you ping the name wormhole, the name server returns the addresses of both interfaces. Ping uses the first address in the list. But which address is first? The solution is to create two A records for wormhole. We could use the New Host command to create them as we did earlier in this chapter, but we'll show you another way.
The Other New Records command lets you choose from 22 different resource records to create. Choose Action Other New Records and you'll see a window like Figure 4-23. Select a record type to see its description. We've selected Host (A), and after we select Create Record we'll see the same New Host window that we showed earlier, which we'll use to add an A record for wh249.movie.edu. Other new records window With the host table, we chose the address we wanted by using either wh249 or wh253?each name referred to one of the host's addresses. To provide equivalent capability with DNS, we didn't make wh249 and wh253 into aliases (CNAME records). That would result in both addresses for wormhole being returned when we looked up the alias.
Instead, we used address records. Now, to check the operation of the 192.253.253.1 interface on wormhole, we ping wh253 since it refers to only one address. The same applies to wh249. As a general rule, if a host is multihomed (i.e., has more than one network interface), create an address (A) record for each alias unique to one address. Create a CNAME record for each alias common to all the addresses.
4.4.4.2 One more note about PTR records We now have two A records, wormhole.movie.edu and wh249.movie.edu, pointing to the same address, 192.249.249.1. We also have a PTR record pointing from 1.249.249.192.in-addr.arpa to wormhole.movie.edu. (This record was added automatically to the 249.249.192.in-addr.arpa zone by the New Host option. Remember that addresses are looked up as names: the IP address is reversed, and in-addr.arpa is appended.) Thus, 192.249.249.1 maps to wormhole.movie.edu and not to wh249.movie.edu. Should you create another PTR record that maps 192.249.249.1 to wh249.movie.edu? You can create two PTR records?it's perfectly legal?but most systems are not prepared to see more than one name for an address. We recommend that you don't bother with multiple PTR records since so few systems can use them.
4.4.5 Where Is All This Information Stored? You may be wondering what's happened to all the resource records we've been entering. Where are they being stored? The answer is: in the memory of the DNS server process. We mentioned earlier that the DNS console communicates with the DNS server using an RPC mechanism. As you add records to a zone with the DNS console, they are added 'on the fly' to the name server's memory.
Of course, the name server's memory is transient?when the name server process stops, its memory is lost. Obviously it needs a permanent storage location, too. This is where the zone datafiles specified when we created the zones come in. The zone datafiles are the zones' permanent storage location, holding all the zones' resource records. If you use the DNS console to make a change to a zone, the copy of the zone in the name server's memory is changed, and a flag is set to update that zone's datafile. The name server updates the zone datafile when it exits, unless you tell it to update the file sooner.
Choosing Action Update Server Data Files (available when a name server is selected in the left pane) causes the name server to update the zone datafiles of all the zones for which it's a primary (if the version of a zone in the server's memory is more recent than the version on disk). There's also a per-zone version of this command: with a primary zone selected in the left pane, selecting Action Update Server Data File causes the server to update only that zone's file.
To avoid losing data, we recommend using Action Update Server Data File(s) after a batch of changes?use it like you use the Save command in other applications. Of course, the difference here is that the server will save your data if it exits gracefully.
You don't have to use Action Update Server Data File(s) after a batch of changes, but it doesn't hurt anything and you'll sleep better. As you've probably guessed, when the name server starts up, it reads the zone datafiles into memory. When you select Action Refresh or press F5, the DNS console queries the name server and updates the console's display. If you've been keeping track, you'll realize that DNS information exists in three places: zone datafiles, the name server's memory, and the DNS console's window. The diagram in Figure 4-24 helps explain how the information flows. Where everything is stored 4.4.6 The Zone Datafiles Let's take a look at the zone datafiles for Movie U. After inputting the remaining host table entries, we end up with the display shown in Figure 4-2.
(Of course, this view shows only the contents of movie.edu. The 249.249.192.in-addr.arpa and 253.253.192.in-addr.arpa zones are populated with PTR records.) Next we select Action Update Server Data Files, and the server generates three files in%SystemRoot% System32 DNS: movie.edu.dns, 249.249.192.in-addr.arpa.dns, and 253.253.192.in-addr.arpa.dns. We include them here. 4.4.6.1 Contents of movie.edu.dns;; Database file movie.edu.dns for movie.edu zone.; Zone version: 17; @ IN SOA terminator.movie.edu. ( 17; serial number 900; refresh 600; retry 86400; expire 3600 ); default TTL;; Zone NS records; @ NS terminator.movie.edu.;; Zone records; bigt CNAME terminator.movie.edu. Carrie A 192.253.253.4 dh CNAME diehard.movie.edu.
Diehard A 192.249.249.4 misery A 192.253.253.2 robocop A 192.249.249.2 shining A 192.253.253.3 terminator A 192.249.249.3 wh CNAME wormhole.movie.edu. Wh249 A 192.249.249.1 wh253 A 192.253.253.1 wormhole A 192.253.253.1 A 192.249.249.1 4.4.6.2 Contents of 249.249.192.in-addr.arpa.dns;; Database file 249.249.192.in-addr.arpa.dns for 249.249.192.in-addr.arpa zone.; Zone version: 7; @ IN SOA terminator.movie.edu. ( 7; serial number 900; refresh 600; retry 86400; expire 3600 ); default TTL;; Zone NS records; @ NS terminator.movie.edu.;; Zone records; 1 PTR wormhole.movie.edu. 2 PTR robocop.movie.edu. 3 PTR terminator.movie.edu. 4 PTR diehard.movie.edu. 4.4.6.3 Contents of 253.253.192.in-addr.arpa.dns;; Database file 253.253.192.in-addr.arpa.dns for 253.253.192.in-addr.arpa zone.; Zone version: 7; @ IN SOA terminator.movie.edu.
( 7; serial number 900; refresh 600; retry 86400; expire 3600 ); default TTL;; Zone NS records; @ NS terminator.movie.edu.;; Zone records; 1 PTR wormhole.movie.edu. 2 PTR misery.movie.edu. 3 PTR shining.movie.edu. 4 PTR carrie.movie.edu. 4.4.7 Zone Datafile Format The format of zone datafiles is specified in the DNS standards. That means all name servers, whether Microsoft DNS Server or the BIND name server, can read each other's zone datafiles.
You've probably already guessed that the semicolon is the comment character. It can appear anywhere on a line, and anything to the right is considered a comment and is ignored by the name server. Blank lines are okay, too. Each resource record must start in the first column of the file?no preceding whitespace. (Don't be confused by the examples in this book, which are indented because of the way the book is formatted.) Resource records are case-insensitive?you can use uppercase or lowercase. The name server doesn't preserve the case, though. It matches the case of the reply to the case of the query.
For example, if a record is written as terminator in the zone datafile but you query for Terminator, the server responds with Terminator. Resource records are broken up into fields, with any amount of whitespace (tabs or spaces) separating the fields. The first field, called the owner, is the domain name of the record. Put another way, it's the node in the namespace to which the resource record is attached. You've seen the domain name on the left side of the right pane of the DNS console. The next field in our examples is the class, IN, which stands for Internet.
Other classes exist, but none of them are currently in widespread use. Our examples use only the IN class.
The field after that is the record type. We've already discussed the SOA, NS, A, PTR, and CNAME record types, and you've probably browsed through the list of other record types in the DNS console's Other New Records window. The type simply specifies what type of data is associated with the domain name on the right: A means IP address, NS means the name of an authoritative name server, and so on. That's a good lead-in to the final field, the RDATA or resource record data field. This field holds the kind of data specified by the record type.
It can be divided into multiple subfields, depending on the type. For example, A records specify only one parameter, an IP address, but the SOA record specifies seven parameters (remember all those fields in Figure 4-19?).
Speaking of the SOA record, you'll notice in the examples that it's the only record spanning multiple lines. If you ever have to edit zone datafiles by hand, you can use parentheses to allow a resource record to span multiple lines. This trick works for all record types, not just SOA.
Domain names appear a lot in resource records. The left side of every resource record is a domain name, and the right side (RDATA field) of many record types also contains domain names (for example, NS and SOA records). Using a fully qualified domain name in each case is perfectly legal, but it would be a lot of work: imagine having to type movie.edu at the end of every hostname if you were entering these files by hand. Fortunately, abbreviations are allowed. You need to understand the abbreviations because the Microsoft DNS Server uses them in records it generates. 4.4.7.1 Appending domains Every zone has a domain name: it's just the name of the zone.
(This probably strikes you as pretty obvious.) This domain name is the key to the most useful shortcut. This domain name is the origin of all the data in the datafile.
The origin is appended to all domain names in the file not ending in a dot. The origin is different for each file because each file is associated with a different zone, each of which has a different domain name. Since the origin is appended to names, instead of entering robocop's address in movie.edu.dns as this: robocop.movie.edu. IN A 192.249.249.2 the server generated it like this: robocop A 192.249.249.2 The server also used another shortcut and omitted the class, IN. If you omit the class on a record, the previous record's class is used. Since this file uses only the IN class, it makes sense to specify it once on the first record in the file and leave it off the subsequent records. In that case, the first record's class applies to all the other records.
In 192.249.249.in-addr.arpa.dns, this is the long way to write this record: 2.249.249.192.in-addr.arpa. IN PTR robocop.movie.edu. But since 249.249.192.in-addr.arpa is the origin, the server generated: 2 PTR robocop.movie.edu.
Notice that all the fully qualified domain names in the file end in a dot. That tells the server that this domain name is complete and should be left alone. Suppose you forgot the trailing dot.
An entry like this: robocop.movie.edu A 192.249.249.2 turns into an entry for robocop.movie.edu.movie.edu, not what you intended at all. 4.4.7.2 @ notation If the domain name is the same as the origin, the name can be specified with an at sign (@). This is most often seen in the SOA record in datafiles generated by hand, but the Microsoft DNS Server also uses the @ notation in NS records. In the movie.edu.dns file in the previous example, the @ stands for movie.edu. Of course, in the 249.249.192.in-addr.arpa.dns file, the @ stands for 249.249.192.in-addr.arpa, and in the 253.253.192.in-addr.arpa.dns file. Well, you get the idea.
4.4.7.3 Repeat last name If there is a space or a tab in column one, the name from the last resource record is used. This shortcut gets used when a name has multiple resource records. This example shows two address records for one name: wormhole A 192.253.253.1 A 192.249.249.1 In the second address record, the name wormhole is implied.
You can use this shortcut even if the resource records are of different types?for example, if wormhole also had a TXT (arbitrary text) record. 4.4.8 The Loopback Address Those of you familiar with the BIND name server may be wondering if we forgot about the loopback address. If we were setting up a BIND name server, it would need one additional zone datafile to cover the loopback network: the special address that hosts use to direct traffic to themselves. This network is (almost) always 127.0.0.0, and the host number is (almost) always 127.0.0.1.
Therefore, the name of this file would be 0.0.127.in-addr.arpa.dns, and it would look like the other in-addr.arpa.dns files. The following would be the contents of the 0.0.127.in-addr.arpa.dns file: @ IN SOA terminator.movie.edu. ( 1; serial number 3600; refresh 600; retry 86400; expire 3600 ); minimum TTL;; Zone NS records; @ NS terminator.movie.edu.;; Zone records; 1 PTR localhost. Why do name servers need this file?
Think about it for a second. No one was given responsibility for network 127.0.0.0, yet systems use it for a loopback address. Since no one has direct responsibility, everyone who uses it is responsible for it individually. If you omit this file on a name server, it will still operate.
However, a lookup of 127.0.0.1 might fail: the name server will send the query to a root name server that might not be configured to map 127.0.0.1 to a name. With the Microsoft DNS Server, you don't have to worry about creating this file and making your name server authoritative for the in-addr.arpa zone corresponding to network 127.0.0.0. The server is authoritative for this zone by default. It's called an automatically created zone and is visible in the DNS console only in advanced mode. Select View Advanced and you can see the three automatically created zones shown in Figure 4-25. The DNS console showing automatically created zones We've drilled down into the 127.in-addr.arpa zone to show that there's a PTR record for 1.0.0.127.in-addr.arpa pointing to the domain name localhost. In other words, the Microsoft DNS Server reverse-maps the IP address 127.0.0.1 to the domain name localhost 'out of the box' without any work on your part.
The 0.in-addr.arpa and 255.in-addr.arpa zones are empty, save for NS and A records. Some hosts attempt to reverse-map the IP addresses 0.0.0.0 and 255.255.255.255, and these zones cause the local server to return an immediate Name Error (also known as NXDOMAIN, which is short for nonexistent domain) for those queries rather than asking a root name server.
4.4.9 The Root Hints Data Besides your local information, the name server also needs to know where the name servers for the root zone are. (Remember that the resolution process starts at the root zone, so knowing which name servers are authoritative for the root zone is critical.) This information is stored in a file called the root name server hints file, which is named%SystemRoot% System32 DNS cache.dns on your name server. The Microsoft DNS Server ships with a version of this file that looks like this (or at least it did when this book was published):;; cache.dns - DNS CACHE FILE;; Initial cache data for root domain servers.;; YOU SHOULD CHANGE:; - Nothing if connected to the Internet. Edit this file only when; updated root name server list is released.; OR; - If NOT connected to the Internet, remove these records and replace; with NS and A records for the DNS server authoritative for the; root domain at your site.;; Note, if you are a root domain server, for your own private intranet,; no cache is required, and you may edit your boot file to remove; it.;; This file holds the information on root name servers needed to; initialize cache of Internet domain name servers; (e.g. Reference this file in the 'cache.
'; configuration file of BIND domain name servers).;; This file is made available by InterNIC; under anonymous FTP as; file /domain/named.root; on server FTP.INTERNIC.NET;; last update: Nov 5, 2002; related version of root zone:;;; formerly NS.INTERNIC.NET;. 3600000 IN NS A.ROOT-SERVERS.NET.
3600000 A 198.41.0.4;; formerly NS1.ISI.EDU;. 3600000 NS B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107;; formerly C.PSI.NET;.
3600000 NS C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12;; formerly TERP.UMD.EDU;. 3600000 NS D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90;; formerly NS.NASA.GOV;. 3600000 NS E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10;; formerly NS.ISC.ORG;. 3600000 NS F.ROOT-SERVERS.NET.
3600000 A 192.5.5.241;; formerly NS.NIC.DDN.MIL;. 3600000 NS G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4;; formerly AOS.ARL.ARMY.MIL;. 3600000 NS H.ROOT-SERVERS.NET.
3600000 A 128.63.2.53;; formerly NIC.NORDU.NET;. 3600000 NS I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17;; operated by VeriSign, Inc.;. 3600000 NS J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30;; housed in LINX, operated by RIPE NCC;. 3600000 NS K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129;; operated by IANA;.
3600000 NS L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12;; housed in Japan, operated by WIDE;.
3600000 NS M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33; End of File The domain name '.' Refers to the root zone. This information can also be retrieved from the Internet host ftp.rs.internic.net (198.41.0.7). Use anonymous FTP to retrieve the file named.root from the domain subdirectory. However, you probably won't ever need to update your server's cache.dns file.
Because the ability to reach the root name servers is so important, the Microsoft DNS Server goes out of its way to make sure its list of root name servers is always up to date. It views the contents of cache.dns somewhat suspiciously and doesn't use that list of name servers directly. (That's why this file is called the root hints.) Rather, when the server starts up, it chooses a root name server from cache.dns at random and asks it for the current list of root name servers. After all, who would know the current list of root name servers better than one of the root name servers? The list returned is the one used by the name server to start the resolution process and is the list you see when you drill down in the left pane of the DNS console. The DNS server also overwrites the contents of cache.dns with the updated list.
As a result, if you've started the DNS server even just once, your cache.dns will look different than the one shown here because the server doesn't preserve the comments when it overwrites the file. You can also view this information from within the DNS console. Select a name server in the left pane and choose Action Properties Root Hints tab to see a window like the one shown in Figure 4-26. Root Hints window Finally, you may be wondering what the 3600000s in the file are for. In older versions of this file, this number was 99999999.
It dates back to the behavior of early versions of BIND. The BIND name server used to put the contents of the root hints file directly into its cache, and it had to know how long to keep these records active.
The 99999999s meant a very long time. The root name server data was to be kept active for as long as the server ran. Since both BIND and the Microsoft DNS Server now store the root hints data in a special place and don't discard it if it times out, the TTL is unnecessary. But it's not harmful to have the 3600000s, and it makes for interesting DNS folklore when you pass responsibility to the next name server administrator.
Applies To: Windows Server 2012 R2, Windows Server 2012 If a zone is signed with DNSSEC and validation is required, DNSSEC must be supported by each DNS server that is involved in the process of a DNS query and response. This support creates a chain of trust that enables DNSSEC data to be passed from the authoritative DNS server that hosts a signed zone to other DNS servers that can verify this data and thus validate that DNS responses are genuine. DNS clients are protected against spoofing attacks when they receive this validated response. To enable DNSSEC and the chain of trust:.
Primary authoritative DNS servers must support zone signing. Primary and secondary authoritative DNS servers must support hosting of signed zones. Recursive or forwarding DNS servers must support DNSSEC validation of DNS responses. DNS clients that are security-aware can also be configured to require that DNSSEC validation be performed.
Clients that are not security-aware or that do not require validation can still be protected with DNSSEC. For more information, see. Note DNSSEC requires Extension Mechanisms for DNS (EDNS0), a DNS extension that permits large UDP packets to be used in DNS responses. Some network infrastructure devices such as routers and firewalls can interfere with transmission of large UDP packets and cause DNS queries to fail when EDNS0 is enabled. For more information, see Knowledge Base article 2028240: ”. In this section. DNSSEC support in Windows Server DNSSEC support in Windows Server is greatly improved in Windows Server 2012 and Windows Server 2012 R2.
The following table provides a summary of DNSSEC support in Windows Server operating systems. Operating system version DNSSEC support Windows Server 2003 and Windows Server 2008 DNSSEC is implemented on secondary zones as described in RFC 2535. RFC 2535 has been made obsolete by RFCs 4033, 4034, and 4035; therefore, this DNSSEC implementation is not interoperable with Windows Server 2008 R2 or any later operating systems. Windows Server 2008 R2 Limited DNSSEC support was added in Windows Server 2008 R2 to enable offline signing for static zones. DNSSEC in Windows Server 2008 R2 is not intended to be used with dynamic, Active Directory-integrated DNS zones. If a zone is DNSSEC-signed on a DNS server running Windows Server 2008 R2, all types of dynamic updates, secure and non-secure, are disabled on that zone.
To support staged migration, you can deploy DNSSEC in a mixed environment with Windows Server 2008 R2 and Windows Server 2012 DNS servers. For more information, see the topic in this section. Windows Server 2012 and Windows Server 2012 R2 DNSSEC support is significantly enhanced in Windows Server 2012 and Windows Server 2012 R2. Enhancements include online signing, DNS dynamic update support for signed zones, Windows PowerShell support, automated trust anchor distribution and rollover, support for NSEC3 and RSA/SHA-2 standards, and updated user interface deployment and management wizards.
Note: The DNS client in Windows 7, Windows Server 2008 R2 and later versions of Windows is a non-validating DNSSEC-aware stub resolver. Earlier versions of the Windows DNS Client were not DNSSEC-aware.
For more information about DNSSEC and DNS clients, see the topic in this guide. For detailed information about DNSSEC in Windows Server 2008 R2, see in the for Windows Server 2008 R2. DNSSEC mixed-mode deployment To support staged migration, you can deploy DNSSEC in a mixed environment with some DNS servers running Windows Server 2008 R2 and other DNS servers running Windows Server 2012 or a later operating system. The following specifications apply to mixed-mode deployments:. Updated DNSSEC standards (ex: NSEC3) that are available in Windows Server 2012 and Windows Server 2012 R2 are incompatible with DNS servers running Windows Server 2008 R2. As a result, servers running Windows Server 2008 R2 will load zones that are signed on Windows Server 2012 as unsigned zones. Zones that are signed on (legacy) DNS servers running Windows Server 2008 R2 are compatible with some DNSSEC operations on (current) DNS servers running Windows Server 2012 or a later operating system.
DNSSEC-related resource records (ex: RRSIG, DNSKEY) in these zones will be loaded on current DNS servers and the zones will be capable of DNSSEC validation. However, the zone will not appear to be signed in DNS Manager or using current Windows PowerShell cmdlets. A zone that is signed on Windows Server 2008 R2 cannot be unsigned on a server running Windows Server 2012 or a later operating system using the Invoke-DnsServerZoneUnsign cmdlet or the DNS Manager console. To unsign a zone that was signed on a legacy DNS server, you must use legacy procedures. These procedures can be performed on a current DNS server or a legacy DNS server.
Trust anchors that are created on legacy DNS servers can be imported and will be displayed on current DNS servers using the DNS Manager console or Windows PowerShell. The format of trust anchors is the same in both legacy and current operating systems. Warning An issue has been identified where DNSSEC validation can fail on computers running Windows 7 when you distribute trust anchors in Active Directory.
To repair this issue, import trust anchors manually to validating DNS servers. WINS lookup for signed zones You can configure a DNS server to use Windows Internet Name Service (WINS) to look up names that are not found in DNS by checking the NetBIOS namespace. To use WINS lookup integration, two special resource record types—the WINS and WINS-R resource records—are enabled and added to a zone. When the WINS resource record is used, DNS queries that fail to find a matched host (A) resource record in the zone are forwarded to WINS servers that are configured in the WINS resource record. For reverse lookup zones, the WINS-R resource record can be enabled and used to provide a similar benefit for further resolving a reverse DNS query that is not found.
In Windows Server 2008 R2, WINS lookup was disabled for DNSSEC-signed zones. For unsigned zones, the WINS tab is displayed in DNS Manager when you view properties of the zone. See the following example. If a zone was signed, WINS lookup was disabled, and the WINS tab was not displayed. In Windows Server 2012 and later operating systems, WINS forwarding is enabled for signed zones. If you select the Use WINS forward lookup check box to enable WINS lookup on a signed zone, a warning message appears. See the following example.
A similar message is displayed if you attempt to sign a zone that previously has had WINS lookup enabled. Warning messages are also displayed when you attempt to sign a zone with Windows PowerShell that has WINS lookup enabled. In summary, WINS lookups are available for both signed and unsigned zones on Windows Server 2012 or later, but WINS lookup is not tamper-proof and constitutes a security risk if it is enabled for a DNSSEC-signed zone. DNSSEC in Windows Server 2012 Windows Server 2012 and Windows Server 2012 R2 provide many enhancements over Windows Server 2008 R2 that simplify DNSSEC deployment and administration, including online signing of dynamic, Active Directory-integrated DNS zones, Windows PowerShell support, and wizards that are integrated into the DNS Manager console. These key DNSSEC-related features are described in this topic and summarized in the table below. The following table provides a summary of new DNSSEC features in Windows Server 2012.
Feature Description More information Dynamic online signing Online signing of dynamic, Active Directory-integrated zones is supported. DNSSEC and read-only domain controllers (RODCs) RODCs load signed zones as file-backed secondary zones. DNSSEC deployment wizards Zone signing and unsigning is greatly simplified. DNSSEC administration The Key Master is a DNS server that generates and manages signing keys for a zone.
DNSSEC key management is greatly enhanced with automatic key rollover and trust anchor distribution. Standards Updated standards like NSEC3 and RSA/SHA-2 are supported. Windows PowerShell support Windows PowerShell has parity with dnscmd for management of DNSSEC-signed zones. Online signing and dynamic updates Support for DNSSEC zone signing was added with Windows Server® 2008 R2, and subsequently extended in Windows Server 2012 to support online signing. DNSSEC in Windows Server 2008 R2 In Windows Server 2008 R2, DNSSEC-signed zones could only be signed offline, over a file-based copy of the zone.
It was not possible to generate or update signatures on a zone while the zone was online. Nearly all configuration required manual administration, which included the following operations:. You could only generate the keys required to sign a zone manually by using the dnscmd tool. Although it is recommended that a zone be signed with both a KSK and a ZSK, the keys had to be generated one at a time. There was no built-in provision to generate additional keys automatically for rollovers. You were required to plan the type of rollover that you wanted in advance, and then generate keys manually. Dnscmd required several inputs to generate keys and assumed no defaults.
In some cases, you had to specify the option even though there was only one available – such as algorithm (the only supported algorithm was RSA/SHA-1). Zone signing was also a manual operation through dnscmd and was performed over a file copy of the zone offline. You then had to manually import this signed file copy of the zone to the server. Windows Server 2008 R2 supported signing Active Directory-integrated zones, but a signed zone could not have dynamic updates enabled. You were required to manually re-sign a zone whenever an update was made to the zone.
There was no provision to replicate or distribute private keys. Keys were stored in the machine certificate store on the computer where they were generated. They could not be easily exported to other DNS servers.
DNSSEC in Windows Server 2012 and Windows Server 2012 R2 In Windows Server 2012 and later operating systems, DNSSEC support is enhanced to include online signing of dynamic zones. In addition, multiple zone management tasks are automated:. Signing keys are generated automatically by DNS Manager or Windows PowerShell when parameters have been specified.
You can also choose a default parameter set. For each signing key, the administrator can enable or disable automatic key rollover at a specified frequency. DNS Manager or Windows PowerShell can be used to sign a zone using default values or using custom values. If the zone was previously signed, you can also choose to re-use these parameter values. DNS Manager also provides the option of signing a zone using the same values that were used to sign another zone.
Zone signing is now performed on active, online zones. There is no need to take a zone offline for signing, and then import a signed copy of the zone after signing is complete.
If a zone is updated, it is automatically re-signed. Updates to signed zones can be performed manually or dynamically. Dynamic updates are no longer disabled for DNSSEC-signed zones. For Active Directory-integrated zones, signing keys are automatically replicated to all primary authoritative DNS servers. DNS in Windows Server 2012 and Windows Server 2012 R2 also includes a DNSSEC wizard in DNS Manager, which walks an administrator through the signing and unsigning process. The wizard generates all keys that are necessary to sign a zone automatically.
Update Server Data Files Dns
For more information, see. For Active Directory-integrated zones, private zone signing keys replicate automatically to all primary DNS servers through Active Directory replication.
Each authoritative server signs its own copy of the zone when it receives the key. For optimal performance, and to prevent increasing the size of the Active Directory database file, the signed copy of the zone remains in memory for Active Directory-integrated zones. A DNSSEC-signed zone is only committed to disk for file-backed zones. Secondary DNS servers pull a full copy of the zone, including signatures, from the primary DNS server. In general, cryptographic operations are computationally expensive. For large zones, the DNS server can take several minutes to sign the zone depending on the key length and size of the zone. To prevent performance degradation from occurring when all DNS servers start to sign the zone at the same time, signing is staggered.
When a replica domain controller sees the DNSSEC keys and configuration, it waits for a random period between 5 minutes and 30 minutes before it begins signing the zone. Read-only domain controllers (RODCs) In Windows Server 2008 and Windows Server 2008 R2, DNS servers running on read-only domain controllers (RODCs) host Active Directory-integrated copies of all zones. However, because the zone is read-only, the DNS server cannot make any updates to the zones that it hosts. Instead, updates occur on other DNS servers and are transferred to the RODC through Active Directory replication. When an Active Directory-integrated zone is signed with DNSSEC, private keys are also replicated to all DNS servers running on domain controllers, with an exception: Private keys are not replicated to an RODC because RODCs are intended to operate in insecure environments.
In Windows Server 2012 and Windows Server 2012 R2, an RODC loads unsigned zones from Active Directory with no change in functionality from Windows Server 2008 R2. However, if the RODC finds a DNSSEC-signed zone in Active Directory, it does not load the zone as Active Directory-integrated.
Instead, it creates a secondary copy of the zone, and then configures the closest writeable domain controller for the domain as the primary server. The RODC then attempts to perform a zone transfer. Zone transfers must be enabled on the primary DNS server for this transfer to succeed. If zone transfers are not enabled, the RODC logs an error event and takes no further action.
In this scenario, you must manually enable zone transfers on the primary server that is selected by the RODC. Alternately, you can choose to reconfigure the RODC to point to a different primary DNS server that has zone transfers enabled.
DNSSEC in DNS Manager DNS Manager in Windows Server 2012 and Windows Server 2012 R2 includes wizards to help you sign zones with DNSSEC, to view and edit DNSSEC parameters, and to easily unsign a zone. The DNSSEC status of a zone is displayed in the console tree with a lock icon displayed next to the name of the zone if it is signed with DNSSEC. A signed zone also displays a status of Signed in the right-hand pane in the DNSSEC Status column and the name of the is shown in the corresponding column. See the following example.
If you recently signed the zone, you might have to refresh the DNS Manager console view to see the DNSSEC-signed status of a zone. You can also right-click the zone in DNS Manager and point to DNSSEC. If the zone is not yet signed, the only choice available is Sign the Zone.
See the following example. For information about signing and unsigning a zone, see. The Key Master The DNSSEC Key Master is a new concept and component of a Windows DNSSEC deployment that was introduced in Windows Server 2012. In Windows DNSSEC, the Key Master is the DNS server that is responsible for key generation and key management for a DNSSEC-signed zone. When you use default settings to sign a zone, the local server is selected as Key Master.
You also have the option of choosing a different DNS server from a list of servers that support online DNSSEC signing. Only one DNS server can be the Key Master for a given zone at a given time. The Key Master must be a primary, authoritative server for the zone and must be capable of online zone signing.
However, in a Microsoft multi-master DNS deployment environment, the following is possible:. The Key Master role can be transferred to a different authoritative name server after zone signing.
This transfer can be performed gracefully if the current Key Master is online, or it can be performed as part of a disaster recovery scenario if the current Key Master is offline. For more information, see and later in this topic. One authoritative server can be the Key Master for multiple zones. Different authoritative servers can be Key Masters for different zones.
You cannot transfer the Key Master role if a zone is file-backed, because these zones have only one primary, authoritative DNS server. Important If a zone is Active Directory-integrated, the Key Master is a domain controller and can benefit by enhanced security considerations that are used with domain controllers. If the zone is file-backed, the Key Master might not be also a domain controller. In this scenario, it is recommended to take additional security precautions to protect the Key Master from attack and to protect private key material from becoming compromised. For security reasons, a Key Master that is not a domain controller should only have the DNS Server role installed in order to limit its attack surface. The name of the Key Master is displayed in DNS Manager when you click Forward Lookup Zones or Reverse Lookup Zones, and it is displayed on the Key Master tab of the DNSSEC properties page.
You can also use the Get-DnsServerDnsSecZoneSetting Windows PowerShell cmdlet to view the Key Master. See the following example: PS C: Get-DnsServerDnsSecZoneSetting -ZoneName secure.contoso.com Select KeyMasterServer KeyMasterServer - DC1.contoso.com The Key Master generates all keys for the zone, and is responsible for distribution of private keys and zone signing information. The Key Master is also responsible for performing all zone signing key (ZSK) and key signing key (KSK) rollovers and for polling child zones to keep signed delegations up-to-date. Note An unsigned zone can also be assigned a Key Master. All zones that have been signed have a Key Master setting, whether they are currently signed or not. A zone that has never been signed typically does not have a Key Master, but can be configured with a Key Master in preparation for zone signing with Windows PowerShell.
Transferring the Key Master role If the Key Master is online, you can perform a graceful transfer the Key Master role to another DNS server. Another qualifying DNS server must be available on the network. To transfer the Key Master role using DNS Manager, view the DNSSEC properties of the zone, click the Key Master tab, and then choose Use the following DNS server as the Key Master.
When you click the drop-down list, a pop-up alert asks if you want the local server to build a list of available, qualifying DNS servers that can be the Key Master. Click OK, choose a server from the list, and then click OK. See the following examples. Important The signed-in user must have Domain Admins group rights, or equivalent, on a DNS server in order for it to be displayed in the list.
You can also perform this operation using Windows PowerShell with the Reset-DnsServerZoneKeyMasterRole cmdlet. See the following example. PS C: Reset-DnsServerZoneKeyMasterRole -ZoneName secure.contoso.com -KeyMasterServer dc2.contoso.com -force PS C: Get-DnsServerDnsSecZoneSetting -ZoneName secure.contoso.com Select KeyMasterServer KeyMasterServer - DC2.contoso.com In this example, the Get-DnsServerDnsSecZoneSetting cmdlet is also used to verify that the Key Master role was transferred successfully. Seizing the Key Master role The server that is designated as the Key Master should be online and highly available to ensure uninterrupted service for key signing operations. However, if the Key Master becomes offline and cannot easily be restored to online status, it is possible to forcibly transfer the Key Master role to another qualifying DNS server, using a process called seizing. Do not seize the Key Master role unless it is unavoidable.
A graceful online transfer of the Key Master role is always preferred. Private key material. Important The Key Master must have access to private key material for a DNSSEC-signed zone. If the current Key Master is offline, other DNS servers might have access to private key material if it is stored in a shared location such as Active Directory. If private key material is not stored in Active Directory, and the new Key Master cannot access the private keys for a zone through other means, then new keys must be generated, and the zone must be re-signed with these new keys. After re-signing with new keys, all trust anchors that exist on other DNS servers will be invalid and must be updated. To store private key material in Active Directory, select the Replicate this private key to all DNS servers authoritative for this zone check box in KSK settings for all KSKs that are used.
See the following example. If you do not want to store private key material in Active Directory, you might also be able to provide access to private key material using a certificate or hardware storage module (HSM) device. This storage media must be accessible to the DNS server that is selected as the new Key Master. If private key material is not stored in Active Directory or an external device, you can use the following command to store this material in a certificate on the local computer.
MakeCert -ss MS-DNSSEC -sr LocalMachine To use the command, you must first download and install the Windows SDK from. If the new Key Master cannot access private key material for the zone, a notification is displayed that indicates that private key material is not accessible and that new keys must be generated.
See the following example. Important If you click Yes and continue seizing the Key Master role, new ZSKs and KSKs are not automatically generated. You must re-sign the zone so that private key material is available. If trust anchors were distributed for the zone, these trust anchors must also be replaced.
If the original Key Master becomes available before the zone is re-signed, you can transfer the Key Master role back to this server without the requirement to re-sign the zone and redistribute trust anchors. If private key material is stored in Active Directory, you can seize the Key Master role on another primary, authoritative Active Directory-integrated DNS server and have full access to private key material. In this case, the signing keys (ZSKs and KSKs) do not have to be replaced. If you use DNS Manager to access an Active Directory-integrated authoritative DNS server with a primary copy of the zone when the Key Master is offline, a notification is displayed when you view DNSSEC properties of the zone, which indicates that DNSSEC settings could not be loaded.
See the following example. Click OK to load DNSSEC settings using the local server. These settings will be the settings that were configured during the last successful replication. On the Key Master tab, you can choose a new Key Master from a list of available DNS servers, similar to the procedure that is used for a graceful transfer of the Key Master role, described earlier in this topic.
After choosing a new Key Master and clicking OK, a notification is displayed with information about the changes to be made. Click OK again to proceed with the seizing operation. Another notification is displayed with the status of the role transfer. See the following examples: Information about the new Key Master replicates in Active Directory to all primary DNS servers.
After seizing the Key Master role on another server, if the old Key Master comes online, it detects that it is no longer the Key Master. You do not have to modify settings further. DNSSEC standards In addition to online signing and unsigning of dynamic Active-Directory-integrated zones, DNSSEC in Windows Server 2012 and Windows Server 2012 R2 includes support for:.
Automated key rollover. Automated updates of DNS security trust anchors (RFC 5011). NSEC3 zone signing and validation. NSEC3 random salt and user-defined salt. RSA/SHA-2 zone signing and validation For more information about DNSSEC settings that are used in zone signing, see. Zone transfers Zone transfers can be secured using IPsec. Windows Server 2012 and Windows Server 2012 R2 do not support Transaction Signature (TSIG) for zone transfers.
Update Server Data Files
Certificate-based authentication can be used to establish an IPsec session between DNS servers. Each endpoint must present a certificate to prove its identity. This method requires that certificates are created and configured on all DNS servers that participate in zone transfers for DNSSEC-signed zones.
To configure certificate-based IPsec policies on DNS servers, see the following topics. Warning A bug has been identified in Windows Server 2012 and Windows Server 2012 R2 whereby multiple RRSIG records in a DNSSEC-signed zone can accumulate on a secondary DNS server, particularly for resource records at the zone root, such as DNSKEY signatures.
Stub Data Directory
These additional resource records do not cause DNS resolution problems. These extra RRSIG records accumulate because incremental zone transfers (IXFR) from the primary DNS server add new RRSIG records but do not automatically remove older RRSIG records. To remove these records, initiate a full zone transfer.
It is also possible for RRSIG records on a secondary DNS server to expire. To prevent expiration, you can periodically initiate a full zone transfer from the primary to the secondary DNS server. DNS-Server-Service event ID 1525 (warning) and event ID 1524 (error) are recorded in Event Viewer when signatures are about to expire, and have expired, respectively. This bug is pending a hotfix.