You’ve heard the old saying, “If you can’t beat ‘em, join ‘em.” Well, if Microsoft were to adopt a corporate motto, it might be something more like, “If you can’t beat ‘em, embrace and extend ‘em.” Seriously, Microsoft knows when it’s fighting an uphill battle on a technical front. When it’s clear that a Microsoft-fostered initiative will not take over the world, they eventually adopt the dominant standard. Sort of…
With Windows 2000, Microsoft finally did away with WINS (Windows Internet Naming Service, Microsoft’s proprietary NETBIOS naming service) and began using the Domain Name System (DNS), the Internet’s standard naming service. This seems like good news for those who run (or aspire to run) pure, simple, IP-based networks. However, Windows 2000 was written to work best with (guess what?) the Microsoft DNS Server.
Historically though, BIND, the Berkeley Internet Name Domain software, has been the most popular implementation of DNS. And while it’s certainly possible to support a Windows 2000 environment using a traditional BIND name server, it requires some special configuration. In this article, we’ll explore a number of configuration options and gain a thorough understanding of how to accommodate Windows 2000 with BIND. First though, let’s examine how Windows 2000 uses DNS.
Before we proceed, one quick note — for the purposes of this article, we assume that you are familiar with the inner workings of traditional BIND name servers. If you’re not, please check out the article Using DNS in the September 2000 issue of Linux Magazine. You can find it on the Web at http://www.linux-mag.com/2000-09/dns_01.html.
How Windows 2000 Uses DNS
Back in the bad, old days of WINS, Windows clients “registered” their current NETBIOS name-to-address mappings with WINS servers when they were assigned IP addresses via DHCP (Dynamic Host Configuration Protocol). NETBIOS names were allocated out of a flat name space, and all WINS servers on an organization’s network were supposed to have complete, synchronized copies of this name space. If a Windows client registered with one WINS server, that WINS server would tell all of its “replication partner” WINS servers about that client’s name-to-address mapping. These partners would, in turn, tell their partners, and so on. This made WINS servers very chatty. This relatively unsophisticated synchronization mechanism could also leave inconsistencies among WINS servers. In addition, the use of a flat name space for NETBIOS names could result in naming conflicts between WINS servers.
Now DNS provides a feature, described in RFC 2136 (http://www.ietf.org/rfc/rfc2136.txt), called dynamic update. Dynamic update allows an authorized updater to modify the contents of a zone on the zone’s primary master name server. The updater can add or delete records from the zone and can make those operations contingent upon certain conditions, like the existence or non-existence of a particular domain name or record.
Why didn’t Microsoft simply use DNS’s dynamic update mechanism to handle registration, obviating the need for a separate, largely redundant naming service? Well, WINS was developed well before the advent of dynamic update.
Windows 2000 Clients
Nowadays, both Windows 2000 clients and servers use DNS. A Windows 2000 client with a static IP address registers its name-to-address and address-to-name mappings by sending dynamic updates. One update adds the client’s address (A) record and another adds the client’s pointer (PTR) record. For example, a client called host.a.example with the address 10.0.0.1 would send updates to add the two records, as illustrated in Figure One.
host.a.example. IN A 10.0.0.1
1.0.0.10.in-addr.arpa. IN PTR host.a.example.
|
The first of these records maps host.a.example’s domain name to the address 10.0.0.1. The second maps the address 10.0.0.1 to the domain name host.a.example. Both records are necessary to ensure correct forward- and reverse-mapping.
A Windows 2000 client with a dynamic IP address (running DHCP) also registers its name-to-address mapping, but by default its DHCP server registers the client’s address-to-name mapping. In other words, the DHCP client sends the update to add the A record, while its DHCP server sends the update to add the appropriate PTR record.
An administrator can also configure the DHCP server to handle sending all dynamic updates. This is meant for use with DHCP clients that lack the ability to update their own name-to-address mappings but works with Windows 2000 DHCP clients also. The server sets a special DHCP option that tells the client, “Just relax — I’ll do all the work.” Then the DHCP server sends the updates to add the A and PTR records.
Windows 2000 clients set dynamic update prerequisites when adding A records. Prerequisites allow an updater to specify conditions that must hold before the update is applied. For instance, the updater could specify that the A record for host.a.example that was shown earlier should be added only if the domain name host.a.example doesn’t already have an A record associated with it, or only if the domain name host.a.example doesn’t already exist. In fact, this is very similar to the prerequisites actually specified by Windows 2000 clients, which are:
1. The domain name of the client must not already own an address record.
2. The domain name of the client must not be an alias.
What happens when a Windows 2000 client’s update is denied because a prerequisite isn’t satisfied? Well, if there’s a conflicting A record, the client deletes the offending record and tries again. Why? Well, the A record could be an old record that the client added, and didn’t later delete, when it had a different name-to-address mapping.
Windows 2000 Domain Controllers
Windows 2000 Domain Controllers use DNS too, but for a different reason. Domain Controllers send dynamic updates to add SRV records that advertise where (on which host and port) various services are available. This way, when a Windows 2000 client needs to reach the Kerberos server for its domain, it can simply look up the right SRV record.
SRV records, in case you’re not familiar with them, have a fairly complicated syntax, especially when compared to the more common A and PTR records. First, the owner name in an SRV record isn’t just any old domain name; it has a special format:
_service._protocol.domain name
service is the name of a network service, as might appear in the /etc/ services file, like telnet. protocol is the name of a transport protocol, usually udp or tcp. Both the service and the protocol identifiers follow an underscore, which is used to avoid collisions between domain names that own SRV records and domain names that represent hosts.
All SRV records are attached to domain names in this format. They then apply to clients of the named service running over the specified transport protocol. So, the hypothetical domain name _http._tcp.verisign.com applies to HTTP clients (e.g., Web browsers) running over TCP and trying to access the destination domain name verisign.com.
Each SRV record has four record-specific fields: priority, weight, port, and target. Priority, weight, and port are all unsigned, 16-bit integers, while target is a domain name. Figure Two contains a few sample SRV records.
_http._tcp.movie.edu. IN SRV 0 0 80 www.movie.edu.
_http._tcp.movie.edu. IN SRV 1 1 80 www1.movie.edu.
_http._tcp.movie.edu. IN SRV 1 1 8080 www2.movie.edu.
|
Let’s take Figure Two apart, field-by-field:
> Priority functions similarly to the preference field in an MX (Mail Exchange) record; if a client finds that multiple SRV records apply to a destination that it’s accessing, it must use the SRV records in the order specified by the records’ priority fields, lowest priority value first. So a Web browser that is retrieving these SRV records would first try to contact www.movie. edu before trying www1.movie.edu and www2.movie.edu.
> The weight field is used for load distribution; if a client finds multiple SRV records with the same priority, it must use the corresponding targets in proportion to their weights. So a Web browser that isn’t able to contact www.movie.edu would then have to choose randomly between www1. movie.edu and www2.movie.edu. The client would choose www1.movie. edu first 50 percent of the time and www2.movie.edu first the other 50 percent of the time.
> The port field simply tells the client which port the service is running on. HTTP, of course, normally runs on port 80. www2.movie.edu, however, runs its Web server on the non-standard port 8080, so an SRV-aware Web browser would try that port instead.
> Finally, the target field simply tells the client the domain name of a host running the service. The priority, weight, and port information in an SRV record only apply to the target specified in that record.
Windows 2000 Domain Controllers add a sheaf of SRV records when you set them up. Figure Three contains a list of the records our Domain Controller added to our zone shortly after we set it up.
$ORIGIN fx.movie.edu.
@ 600 A 192.253.254.14
_kerberos._tcp.dc._msdcs 600 SRV 0 100 88 matrix.fx.movie.edu.
_ldap._tcp.dc._msdcs 600 SRV 0 100 389 matrix.fx.movie.edu.
_ldap._tcp.e437709a-1862-11d3.domains._msdcs 600 SRV 0 100 389 matrix.fx.movie.edu.
e4377099-1862-11d3-8eda-00400536c213._msdcs 600 CNAME matrix.fx.movie.edu.
gc._msdcs 600 A 206.168.119.178
_ldap._tcp.gc._msdcs 600 SRV 0 100 3268 matrix.fx.movie.edu.
_ldap._tcp.pdc._msdcs 600 SRV 0 100 389 matrix.fx.movie.edu.
_gc._tcp 600 SRV 0 100 3268 matrix.fx.movie.edu.
_kerberos._tcp 600 SRV 0 100 88 matrix.fx.movie.edu.
_kpasswd._tcp 600 SRV 0 100 464 matrix.fx.movie.edu.
_ldap._tcp 600 SRV 0 100 389 matrix.fx.movie.edu.
_kerberos._udp 600 SRV 0 100 88 matrix.fx.movie.edu.
_kpasswd._udp 600 SRV 0 100 464 matrix.fx.movie.edu.
|
Most of the records in Figure Three make sense if you know that a Domain Controller is basically a combo Kerberos/LDAP server; _kerberos, _ldap, and _kpasswd are all services that are related to these functions. _gc is Active Directory’s Global Catalog service, which is used to find out which Active Directory server has information about a particular object.
You should also notice that two of the records aren’t SRV records at all — they’re A records. One is attached to the domain name of the zone (”@” is shorthand for “the current origin,” which is fx.movie.edu, the domain name of our zone). Another record is attached to the domain name gc._ msdcs.fx.movie.edu. However, all of the records — not just the SRV records — point to either the domain name or the IP address of our Domain Controller, matrix.fx.movie.edu.
BIND Solutions
There are several ways to configure BIND to satisfy all of Windows 2000’s requirements. Not one is perfect. We’ll examine these solutions and point out the advantages and disadvantages of each.
Letting Each Windows 2000 Client Send Updates
By default, each Windows 2000 client will try to update its own name-to-address mapping. If you want to permit these updates, simply allow dynamic updates to your forward-mapping zone (the zone that contains your hosts’ A records) from any IP address that a Windows 2000 client might have.
First, define an access control list in the name server’s named.conf file. This ACL will correspond to the IP addresses of all of our DHCP clients and will let us refer to them by the name “dhcp-clients” (rather than having to specify their addresses). You can do this as follows:
acl “dhcp-clients” {
192.253.254/24;
};
Now that we’ve defined the ACL, we can refer to it elsewhere in the named. conf file. To restrict dynamic update to a zone, we use the name of the ACL in an allow-update substatement:
zone “fx.movie.edu” {
type master;
file “db.fx.movie.edu”;
allow-update{ “dhcp-clients”;};
};
Does allowing dynamic updates from any DHCP client sound scary? It is.
A user on any computer with one of those IP addresses could make just about any change to your forward-mapping zone. All he would have to do is load the appropriate software and he could make www.fx.movie.edu an alias for www.whitehouse.com. Or, he could just delete all of fx.movie. edu. Consequently, we don’t recommend this.
Letting the DHCP Server Send All Updates
A somewhat saner approach is to configure the DHCP server to handle updating both a client’s name-to-address and its address-to-name mappings. You can configure this through the DHCP Manager.
Since you now know that all dynamic updates will come from your DHCP server’s IP address, you can easily restrict dynamic updates to just that IP address, as illustrated in Figure Four.
acl “dhcp-server” {
192.253.254.2;
};
zone “fx.movie.edu” {
type master;
file “db.fx.movie.edu”;
allow-update{ “dhcp-server”;};
};
zone “254.253.192.in-addr.arpa” {
type master;
file “db.192.253.254″;
allow-update{ “dhcp-server”;};
};
|
Note that we also let the DHCP server update our reverse-mapping zone, 254.253.192.in-addr.arpa.
What’s wrong with this? Well, one problem is that the DHCP server simply believes a client when it specifies its fully qualified domain name. In other words, if you configure your Windows 2000 client with the domain name www.fx.movie.edu, the DHCP server will delete any conflicting address record at that domain name and add a record pointing www.fx.movie. edu to your client’s IP address. This is no good.
Isolate Windows 2000 Clients
For maximum protection you can isolate your clients in their own zone. By default, Windows 2000 assumes that the domain name of your clients’ forward-mapping zone is the same as the name of the Windows 2000 domain that they belong to. However, Windows 2000 will also allow you to specify the domain name of the zone independently.
The easiest way to do this is by right-clicking on My Computer and choosing Properties. Next, choose the Network Identification tab and click the Properties button. On the Identification Changes window, click the More… button. Now fill in the domain name of the new forward-mapping zone in the field labeled Primary DNS suffix of this computer. This doesn’t have to be the same as the name of the Windows 2000 domain.
Let’s say we create a new subzone of our main forward-mapping zone just for Windows 2000 clients. We’ll call it dhcp.fx.movie.edu (though we could certainly configure statically addressed clients to register in it too). We would configure our BIND name servers to accept dynamic updates to that zone from any Windows 2000 client, as illustrated in Figure Five.
acl “dhcp-clients” {
192.253.254/24;
};
acl “dhcp-server” {
192.253.254.2;
};
zone “fx.movie.edu” {
type master;
file “db.fx.movie.edu”;
};
zone “dhcp.fx.movie.edu” {
type master;
file “db.dhcp.fx.movie.edu”;
allow-update{ “dhcp-clients”; };
};
zone “254.253.192.in-addr.arpa” {
type master;
file “db.192.253.254″;
allow-update { “dhcp-server”; };
};
|
Note that we still need to let our DHCP server update our reverse-mapping zone. If we have clients with static addresses, they will update their own PTR records. We should include them in the access control list for the reverse-mapping zone.
We’ve effectively created a little sandbox (or asylum, if you prefer) for our Windows 2000 clients. They can trash it if they want — deleting each other’s address records, for example — but they won’t interfere with records in our main forward-mapping zone, fx.movie.edu.
Letting Only the Domain Controller Update the Zone
Now we’ve got to take care of the Domain Controller. The DC, you’ll remember, will try to add all sorts of SRV records (and a couple of A records) to our forward-mapping zone. We could just let it update the zone. This is less problematic than letting some random Windows 2000 client update the zone, since we have complete control of the Domain Controller. If we choose to go that route, we simply allow updates from the Domain Controller’s IP address to our main forward-mapping zone, as illustrated in Figure Six.
acl “dhcp-clients” {
192.253.254/24;
};
acl “dhcp-server” {
192.253.254.2;
};
acl “domain-controller” {
192.253.254.3;
};
zone “fx.movie.edu” {
type master;
file “db.fx.movie.edu”;
allow-update { “domain-controller”; };
};
zone “dhcp.fx.movie.edu” {
type master;
file “db.dhcp.fx.movie.edu”;
allow-update { “dhcp-clients”; };
};
zone “254.253.192.in-addr.arpa” {
type master;
file “db.192.253.254″;
allow-update { “dhcp-server”; };
};
|
We’re fairly safe as long as we don’t allow anyone to send arbitrary dynamic updates from the Domain Controller to our name server.
Creating Special SRV Subzones
What if you’re skeptical of your Domain Controller’s security? Or what if you don’t trust the dynamic update code in Windows 2000 not to trash your main forward-mapping zone? Well, you can certainly take advantage of the funny format of the owner names in those SRV records and create subzones for all of those records to live in.
Remember that, generally, SRV records have the form:
_service._protocol. domain name
The protocol for most services is either udp or tcp. Microsoft also uses the pseudo-protocols msdcs and sites. So we’ll just create subzones called _udp.fx.movie.edu, _tcp.fx. movie.edu, _msdcs.fx.movie. edu and _sites.fx.movie.edu. However, we’ll have to take one special precaution — because the A record that the Domain Controller wants to add to the _msdcs.fx.movie. edu zone would otherwise be illegal, we’ve got to turn off name checking for that zone. (Domain names that own A records are potentially hostnames. Therefore, they must follow Internet hostname syntax, which doesn’t allow the use of underscores.) This would look like Figure Seven.
acl “dhcp-clients” {
192.253.254/24;
};
acl “dhcp-server” {
192.253.254.2;
};
acl “domain-controller” {
192.253.254.3;
};
zone “fx.movie.edu” {
type master;
file “db.fx.movie.edu”;
};
zone “_udp.fx.movie.edu” {
type master;
file “db._udp.fx.movie.edu”;
allow-update { “domain-controller”; };
};
zone “_tcp.fx.movie.edu” {
type master;
file “db._tcp.fx.movie.edu”;
allow-update { “domain-controller”; };
};
zone “_msdcs.fx.movie.edu” {
type master;
file “db._msdcs.fx.movie.edu”;
allow-update { “domain-controller”; };
check-names warn;
};
zone “_sites.fx.movie.edu” {
type master;
file “db_sites.fx.movie.edu”;
allow-update { “domain-controller”; };
};
zone “dhcp.fx.movie.edu” {
type master;
file “db.dhcp.fx.movie.edu”;
allow-update { “dhcp-clients”; };
};
zone “254.253.192.in-addr.arpa” {
type master;
file “db.192.253.254″;
allow-update { “dhcp-server”; };
};
|
This is a nice, safe configuration, because we can deny all dynamic updates to our main forward-mapping zone.
GSS-TSIG
How does Microsoft avoid this mess? They use “Secure Dynamic Updates,” which carry with them the identity of the updater. The Microsoft DNS Server can then make sure, for example, that only the DHCP client that added a given A record can later delete it and add another A record to that domain name.
Microsoft’s “Secure Dynamic Updates” are really just standard dynamic updates with transaction signatures (TSIGs), as specified in RFC 2845 (http://www.ietf.org/rfc/rfc2845.txt). Unfortunately, the particular dialect of TSIG that Windows 2000 clients and name servers speak, GSS-TSIG, is not presently spoken by any other name servers.
By the way, the “GSS” in “GSS-TSIG” is the same “GSS” in “GSSAPI,” the Generic Security Service API. GSSAPI is an IETF standard API that provides a uniform, high-level API to security services like authentication and confidentiality.
That may change with a future version of BIND 9. BIND 9 is scheduled to support GSS-TSIG in a future release. Once it does, you’ll be able to use BIND 9’s new update-policy mechanism to determine which domain names and records in a zone a particular TSIG key has authority to update. This would make our solution much simpler.
To whet your appetite for GSS-TSIG support in BIND, Figure Eight illustrates a configuration that would ensure that only the Domain Controller could update the SRV records in the zone and that DHCP clients could only update those address records that are attached to their own domain names.
zone “fx.movie.edu” {
type master;
file “db.fx.movie.edu”;
update-policy {
grant *.fx.movie.edu. self *.fx.movie.edu. A;
grant matrix.fx.movie.edu. subdomain fx.movie.edu. SRV;
};
};
|
For now though, we will have to be satisfied with the solutions that we have, inelegant as they may be. What’s important, however, is that you can safely use BIND to service a Windows 2000 environment.
Cricket Liu is the Director of DNS Product Development for VeriSign Global Registry Services and is author of DNS and BIND. Cricket can be reached at cricket@verisign.com.
Loading ...
No Comments
No comments yet.