Dns On Windows Server 1002003 [Electronic resources] نسخه متنی

11.1 New Ways to Make Changes

In Chapter 4 we described the traditional method
for making changes to zone data and how those changes are propagated:
any changes to a zone are made on the zone's primary
server, and secondary servers periodically poll the primary to check
if the zone has changed. If the zone has new information, the
secondaries perform a zone transfer to download the entire zone. This
scheme is effective but inefficient and it's not
suitable for every environment. The DNS console is great for making
changes by hand, but what about automated changes (say you want to
have a program change information in a zone)? It can also be
frustrating to wait for all the secondaries to be updated with the
new information. And for a large zone, it's a waste
of time and bandwidth to transfer the entire zone if only a single
record was added or deleted.

The next three sections describe relatively recent changes to the DNS
protocol called dynamic update, NOTIFY, and incremental zone transfer
that work together to address these issues. The Microsoft DNS Server
implements all three.

11.1.1 Dynamic Update

Dynamic update was implemented in the
Microsoft DNS Server starting with Windows 2000. Like many other
protocols used by Windows, it's an Internet
standard, defined in RFC 2136. Dynamic update allows a name server to
be updated by sending it a message over the network. This is a big
improvement over the traditional method, which requires a human to
fire up the DNS console to make the change in person. Dynamic update
allows nonhumansi.e., programsto easily update DNS
information. Dynamic update is now used extensively in Windows: a
modern Windows client uses it to add an A record to DNS for its IP
address and recent Windows DHCP servers also use dynamic update to
add PTR records as they assign leases.

No
security is built into the dynamic update protocol.
It's up to an individual name server to decide
whether or not to accept an update message. About the only means of
authentication a name server has is to look at the source IP address
of the dynamic update message, and that's not a very
strong means of authentication at all: it's easy to
"spoof" or forge a
packet's source IP address. And since a complete
dynamic update message travels in a single UDP packet, all an
attacker needs to know is an IP address that the name server
accepting dynamic updates trusts. The Bad Guy just creates a dynamic
update with a spoofed source IP address and sends it to the
unsuspecting name server.

This deficiency begs
for some stronger security based on cryptography, which fortunately
has been developed. The DNS standards community developed a protocol
extension to use transaction signatures to sign
any kind of DNS messageincluding dynamic updatessent
between two parties: client to server, server to server, dynamic
updater to server, etc.

The transaction signatures, or TSIGs for short, in DNS use a
technique called HMACKeyed-Hashing for Message Authentication
(see RFC 2104)which employs a shared secret and a one-way
cryptographic hash function to sign data. A shared secret is like a
password known only to the two parties involved in exchanging data. A
one-way cryptographic hash function computes a fixed-size checksum
based on any amount of input. What differentiates a cryptographic
hash function, such as MD5 or SHA1, from a run-of-the-mill checksum,
such as a CRC (Cyclic Redundancy Check), is that
it's computationally infeasible to find two
different input streams that produce the same hash output. With a CRC
checksum, on the other hand, the algorithm is easily reversible:
given any checksum, it's trivial to calculate an
input stream to generate that checksum. Another property of a good
cryptographic hash function is that varying the input by even a small
amountsuch as changing just one bitproduces a major
change in the hash output. In other words, the hash output is like a
fingerprint of the original input.

A transaction
signature is so-named because it's ephemeral: the
signature applies only to a single transaction and is not reusable.
Let's say a client wants to send a dynamic update
signed with a TSIG to the appropriate name server. After generating
the dynamic update message, it appends the secret it shares with the
server to the message and runs everything through MD5. The output is
the TSIG itself, which is placed into a TSIG resource record that
goes in the dynamic update message. Since TSIGs are generated on the
fly like this, you see a TSIG record only on a packet sniffer, never
in the DNS console or a zone datafile. Note that TSIG
doesn't encrypt the data being sent: it only
authenticates it. HMAC is illustrated in Figure 11-1.

Figure 11-1. HMAC illustrated

One difficulty with TSIG is distributing the shared secrets. Imagine
having hundreds of clients that need to send TSIG-signed dynamic
updates to a name server: that would require generating hundreds of
keys and distributing them securely to each client. Microsoft found
itself in just such a predicament. As we discussed in Chapter 8, individual Windows clients do send dynamic
updates to name servers. TSIG is a requirement for these transactions
to happen securely, but it's not feasible to
statically configure shared secrets on each Windows client. The
solution: Kerberos to the rescue!

Windows Server 2003 (and Windows 2000 before it) uses Kerberos for
authentication and authorization. Kerberos allows two parties who
want to communicate securely to negotiate the necessary information
to do so. Every Windows Server 2003 domain controller is a Kerberos
Key Distribution Center, or KDC. Every modern Windows client and
server is a Kerberos "principal."
Every Kerberos principal shares a secret with the KDC. (This shared
secret is generated when the host is joined to the domain.) The KDC
acts as a trusted third party that allows two principals to
communicate securely. For example, suppose a client named Alice wants
to send an encrypted message to a client named Bob. Alice asks the
KDC to help negotiate a session key^[1] with Bob. Alice and Bob
don't (yet) trust each other, but they do trust the
KDC, which facilitates distributing the session key to each of them.
This explanation is quite an oversimplification of how Kerberos
actually works, but it does show the underlying concepts.

^[1] As the name
implies, a session key is a short-lived key usually used for a single
conversation.

Microsoft extended TSIG in Windows to use Kerberos. A Windows client
that wants to send a TSIG-signed dynamic update message to a name
server doesn't have to be statically configured to
share a secret with that server. The client uses Kerberos to obtain a
session key, which serves as a one-time shared secret. This variant
of TSIG is called GSS-TSIG and is documented in an
Internet-Draft.^[2]

^[2] GSS stands for Generic Security
Service. At the time of this writing, GSS-TSIG was not yet an
Internet standard but was on track to become one. Internet-Drafts may
be found at
http://www.ietf.org/1id-abstractsl/.

The Microsoft DNS Server supports GSS-TSIG for securing dynamic
updates, but only for zones that are AD-integrated (stored in Active
Directory as opposed to a zone datafile). GSS-TSIG-secured dynamic
updates allow quite fine-grained access control to a
zone's contents. For example, the server can allow
only the specific host that added an A record for itself to change or
remove that record. This extra authorization can't
be stored in a zone datafilethere aren't the
necessary fieldsso the server needs to store a zone in Active
Directory to support secure dynamic updates. More information about
AD-integrated zones and secure dynamic updates can be found in Chapter 8.

11.1.2 NOTIFY (Zone Change Notification)

As we described earlier,



secondaries have traditionally used a
polling scheme to determine when they need a zone transfer. The
polling interval is called the refresh time and
it's specified as a field in a
zone's SOA record. Other parameters in the
zone's SOA record govern other aspects of the
polling mechanism.

But this scheme requires the secondaries to ask the primary,
"Has the zone changed yet?", over
and over. Wouldn't it be nice if the primary name
server could tell its secondary servers when the information in a
zone changed? After all, the primary name server knows the data has
changed: every time a zone is changed with the DNS console or a
dynamic update message is received, the server immediately changes
the zone in its memory. The primary's notification
can come soon after the actual modification instead of waiting for
the refresh interval to expire.

RFC 1996 describes a mechanism that allows primary servers to notify
their secondaries of changes to a zone's data. The
Microsoft DNS Server implements this protocol, called NOTIFY for
short.

NOTIFY works like this: when a primary name server notices a change
to data in a zone, it sends a special notification message to all
secondary servers for that zone. It uses the list of NS records in
the zone to build the list of servers to notify. The primary removes
any NS record corresponding to the local host, which prevents it from
sending a notification message to itself. You can also override using
the list of NS records and specify your own list of secondary servers
to notify.

The special NOTIFY request is
identified by its opcode in the query header. The opcode for most
queries is QUERY. NOTIFY messages have a special opcode, NOTIFY.
Other than that, the request looks much like a query for the SOA
record for the zone: it specifies the zone's domain
name, class, and a type of SOA.

When a secondary receives a NOTIFY request for a zone from one of its
configured master name servers, it sends a NOTIFY response. The
response tells the master that the secondary received the NOTIFY
request and to stop sending NOTIFY messages for the zone. Then the
secondary proceeds just as if the zone's refresh
timer had expired: it queries the master server for the SOA record
for the zone the master claimed had changed. If the serial number is
higher, the secondary performs the zone transfer, using an
incremental zone transfer if possible (see the next section for
details on this new kind of zone transfer).

Why doesn't the secondary simply take the
master's word that the zone has changed?
It's possible that a miscreant could forge NOTIFY
requests to our secondaries, causing lots of unnecessary zone
transfers that might amount to a denial-of-service attack against our
master server.

If the secondary actually transfers the zone, RFC 1996 says that it
should issue its own NOTIFY requests to the other authoritative name
servers for the zone. The idea is that the primary may not be able to
notify all the secondary servers for the zone itself, since
it's possible that some secondaries
can't communicate directly with the primary and so
use another secondary as their master. The Microsoft DNS Server
follows this behavior if NOTIFY is enabled for a secondary zone
(it's disabled by default for secondary zones) and
you don't list a specific set of name servers to
NOTIFY.

Here's how this process works in practice: on our
network, terminator.movie.edu is the primary for
movie.edu, and
wormhole.movie.edu and
zardoz.movie.edu are secondaries (as shown in
Figure 11-2).

Figure 11-2. movie.edu zone transfer example

When we update movie.edu on
terminator, terminator
sends NOTIFY messages to wormhole and
zardoz. Both secondaries check to see whether
movie.edu's serial number has
been incremented and, if they find it has, perform a zone transfer.

Let's also look at a more complicated zone transfer
scheme. In Figure 11-3, a is
the primary name server for the zone and
b's master server, but
b is c's
master server. Moreover, b has two network
interfaces.

Figure 11-3. Complex zone transfer example

In this scenario, a notifies both
b and c after the zone is
updated. b checks to see whether the
zone's serial number has been incremented and
initiates a zone transfer. However, c ignores
a's NOTIFY message because
a is not
c's configured master name
server (b is). If b is
explicitly configured to notify c, after
b's zone transfer completes it
sends c a NOTIFY message, which prompts
c to check the serial number
b holds for the zone.

Older BIND secondary name servers, and other name servers that
don't support NOTIFY, respond with a
"Not Implemented" (NOTIMP) error,
wait until their refresh timers expire, and then transfer the zone.
The Microsoft DNS Server just ignores the NOTIMP error.

NOTIFY is controlled on a zone-by-zone basis and is enabled by
default for primary zones (and disabled by default for secondary
zones). The controls for NOTIFY are somewhat hidden: highlight a zone
in DNS console's left pane, select Action Properties, and choose the Zone Transfers tab of the zone properties
window, which produces a window like the one shown in Figure 11-4.

Figure 11-4. Zone transfer configuration for movie.edu

Figure 11-5. NOTIFY configuration for movie.edu

Select the Notify button to open the
window shown in Figure 11-5, which illustrates the
NOTIFY configuration for the movie.edu zone on
the zone's primary, terminator.
You have two choices for configuring which servers get NOTIFY
messages for a zone. The first is to check the Servers listed on the Name Servers tab, which
lets the server decide based on the name servers listed in the
zone's NS records. (The Name
Servers tab of the zone properties window simply shows the
name servers listed in the zone's NS records.) The
second choice is to specify exactly which secondary servers should
receive NOTIFY messages. This option is required if you have
secondary servers not listed in the zone's NS
records: such secondaries are effectively hidden, and the only way
the primary knows to send NOTIFY messages to them is if you tell it
to.

11.1.3 Incremental Zone Transfer

The Microsoft DNS Server in
Windows 2003 supports a new kind of zone transfer. Incremental zone
transfer, or IXFR for short, is specified in RFC 1995, and it does
exactly what you'd expect based on its name. A
traditional zone transfer always transfers the entire contents of a
zone, even if only one record has changed. Incremental zone transfers
allow a name server to send a list of just the records that have
changed since the last zone transfer (whether it was a full or
incremental one).

This new feature is critical for zones that change frequently.
Imagine the scenario with dynamic update: every dynamic update is a
change to the zone that requires a zone transfer. Doing a full zone
transfer with every small change wastes bandwidth and CPU time. The
situation is compounded when the zone being updated and transferred
is large.

For IXFR to function, the master servers need to keep track of the
differences between successive versions of the zone. A secondary
requests an incremental zone transfer and presents its current serial
number. The master server calculates and sends the changes needed on
the secondary to make its version of the zone current. If the master
server can't calculate the changes for whatever
reasonperhaps the secondary has an old version of the zone and
the primary hasn't kept a record of changes that far
backthe primary is allowed to say "Sorry, but
you've got to accept a full zone
transfer."

A Microsoft DNS Server acting as a secondary requests an incremental
zone transfer by default. If the master server
doesn't support incremental zone transfer, the
Microsoft DNS Server asks for a standard full zone transfer. A
Microsoft DNS Server acting as a primary master stores a record of
changes going back several versions. The number of versions the
server keeps in memory depends on the zone's size:
it keeps 25% of the total number of resource records of the zone, up
to a total of 64,000. For example, given a zone of 100 resource
records, the server would store changes corresponding to the last 25
versions of the zone. It responds with a full zone transfer instead
of an incremental when it doesn't have the necessary
information to produce the list of changes to the zone or when the
list of changes would be larger than a full zone transfer.

AD-integrated zones introduce an extra wrinkle. Recall that every
server for an AD-integrated zone stores the zone in Active Directory.
Because of Active Directory's multimaster
replication scheme, the notion of one server being a
"primary" doesn't
apply anymore. Instead, any of the zone's
authoritative servers can accept a dynamic update for the zone. The
change is stored locally and replicated to the other servers using
Active Directory. This situation means that different servers can
potentially apply changes to the zone in a different order. To
maintain a consistent view of changes to a zone, a secondary must
always use the same master server. If a particular master server
becomes unavailable and a secondary is forced to use another, it
automatically requests a full zone transfer for the first transfer
from that server to avoid inconsistencies.

11.1.4 More Efficient Zone Transfers

As long as we're on the topic of zone transfers, we
should mention another enhancement.


A zone
transfer comprises many DNS messages sent end-to-end over a TCP
connection. Traditional zone transfers put only a single resource
record in each DNS message. That's a waste of space:
you need a full header on each DNS message, even though
you're carrying only a single record.
It's like being the only person in a Chevy Suburban.
A DNS message can carry many more records.

The Microsoft DNS Server understands
a newer zone-transfer format that puts as many records as possible
into a single DNS message. The resulting "many
answers" zone transfer takes less bandwidth because
there's less overhead and less CPU time because less
time is spent unmarshaling DNS messages.

The DNS server uses the "many
answers" format by default, which is fine if all
your secondaries can understand it. Older BIND name servers (prior to
Version 4.9.4) can't cope with this format and
require the traditional one. Fortunately, you can tell the Microsoft
DNS Server to use the traditional method with a server properties
setting. Right-click on a server in the left pane of the DNS console
and choose Properties, then select
the Advanced tab. Click the box next
to BIND secondaries. When this box
is checked, the server sends traditional zone transfers to satisfy
older BIND servers. The box is checked by default, but that
doesn't affect zone transfers between two Microsoft
DNS Servers. They recognize each other, and the master uses the
"many answers" format to the
secondary.

You should change this setting only if you have no BIND secondaries
or if all your BIND secondaries are running Version 4.9.4 or later.