Recommendations on integrating BIND and AD

[Kevin Darcy]

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