Newsgroup: it.comp.os.win.win2000
Titolo: Come usare BIND per Active Directory [lunghissimo]

Dato che qualcuno l'ha chiesto ecco come usare BIND al posto del DNS
MS per l'Active Direcotry.
-------------
Introduction
 
The Domain Name System (DNS) Server provided with Windows 2000 Server
is an IETF standard-based DNS server that fully supports Active
Directory and is fully interoperable with other standards-based
implementations of DNS server, that offers excellent performance, easy
installation and configuration, as well as graphical, and scriptable
administration options. For these reasons, the Windows 2000 DNS server
is recommended for supporting Windows 2000 networks and Active
Directory. Many environments may have non-Microsoft DNS
implementations in place, and may wish to implement Active Directory
before migrating to Microsoft’s DNS server.  This white paper
addresses requirements for configuring Berkeley Internet Name Domain
(BIND) DNS servers to support Active Directory to facilitate such a
migration, prior to migrating to Microsoft’s DNS server.
Active Directory offers many features that reduce administrative
overhead, and increase security. It is likely that system
administrators will wish to implement Active Directory to take
advantage of these features., the purpose of this document is to
assist administrators who wish to use existing Berkeley Internet Name
Domain  (BIND) servers to support Active Directory. It covers
interoperability issues between Active Directory and BIND, BIND
configuration, and testing and verification of BIND support of Active
Directory.
This paper assumes familiarity with DNS. It provides a quick overview
of how Windows 2000 and Active Directory use DNS, the records stored
by Active Directory in DNS, and minimum DNS requirements for support
of Active Directory.  This paper does not cover any DNS fundamentals;
consult the Additional Reading section for a list of resources on this
and other related topics. 
Additional Reading
 
·Windows 2000 DNS White Paper
·Designing the Active Directory Structure chapter in the Deployment
Planning Guide
·Active Directory papers
·”DNS and BIND” (Cricket Liu) published by O'Reilly and Associates,
3rd Edition ISBN: 1-56592-512-2
How Windows 2000 Uses DNS
 
Host Name Resolution
 
Like any other Internet Protocol (IP) host, Windows 2000 uses DNS
primarily for resolving Internet names to IP addresses (host name
resolution), and resolving IP addresses to fully qualified domain
names (reverse lookup). 
Service Location
 
DNS is the primary name-resolution method used by Windows 2000
computers to locate services on the network, including locating domain
controllers for logon. DNS in Windows 2000 replaces the service
location functions provided by the WINS service. WINS was the
Microsoft implementation of NetBIOS Name Service, which was used in
earlier versions of Windows NT® to locate domain controllers and other
network services. (Down-level clients such as Windows NT 3.5 and 3.51,
Windows NT 4.0, Windows 95, and Windows 98 still require WINS servers
to locate network services.)  Network services and domain controllers
are advertised in DNS using Service Locator (SRV) records.
Service Locator (SRV) Records
 
Service Locator (SRV) resource records (defined in RFC 2782) allow
multiple servers providing a similar TCP/IP-based service to be
located using a single DNS query operation. These records enable you
to maintain a list of servers for a well-known server port and
transport protocol type, ordered by preference for a DNS domain name.
For example; SRV records provide a means for Windows 2000 clients to
locate domain controllers that use Lightweight Directory Access
Protocol (LDAP) service over TCP port 389. 
The purposes of each of the specialized fields used in an SRV resource
record are as follows:
·service  A symbolic name for the desired service. For well-known
services, a reserved universal symbolic name such as "_telnet" or
"_smtp" is defined in RFC 1700. If a well-known service name is not
defined in RFC 1700, a local or user-preferred name can be used
instead. Some widely used TCP/IP services, notably the Post Office
Protocol (POP), do not have a single universal symbolic name. If RFC
1700 assigns a name for a service indicated in this field, the
RFC-defined name is the only name that is legal to use. Only locally
defined services can be named locally. 
·protocol  Indicates the transport protocol type. Typically, this is
either TCP or UDP, although any transport protocol named in RFC 1700
can be used. 
·name  The DNS domain name referred to by this resource record. The
SRV resource record is unique among other DNS record types in that it
is not used to perform the search or query. 
·priority  Sets the preference for a host specified in the target
field. DNS clients that query for SRV resource records attempt to
contact the first reachable host of the lowest numbered preference
listed here. Although target hosts have the same stated preference
value, they can be tried in random order. The range of preference
values is 0 to 65535. 
·weight  Can be used in addition to preference to provide a
load-balancing mechanism, where multiple servers are specified in the
target field and are all set to the same level of preference. When
selecting a target server host among those of equal preference, this
value can be used to set an added level of preference that can be used
to determine the exact order or balancing of selection for the target
hosts used in an answered SRV query. When a non-zero value is used,
servers of equal preference are tried in proportion to the weight of
this value. The range of values is 1 to 65535. If load balancing is
not needed, use a value of 0 in this field to make the record easier
to read. 
·port  This is the server port on the target host that provides the
service indicated in the service field. The range of port numbers is 0
to 65535, although the number is often a well-known assigned service
port number, as specified in RFC 1700. Unassigned ports can be used as
needed. 
·target  Specifies the DNS domain name of the host that provides the
type of service being requested. For each host name used, a
corresponding host address (A) resource record in the DNS namespace is
required. A single period (.) can be used in this field to indicate
authoritatively that the requested service specified in this SRV
resource record is not available at this DNS domain name. 
Service Locator (SRV) Record Examples
 
Syntax:     
service.protocol.name
  ttl  class  SRV  preference  weight
port  target
Example:     _ldap._tcp.ms-dcs    SRV  0 0   389
dc1.example.microsoft.com
 
                                                        SRV 10 0   389
dc2.example.microsoft.com
 
Active Directory and DNS
 
DNS Requirements to Support Active Directory
 
In order for a DNS server to be able to support the Active Directory
it is required to support the SRV records so that domain controllers
can be located for authentication and query purposes.
A Windows 2000 domain is represented by a DNS domain name (for
example, nt.microsoft.com.). Each domain controller registers its
address with DNS using the standard DNS dynamic update (these records
may be added manually if the DNS server does not support dynamic
updates).  Each domain controller registers a host record (A record),
and several SRV records.
For example, a domain controller named dc1 in the 
ad.mydom.com
 domain
with an IP address of 4.2.2.3 would register the following records
with DNS:
dc1.ad.mydom.com
.	A	4.2.2.3
_ldap._
tcp.ad.mydom.com
.	SRV	0 0 389 
dc1.ad.mydom.com
.
_kerberos._
tcp.ad.mydom.com
.	SRV	0 0 88 
dc1.ad.mydom.com
.
_ldap._tcp.dc._
msdcs.ad.mydom.com
.	SRV	0 0 389
dc1.ad.mydom.com
.
_kerberos._tcp.dc._
msdcs.ad.mydom.com
.	SRV	0 0 88
dc1.ad.mydom.com
.
Other domain controllers in the same domain will register similar
records in DNS. 
Microsoft recommends that DNS servers supporting Active Directory also
support dynamic updates, as described in RFC 2136. Support for dynamic
updates is not strictly required for Active Directory to function.
Active Directory related records may be manually added to the zone
data supporting an Active Directory domain; however, this could be
time consuming due to the number of records registered by each domain
controller. When a domain controller is promoted, a file named
NETLOGON.DNS is created in the  %systemroot%\system32\config folder.
This file contains all of the DNS entries the domain controller would
register. This file can be used to aid in statically entering Active
Directory DNS records.
BIND Versions That Support Active Directory Requirements
 
Version 8.2.2 patch 7 or later fully supports SRV records (RFC 2782),
and Dynamic DNS (RFC 2136).
The versions here simply provide a minimum version that meets the
requirements for supporting Active Directory. This recommendation does
not take into account any patches or updates that should be applied to
any version of BIND due to performance or security-related problems.
For information on BIND versions, patches, and issues related to
running BIND, see 
http://www.isc.org/
Function of Active Directory DNS Data
 
The variety of records registered by domain controllers advertise the
different services offered by the domain controller, including:
·Authentication services (Kerberos Key Distribution Centers (KDCs)).
·LDAP and Global Catalog services, which allow clients to query domain
controllers for information about objects in the Active Directory.
·Active Directory site information, which allows clients to find local
domain controllers to which they can submit queries or requests for
authentication. 
For example, the purpose for each of the example records is stated
below:
dc1.ad.mydom.com
.	A	4.2.2.3
Host record for the domain controller.
_ldap._
tcp.ad.mydom.com
.	SRV	0 0 389 
dc1.ad.mydom.com
.
Allows a client to find an LDAP server in the 
ad.mydom.com
 domain to
submit queries to in order to find objects in the Active Directory.
All Windows NT domain controllers in the 
ad.mydom.com
 domain will
register this name.
_kerberos._
tcp.ad.mydom.com
.	SRV	0 0 88 
dc1.ad.mydom.com
.
Allows a client to locate a Kerberos KDC for the domain. All DCs
domain controllers providing the Kerberos service (used for
authentication and resource access) will register this name. All
domain controllers running the Kerberos KDC service in the
ad.mydom.com
 domain will register this name.
_ldap._tcp.dc._
msdcs.ad.mydom.com
.	SRV	0 0 389
dc1.ad.mydom.com
.
Allows a client to find a domain controller in the 
ad.mydom.com
domain. All Windows NT Ddomain controllers in 
ad.mydom.com
 will
register this name.
_kerberos._tcp.dc._
msdcs.ad.mydom.com
.	SRV	0 0 88
dc1.ad.mydom.com
.
Allows a client to find a domain controller running a Kerberos KDC for
the domain named 
ad.mydom.com
. All Windows NT domain controllers
running the Kerberos  service in the 
ad.mydom.com
 domain will register
this name.
gc._
msdcs.ad.mydom.com
	SRV 	0 0 3268 
dc1.ad.mydom.com
.
Allows a client to find any global catalog server in the Active
Directory forest via a normal A record lookup. Global catalogs in the
forest will register this record. 
Domain controllers register a number of other records in DNS. For a
complete list of the records registered by Active Directory domain
controllers, and the purpose they serve, see the Windows 2000 DNS
white paper at
http://www.microsoft.com/WINDOWS2000/techinfo/howitworks/communications/nameadrmgmt/w2kdns.asp
Configuring BIND to Support Active Directory
 
Assumptions
 
This section assumes familiarity with UNIX and Linux operating
systems, file system navigation techniques, basic daemon
configuration, daemon restart procedures, and the use of text editors.
Active Directory Interoperability Issues with BIND 8
 
As shown earlier, Active Directory records contain underscores. There
is a prohibition on the use of underscore in hostnames (RFC 952, and
1123) and mail domains (RFC 821), but the use of underscores is not
prohibited in domain names. Because underscores are allowed in domain
names—and due to the number and complexity of the records required by
Active Directory—Microsoft opted to use underscores in the domain name
portion of the records to reduce the possibility of Active Directory
data conflicting with existing DNS data.
By default, BIND 8 does not consider any record containing an
underscore to be valid. BIND 8.x uses the check-names directive to
restrict the character set of domain names in master files and/or DNS
responses received from the network. Therefore, you must disable the
check-names option to allow BIND 8.x to support Active Directory.
BIND 9
 
BIND 9x does not restrict the character set of domain names and does
not implement the check-names option.
Determining BIND Version
 
You can use the NSLookup utility to determine the version of BIND that
is running on a BIND DNS Server. To do so, use the following command:
nslookup –q=txt –class=CHAOS version.bind.0
Configuring BIND to Support Active Directory
 
To configure BIND to support Active Directory, you must configure the
named.conf (configuration) file with information specific to the
Active Directory you are supporting, create a zone file for the domain
you are supporting, and then restart the NameD daemon.
Configuring NAMED.CONF
 
The named.conf file, normally located in the /etc directory, contains
the configuration parameters for the BIND daemon and contains
configuration information about all DNS zones that will be supported
and serviced by BIND. 
This white paper covers several BIND directives that are relevant to
supporting Active Directory.  They are: 
·Options specifies global server options and sets defaults for other
statements. 
·Directory specifies the working directory of the server. Any
non-absolute pathnames in the configuration file (e.g. the names of
zone database files) will be taken as relative to this directory. The
default location for most server output files (e.g. named.run) is this
directory. If a directory is not specified, the working directory
defaults to “.”, the directory from which the server was started. The
directory specified should be an absolute path.
·Zone specifies the name of the zone, and IN specifies Internet types
of addresses.
·Type setting specifies this as a primary or secondary DNS server for
the zone.
·File specifies the name of the zone file (where the zone data will be
stored) in the folder specified by the directory directive.
·Allow-update specifies which host(s) are allowed to dynamically
register records for this zone. Options for this directive include
listing hosts by IP address or hostname, or listing entire subnets.
Entries should be separated by a semicolon (;).  All domain
controllers should be allowed to update the zone so that Host and SRV
records required to support Active Directory will be registered. You
may wish to allow other clients and servers to register automatically.
If not specified, allow-update defaults to deny. This directive can be
placed in the Options section and made the default for all zones, or
may be defined on a zone-by-zone basis.
·Check-names turns off the check name feature in BIND 8 and allows the
BIND DNS Server to accept domain names with underscores (_) used by
Active Directory.  This directive has three settings: warn, fail, and
ignore. If the check-names directive is not specified, the default is
set to warn. If check names is set to either warn or fail, updates and
queries containing underscores will be rejected. This directive must
be set to ignore in BIND 8 to support Active Directory.
There are many other directives that can be used to configure BIND
which are beyond the scope of this white paper. For complete
documentation on the BIND product, see
http://www.isc.org/products/BIND/
BIND 8 Abstract Zone Entry
 
The following is an abstract example of the zone entry in the
named.conf file 
Options {
   directory “<working directory name>”;    
};
Zone “<DNS Name for the Active Directory Domain>” IN {
       type master;
       file “<file for this zone>”;
       allow-update { <address_match_list>; };
       check-names ignore;
};
BIND 8 Example Zone Entry
 
The following is a zone entry, that would support an Active Directory
domain with the name of “
ad.mydom.com
”. The type of zone is master
(primary), the file where the zone data is stored is named
“
db.ad.mydom.com
”, located in the “/etc/namedb” directory.  The
computer with the IP address 4.2.2.3, and the computer with the
hostname “dc2,” are allowed to submit updates to the zone. The
check-names directive is set to ignore (this allows the server to
process requests and data that contain underscores).
Note   Entries preceded with “//” are comments, and are not directives
processed by the server.
Options {
   directory “/etc/namedb”;    //Working directory
};
//Zone entry for my Active Directory domain 
ad.mydom.com
.
Zone “
ad.mydom.com
” IN {
       type master;
       file “
db.ad.mydom.com
”;
       allow-update { 4.2.2.3; dc2.; };
       check-names ignore;
};
BIND 9 Example
 
This file is identical to the BIND 8 example except that the
check-names directive has been removed. BIND 9 does not restrict the
character set of domain names and does not implement the check-names
option.
Options {
   directory “/etc/namedb”;    //Working directory
};
//Zone entry for my Active Directory domain 
ad.mydom.com
.
Zone “
ad.mydom.com
” IN {
       type master;
       file “
db.ad.mydom.com
”;
       allow-update { 4.2.2.3; dc2.; };
};
Finishing BIND Configuration
 
You must create a zone file to support the Active Directory zone in
the directory specified by the directory directive, then restart the
NameD daemon. At this point the BIND servers should be ready to
receive updates for the Active Directory™ zone. You can now configure
your domain controllers to use the BIND server as their primary DNS
server.
Configuring Domain Controllers to Use BIND DNS Servers
 
To configure a domain controller—or any Windows 2000 or later
client—to use a BIND server, all you need to do is specify the IP
address of the BIND server as the preferred DNS server in the TCP/IP
properties for the active network connection.
To do this:
1. Right-click My Network Places, and then select Properties.
2. Right-click the active network connection, and then select
Properties.
3. Select Internet Protocol (TCP/IP), and then click Properties
4. Type the IP address of the BIND server in the Preferred DNS server
box. (The graphic below assumes that the IP address of the BIND server
is 4.2.2.15).
Forcing registration of DNS records
 
Once you have configured the preferred DNS server, you can force all
DNS records to be reregistered with the new preferred DNS server two
ways:
1. Restart the NETLOGON service.   This action can be performed from
Control Panel/Administrative Tools/Services. This action will not
disconnect any currently logged-on users but no new users will be able
to connect while the service is down. Restarting the NETLOGON service
usually takes less than a minute, and will immediately update the DNS
zone database.
2. Run IPCONFIG /REGISTERNDS from a command prompt.   This will force
the computer to reregister all DNS records with the preferred DNS
server. IPCONFIG /REGISTERDNS does not register the records
immediately. It can take up to 15 minutes for registrations to show up
in the DNS zone database.
Testing and Verification
 
Using NSLookup utility, you can test that the BIND server is properly
configured, accepting updates, and answering queries for the Active
Directory domain. To test with NSLookup, use the following procedure:
1. On your DNS server, start the NSLookup utility in interactive mode.
2. Type set type=all, and then press Enter (this specifies that all
record types may be returned). 
3. Type _ldap._tcp.dc._msdcs.domainname (where domainname is the name
of your domain; do not forget to include leading underscores), and
then press Enter.
NSLookup returns one or more SRV service location records in the
following format:
    hostname.domainname internet address = ipaddress
Where hostname is the host name of a domain controller, domainname is
the domain to which the domain controller belongs, and ipaddress is
the domain controller's IP address.
Validating Data in the Zone Database File
 
You can also edit the zone database files on the BIND server to see if
the zone data has been added. All data files related to the zone will
be in the working directory specified by the directory directive. Be
aware that updates submitted through Dynamic DNS may not appear
immediately in the zone file. BIND servers store dynamic updates
temporarily in an IXFR (Incremental Zone Transfer) file. Updates are
then added to the zone database file within a few minutes. 
For example:
If the directory directive specifies a working directory of
“/etc/namedb” and the zone entry specifies a file of
“
db.ad.mydom.com
”, the zone database file can be found at
“/etc/namedb/
db.ad.mydom.com
”.  When updates are received, an IXFR
file will be created in the working directory. This file will have the
same name as the zone database file, but will have a “.ixfr”
extension. Continuing with the example, an IXFR file for the
ad.mydom.com
 com domain can be found at
“/etc/namedb/db.ad.mydom.com.ixfr”.
Summary
 
Microsoft recommends using the DNS Server provided with Windows 2000
to support Active Directory and Windows 2000 networks. The DNS Server
provided with Windows 2000 Server is an IETF standard-based DNS server
that fully supports Active Directory, and is fully interoperable with
other standards-based implementations of DNS Sserver. However, if
administrators wish to use existing BIND DNS servers to support Active
Directory, they can do so. 
Any DNS server that supports Active Directory must support SRV records
(defined in RFC 2782), and it is strongly recommended that the DNS
server also support Dynamic DNS (defined in RFC 2136). 
To properly deploy BIND to support Active Directory, you must use BIND
version 8.2.2 patch 7 or later. You must configure the named.conf file
to include a zone statement defining the DNS name of the Active
Directory domain, and specify the location of the database file for
the zone. You must set the check-names directive to ignore (BIND 8
only), and you can configure the allow-update directive to allow
domain controllers to register their DNS data through Dynamic DNS. 
Once the BIND server is configured correctly and the NameD Daemon is
restarted, Windows 2000 domain controllers, servers, and clients
should have their TCP/IP properties configured with the IP address of
the BIND DNS Server as their preferred DNS server. The Netlogon
service can be restarted on any Windows 2000 client to force an
immediate registration of DNS records with the BIND DNS Server.
---------------------------

Per quale arcano motivo ci si dovrebbe fare del male usando il BInD?
Già è complicato usare il suo dns se poi.............
p.s. comunque  grazie.
Ciao
AR