Personal tools
You are here: Home → Fedora Solved → Network Solutions → BIND Special Cases HOWTO, Part 1
 

BIND Special Cases HOWTO, Part 1

by kanarip — last modified Jan 30, 2008 03:46 AM
— filed under:

This is a quick HOWTO for Network Administrators that need to implement Microsoft Windows Active Directory in a BIND authoritative namespace and enabling Dynamic DNS.

HOWTO Using BIND and DHCPD in a Windows Active Directory environment with Secure DDNS enabled

Intended Audience

This HOWTO, however quick and nearly non-informative, is intended for users and administrators that do not want to work out the details of implementing DDNS in a Windows Active Directory, using BIND as the authoritative name-server for the namespace.

In this article, we assume you already know what a namespace is, how DNS works, how DHCP works, how DDNS is related to Active Directory and DHCP, and how it's related to something like Active Directory, and why it could be better to use BIND DNS servers as the authoritative name-server(s) for your namespace. We will also not elaborate on certain actions, or certain consequences of these actions. In other words, we will not elaborate on the need to implement this kind of environmental topology, rather then just handing anyone who likes it, a quick HOWTO.

Build it from scratch

In this part of the article, we'll give you a quick walk through for when you are building a new environment. When migrating from an existing environment, other considerations apply, and thus a migration path will need to be designed before implementation. This we cannot do in a quick HOWTO, however we can hand you some if not all of the conditions that apply to designing and implementing such a migration. For this HOWTO, we'll set up some requirements, make a little design, just to elaborate on what we're doing here.

The requirements

In the environment for this HOWTO, we want our authoritative name-servers for the 'howto.com' namespace to be BIND DNS servers, while enabling Microsoft Windows Active Directory in the same environment. On top of that, we want DHCP clients (usually workstations and not servers), to be able to register their hostnames in DNS, implying Dynamic DNS. All DNS clients (including servers) should use the BIND DNS servers as DNS servers in their configuration.

The design

First, choose a namespace that your Active Directory will use, and that you will make BIND authoritative for. If you already have one, skip to the migration section of this article. In this HOWTO, we will use howto.com.

We will set up an Active Directory in an environment that uses BIND DNS servers, using the 10.10.10.0/24 IP Subnet for all of our servers.

  • 10.10.10.1 is the default gateway for all machines in the subnet
  • 10.10.10.2 is the primary BIND DNS server for all machines in the subnet
  • 10.10.10.3 is the secondary BIND DNS server
  • 10.10.10.4 is the "primary" Domain Controller for Active Directory, also called Operations Master, named win-2k3srv01
  • 10.10.10.5 is the "secondary" Domain Controller, named win-2k3srv02

Notice we use "primary" and "secondary" terms for the BIND DNS servers as well as for the Domain Controllers, but in fact Windows 2003 Active Directory has no such roles for Domain Controllers. We use "primary" to refer to the Operations Master for the Active Directory Configuration and Application Partitions nonetheless.

Build the Active Directory

When setting up your Active Directory, ensure that localhost, or 127.0.0.1 is set up as your primary and only DNS server. When you promote the first Domain Controller, choose to install and configure DNS.

This will enable your Domain Controller to serve DNS for two zones:

  • _msdcs.howto.com
  • howto.com

Because we need to delegate the Active Directory relevant sub-domains of howto.com, we need to extract the sub-domains from the current howto.com zone. Create primary, Active Directory Integrated zones for the following namespaces:

  • _tcp.howto.com
  • _sites.howto.com
  • _udp.howto.com
  • DomainDnsZones.howto.com
  • ForestDnsZones.howto.com

If applicable, set your secondary Windows (future) Domain Controller to use the DNS service of win-2k3srv01 (10.10.10.4), and promote your secondary Domain Controller (win-2k3srv02). When this is all set up, configure your BIND name-server(s).

Now, configure your primary BIND DNS server to serve the zone "howto.com":

zone "howto.com" {
	type master;
	file "data/howto.com.zone";
	check-names ignore;
	notify TRUE;
	allow-update {
		key "DHCP_UPDATER";
	};
};

zone "10.10.10.in-addr.arpa" {
	type master;
	file "data/10.10.10.in-addr.arpa.zone";
	check-names ignore;
	notify TRUE;
	allow-update {
		key "DHCP_UPDATER";
	};
};

key "DHCP_UPDATER" {
	algorithm hmac-md5;
	secret "ssTRfR3DK4uFmMIL1KIhYQ==";
};

As you can see, this zone is configured to be authoritative (type master). We'll elaborate on the keys further on in this document. Create the howto.com zone file and provide at least the following information:

$TTL 84600
howto.com.			IN SOA ns1.howto.com. root.howto.com. (
				20070219	; serial
				3H		; refresh interval
				15M		; retry interval
				1W		; zone expires in ...
				1D		; minimum TTL
		)
				NS	ns1.howto.com.
				NS	ns2.howto.com.
$ORIGIN howto.com.
				A	10.10.10.1

ns1				A	10.10.10.2
ns2				A	10.10.10.3
win-2k3srv01			A	10.10.10.4
win-2k3srv02			A	10.10.10.5

_msdcs			NS	win-2k3srv01
				NS	win-2k3srv02
				A	10.10.10.4
				A	10.10.10.5
_sites				NS	win-2k3srv01
				NS	win-2k3srv02
				A	10.10.10.4
				A	10.10.10.5
_tcp				NS	win-2k3srv01
				NS	win-2k3srv02
				A	10.10.10.4
				A	10.10.10.5
_udp				NS	win-2k3srv01
				NS	win-2k3srv02
				A	10.10.10.4
				A	10.10.10.5
DomainDnsZones		NS	win-2k3srv01
				NS	win-2k3srv02
				A	10.10.10.4
				A	10.10.10.5
ForestDnsZones		NS	win-2k3srv01
				NS	win-2k3srv02
				A	10.10.10.4
				A	10.10.10.5

Use 'named-checkconf' to see if your DNS Server configuration works, and 'named-checkzone howto.com /var/named/data/howto.com.zone' to see if your zone has complete and viable information. Then reload the DNS service.

Configure the 10.10.10.in-addr.arpa zone file in the same manner, provided you add the following information:

$TTL 84600
10.10.10.in-addr.arpa.		IN SOA ns1.howto.com. root.howto.com. (
				20070219	; serial
				3H		; refresh interval
				15M		; retry interval
				1W		; zone expires in ...
				1D		; minimum TTL
		)
				NS	ns1.howto.com.
				NS	ns2.howto.com.
$ORIGIN 10.10.10.in-addr.arpa.
1				PTR	gw.howto.com.
2				PTR	ns1.howto.com.
3				PTR	ns2.howto.com.
4				PTR	win-2k3srv01.howto.com.
5				PTR	win-2k3srv02.howto.com.

Now configure your secondary BIND DNS server to be a slave for the howto.com zone, as well as the 10.10.10.in-addr.arpa zone:

zone "howto.com" {
	type slave;
	file "slaves/howto.com.zone";
	masters { 10.10.10.2; };
	notify FALSE;
	check-names ignore;
};

zone "10.10.10.in-addr.arpa" }
	type slave;
	file "slaves/10.10.10.in-addr.arpa.zone";
	masters { 10.10.10.2; };
	notify FALSE;
	check-names ignore;
};

Again use 'named-checkconf' to see if your configuration will work and reload the DNS service.

From /var/log/messages, you should see messages stating a successful transfer of zone "howto.com" as well as "10.10.10.in-addr.arpa"

To test the DNS environment you've set up so far, use the following:

# Verify the zone is loaded by the primary name-server, that the name-server is
# responsive and that it has the correct name-server records
dig @10.10.10.2 ns howto.com

# Verify that the secondary name-server has successfully transferred the zone, that the
# nameserver is responsive. The information should match your earlier dig.
dig @10.10.10.3 ns howto.com

# A query to verify the Active Directory is being delegated and responsive as it
# should be, via the secondary name-server (so we also verify the zone transfer)
dig @10.10.10.3 srv _ldap._tcp.dc._msdcs.howto.com

Configure win-2k3srv02 to host the DNS service as well, and ensure all Active Directory Integrated DNS Zones are replicated from win-2k3srv01 to win-2k3srv02.

Now, configure the Windows 2003 Active Directory Domain Controllers to use 10.10.10.2 and 10.10.10.3 as DNS servers, and delete the Active Directory Integrated DNS zone of 'howto.com' from these Domain Controllers.

Now you have several options:

  • Create a zone-specific forwarder for 'howto.com' on the Windows DNS servers to point to the BIND DNS servers.
  • Create a stub zone for 'howto.com' com' on the Windows DNS servers obtaining the necessary information from the BIND DNS servers.
  • Configure the BIND name-servers to be forwarders for the Windows 2003 DNS Services.
  • Create a secondary zone for 'howto.com' and use the BIND DNS servers to replicate from.

From the BIND DNS service perspective, you can:

  • Create a zone-specific forwarder for any zone hosted by the Windows DNS servers.
  • Create a stub zone for any zone hosted by the Windows DNS servers.
  • Create a secondary zone for any zone hosted by the Windows DNS servers and replicate from any of the Windows DNS servers.

In this HOWTO, we'll only elaborate on configuring the BIND DNS servers using the options as listed above:

Create zone-specific forwarders

However the use of zone-specific forwarders typically is unnecessary, you could create zone-specific forwarders to redirect any queries for Active Directory Integrated sub-domains of howto.com. Basically, your server already knows where to direct the queries to, as it hosts the parent zone of these sub-domains, and this only applies when you disable recursion.

Basically, in the opinion of the authors of this document: not recommended.

In the BIND configuration, configure a zone for each of the Active Directory Integrated DNS zones:

zone "_msdcs.howto.com" {
	type forward;
	forward only;
	forwarders { 10.10.10.4; 10.10.10.5; };
	check-names ignore;
};

Repeat such configuration block for each of the Active Directory Integrated DNS zones.

Create stub-zones

You should probably not need to use stub zones as the same BIND DNS server is authoritative for the parent zone, delegating the sub-domain to other name-servers already. Using stub zones is considered to be 'redundant' in a way that it can only interfere with normal operation. However, you would need stub zones if the namespace you want to be able to list the name-servers from, exists outside any zone already existent within the BIND DNS server.

Again: This is also not recommended. Nonetheless, a configuration example:

zone "_msdcs.howto.com" {
	type stub;
	file "slaves/_msdcs.howto.com.zone";
	masters { 10.10.10.4; 10.10.10.5; };
};

Create secondary zones

Having secondary zones is also considered to be redundant, but does not interfere with normal operations. This can be useful when you decide not to allow recursion, and not to allow queries to be made from your clients, directly to the authoritative name-servers. Usually, you won't need to create secondary zones.

Advise: use only if needed. To have your BIND DNS servers replicate the zones in a both secure and proper way, you need to add them as name-servers at the SOA name-server, configure the zone to be allowed to be transferred to every server that is listed as a name-server for that zone, and last but not least, when really up-to-date information on all name-servers is required/desirable, enable sending notifies throughout the infrastructure.

zone "_msdcs.howto.com" {
	type slave;
	file "slaves/_msdcs.howto.com.zone";
	masters { 10.10.10.4; 10.10.10.5; };
	notify FALSE;
	check-names ignore;
};

Continue to DHCP Server Configuration.

Migrate an existing environment to use BIND and DHCPD

We do not yet have enough information to write this section of the document.

DHCP Server Configuration

Now we need to configure your DHCP server to update DNS when a client obtains a lease. Configure your DHCP server with the global ddns-update-style configuration directive set to interim to enable your DHCP server to update DNS accordingly.

Below is a configuration example from which we believe you will be able to set up your own version to match your requirements and design, and to copy and paste from if you're using more then just one subnet.

ddns-update-style interim;

authoritative;

subnet 10.10.10.0 netmask 255.255.255.0 {
	option routers				10.10.10.1;
	option subnet-mask			255.255.255.0;
	option domain-name			"howto.com";
	option domain-name-servers		10.10.10.2, 10.10.10.3;

	range dynamic-bootp			10.10.10.10 10.10.10.254;
	default-lease-time			21600;
	max-lease-time			43200;
}

zone howto.com. {
	primary 10.10.10.2;
	key DHCP_UPDATER;
}

zone 10.10.10.in-addr.arpa. {
	primary 10.10.10.2;
	key DHCP_UPDATER;
}

key DHCP_UPDATER {
	algorithm hmac-md5;
	secret ssTRfR3DK4uFmMIL1KIhYQ==;
}

Please note that the domain-name configuration directive should be set to hold the same namespace you want to update, as well as the one you configure as a 'zone'. Also note that the key being used should be configured with the BIND DNS server to be allowed to request updates to the zones "howto.com" as well as "10.10.10.in-addr.arpa".

In addition, to any extra subnets you may configure, create the appropriate reverse DNS zone and supply the necessary zone configuration block in your DHCP server configuration.

Generating the keys

To generate the keys to use with secure updates, give the following command:

# dnssec-keygen -a HMAC-MD5 -b 128 -n HOST ns1.howto.com.

and get the key using:

# cat Kns1.howto.com.*.private

Use this key in the configurations listed above, for both the BIND DNS server configuration and the DHCPD configuration, in the key definition sections that are in bold.

Updating the zone afterwards

This is not all of it. When you got this up and running, whether you have build it from scratch, or migrated from an existing environment, you will still need to update the zone from time to time. Since we only allow hosts that have the appropriate key information to update the zones, your Domain Controllers will not be allowed to update their IN A and IN PTR resource records. This calls for the need of static records to each and every one of your servers, so how to add a RR when the zone is dynamic? Since the dynamic records are being written to a journaling file, which is re-applied every time you reload the zone information, you cannot just edit the zone file and then reload the zone.

The answer is to use the rndc utility. Before updating the zone file freeze dynamic updates, using:

# rndc freeze howto.com
# rndc freeze 10.10.10.in-addr.arpa

After editing the zone files, use:

# rndc unfreeze howto.com
# rndc unfreeze 10.10.10.in-addr.arpa

to allow dynamic DNS updates once again. The rndc freeze command will disallow dynamic updates until you unfreeze the zone, and will apply the journaling file to the plain-text zone file so you are updating the most recent version.

More information

Disclaimer

We test this stuff on our own machines, really we do. But you may run into problems, if you do, come to #fedora on irc.freenode.net

Although the author may have the necessary amount of relevant experience, you may have additional information that could help improve or extend this article. If you do, please leave a comment or submit your feedback using our feedback page.

Additional reading

For most of BIND and it's name-server application 'named', you can read the BIND 9 Administrator Reference Manual, of which the most recent version is to be found at www.isc.org

DNS Security, extending the DNS protocol: http://www.dnssec.net/

Copyright and Trademarks

Microsoft, Windows and Active Directory are trademarks of Microsoft Corporation.


Document Actions
Log in


Forgot your password?
New user?