Recommendations on integrating BIND and AD
Kevin Darcy
kcd at daimlerchrysler.com
Fri Jan 30 01:21:18 UTC 2004
Bell, William IT wrote:
>Hi all,
>I've read the 'DNS and Windows 2000' section in Chapter 16 of "DNS and
>BIND", and I've searched through the BIND archives and the internet. Not
>much luck, so I'd like to ask my questions here on the two lists that should
>know the most about it...
>
>Our company is in the midst of implementing AD for its Windows servers and
>PC workstations, but the heart and soul of our data center is UNIX, both IBM
>AIX and Sun Solaris. Here's how we're configured:
>
>- ALL internal DNS is handled by two Solaris servers running BIND 9; all
>PC's and servers resolve their DNS from these two servers
>- These two servers also handle the DHCP (running ISC DHCP v3), but we don't
>do any DDNS
>- All servers have static DNS entries
>- All PC workstations do DHCP and get their network & TCP/IP settings from
>these DNS/DHCP servers
>- AD is running on Windows 2003 Server
>
>The AD admin has proposed that we change our blissful existence by doing the
>following:
>- Create a subdomain for AD
>- Change TCP/IP settings on all PC workstations and Windows servers to point
>to the AD servers for DNS resolution
>
Why? This point seems completely severable from everything else. Can he
give a business case for providing DNS resolution services from
Microsoft servers as opposed to the BIND servers you already have
deployed? Note that MS-DNS and AD are different products. You don't have
to run them on the same box unless you want "AD-integrated" DNS, and
even in that case, my understanding is that AD-integrated only makes the
server a master (note the phrase "a master", since Microsoft touts its
"multi-master" capability); you could still use the BIND servers for
name resolution. If "AD-integrated" is what he's pushing -- or simply
assuming -- let him make a separate business case for that first.
>- Remove all Windows servers from BIND DNS and move to AD (and it's
>subdomain), leaving only UNIX and network devices in BIND DNS
>
The only value I can see of this is so that the Domain Controllers can
update their own IP addresses if they are moved. Whoop-de-doo. You
probably already have procedures in place -- perhaps even automated or
semi-automated ones -- for updating DNS when servers move, and unless
they are moving around *a*lot*, it shouldn't be very much work to keep
DNS up to date. So how much value does putting the names of the AD
servers into the AD subdomain add, really? Is it worth the cost of
breaking whatever naming conventions and/or paradigms you already have
in place?
>- For any DNS requests not resolved in AD, forward them to our BIND DNS
>servers
>
Well, what do you mean by "forward" here? Obviously if you delegate
chunks of your namespace to different nameservers, then if a server
needs to resolve a name that it's not authoritative for, it'll have to
send the query to some other nameserver. I suppose one could call that
"forwarding", but coming from a BIND perspective, I tend to limit the
term "forwarding" to *overrides* of the normal iterative-resolution
process, and I don't see any need for that here.
>- Take over DHCP (Microsoft DHCP) so that they can do secure dynamic updates
>and begin using Microsoft's Remote Installation Services (RIS)
>
You seem to be *assuming* here that clients need to be registered
dynamically in DNS. As far as I know, Active Directory _per_se_ does not
require that clients be registered in DNS. Various utilities which run
on Win2K and above, e.g. SMS, which may or may not interact with Active
Directory, may require client registration or it may be "convenient"
within the utility for the clients to be registered, so that the
user/administrator can see names instead of just IP addresses. So I
think your first order of business is to establish whether client
registration is a requirement or merely a "would be nice" item.
Understand that if you have no other reason to register clients in DNS,
there is a substantial cost in terms of resources, complexity,
supportability, etc. to start registering them, regardless of what
platform you use for the registration. So you should only do this if it
makes business sense for your organization, not just because "Microsoft
recommends it" or "it looks prettier in the GUI".
As for the question of whether or not to use Microsoft's products for
DNS and/or DHCP, I think you need to make some decisions about what DHCP
and DNS platforms you really want to use in your enterprise, and why.
Tally up all of the advantages and disadvantages of using ISC products
versus using Microsoft products. Interoperability between your DNS and
DHCP platforms is, if you decide to do client registration, *a* factor
to consider in choosing what products to use for DNS and DHCP, but it
should probably not be the *overriding* factor. True, if you use
incompatible products, you can't cryptographically secure the Dynamic
Updates. Is that a security-policy showstopper in your environment? You
should look both at how the products perform alone and how they work
together. Being not a user of ISC DHCP, I'm not sure what this "cleaning
up leases" issue (mentioned below) supposedly is, but if it is indeed
still an unresolved issue, figure it into your assessments. But also
figure in things like scalability, the negative effect of "lock-in" to a
particular vendor's products, the costs of training or retraining
administrators, etc. There are many dimensions to such decisions. Only
you know what matters most to your users and technical staff in your
particular environment.
I'll have to plead ignorance with respect to RIS, since I've never heard
of that product before.
>- Microsoft DHCP server will do DDNS updates
>
Given the assumption that you're doing to use Microsoft DHCP, it's a
reasonable follow-on to say that Microsoft DHCP will perform the Dynamic
Updates. But I would challenge the initial assumption that you're going
to use Microsoft DHCP.
>I proposed the solution contained in Chap. 16 (Problems with Windows 2000
>and BIND) using the existing BIND DNS servers as primary, creating the 4
>delegated microsoft "SRV" subdomains, and allowing the DDNS for the PCs',
>services, etc. to pass thru to the AD server.
>
Um, no. Nothing "passes through" to the AD server. The BIND server would
accept the Dynamic Updates in that example. I think you might be
confusing this example with the idea of delegating one or more zones to
the Domain Controllers. But even in that case, you're not "passing
through" Dynamic Updates; the clients will eventually (possibly with the
help of BIND nameservers) find out that the DC or DCs are the master(s)
for the zones they want to update, and then send the Dynamic Updates
directly there. No "passing through".
> The AD admin claims that this
>is more difficult to implement.
>
Why? What's the extra work involved from his side?
>He also states that ISC DHCP won't do
>secure dynamic updates with AD, thus preventing them from working together.
>
True. If cryptographically-secure Dynamic Updates is a hard requirement
for you, then you need to stick with ISC for both your DNS and DHCP
server platform (actually you could mix-and-match any implementations
which support regular TSIG), or go with Microsoft for both platforms, at
least with respect to the part(s) of your namespace which are going to
be dynamically-updateable.
>In addition, he says that ISC doesn't properly expire leases in AD.
>
>
Wouldn't know. Don't use ISC's DHCP implementation...
>So which way is best:
>Is it better to make the BIND servers forward off any AD queries to the AD
>servers (Chap. 16 solution) or is it better to have the AD servers forward
>off any non-AD queries to the BIND servers (Windows solution)?
>
As pointed out above, I think you might be misunderstanding the example.
There is no "forwarding" or "passing through" in the example.
More generally, there are multiple ways to harmonize BIND and
AD/Windows. One suggestion in Chapter 16 is to delegate a subzone of
your main domain strictly for Windows stuff. Another suggestion (not
mentioned in Chapter 16; I'm making this myself) is to go out and
register another domain completely unrelated to your main domain, for
internal use by AD and/or Windows. Another suggestion (also not
mentioned in Chapter 16), is to delegate each of the "underscore"
subdomains to the Domain Controllers and let them manage them however
they want. Another suggestion in Chapter 16 is to turn off Dynamic
Updates completely and $INCLUDE the netlogon.dns file into a zone file
(you'd have to have some non-Dynamic-Update-based mechanism of keeping
it up to date). Another suggestion (given in the configuration example)
is to delegate the "underscore" subdomains to your BIND box and only
open those particular subzones up for Dynamic Updates coming from the
Domain Controllers. Note that the first two suggestions -- delegate a
subzone of your main domain, or purchase a completely separate domain --
are to address the requirement of client registration, whereas the rest
are to deal with Domain Controllers wanting to register SRV records (and
maybe the occasional A and/or CNAME record) dynamically. In any case,
while there may be multiple solutions here, none of them involve
forwarding. Whether the "underscore" subdomains are separate zones or
not, neither the Microsoft DNS server nor a BIND server should have
problems resolving names in the main domain or the delegated subdomains,
assuming all of the delegations are done correctly. So you are free to
choose which platform you prefer for ordinary day-to-day DNS resolution
for your clients. What nameservers clients use for resolving DNS is a
*separate* question from whether you should use Microsoft or ISC
products to manage your DHCP and/or DNS leases and/or resource-record
data, and a separate question yet again from whether and/or how you want
to integrate DNS and DHCP.
In our environment, for instance, we do not register clients in DNS,
clients use BIND nameservers for name resolution, and we allow Domain
Controllers to update their SRV records etc.,but for production purposes
only in a namespace which we have established wholly separate from any
of our other DNS namespaces. This is one combination among many possible
combinations, and represents a lot of trade-offs, negotiations,
confrontations, etc. And we haven't really rolled out AD in earnest, so
the chapter isn't even closed yet...
>If there's strong support for doing this using the Chap. 16 method, I could
>use some good arguments, examples, and any tales of woe that you can
>provide. It's best to have lots of ammo when heading into a firefight. ;)
>
As pointed out above, there are actually multiple suggestions in Chapter
16, as well as other unmentioned possible solutions to the same
problems. Be wary of fixating on one BIND-based or hybrid solution. One
of the good things about BIND (I don't know if the same can be said to
the same degree of Microsoft's offerings) is that there is a lot of
flexibility in how you can set things up.
- Kevin
More information about the bind-users
mailing list