OpenLDAP Everywhere Reloaded, Part I

On linux01.example.com, modify /etc/bind/named.conf.local to include the following:


//// excerpt of named.conf.local on linux01

// --- Above output suppressed

zone "168.192.in-addr.arpa" {
   type master;
   file "/etc/bind/db.168.192.in-addr.arpa";
   notify yes;
   allow-transfer { 192.168.2.10; }; // linux02
};

zone "example.com" {
   type master;
   file "/etc/bind/db.example.com";
   notify yes;
   allow-transfer { 192.168.2.10; }; // linux02
};

// --- Below output suppressed

On linux01.example.com, create the zone files /etc/bind/db.168.192.in-addr.arpa and /etc/bind/db.example.com, and populate them with appropriate zone information. For very basic examples of the zone files, see the example configuration files available on the LJ FTP site (see Resources for the link).

Before committing changes to a production DNS server, always check that no mistakes are present. Failure to do this causes the named(8) dæmon to abort when restarted. You don't want to cause a major outage for production users if there is a trivial error. On linux01.example.com:


# named-checkconf /etc/bind/named.conf
# named-checkconf /etc/bind/named.conf.local
# named-checkzone 168.192.in-addr.arpa /etc/bind/db.
168.192.in-addr.arpa
zone 168.192.in-addr.arpa/IN: loaded serial 20111003
01
OK
# named-checkzone example.com /etc/bind/db.example.c
om
zone example.com/IN: loaded serial 2011100301
OK
# 

On linux01.example.com, instruct the named(8) dæmon to reload its configuration files, then check that it didn't abort:


root@linux01:~# /etc/init.d/bind9 reload
Reloading domain name service...: bind9.
root@linux01:~# ps -ef|grep named|grep -v grep
bind      1283     1  0 16:05 ?        00:00:00 /usr
/sbin/named -u bind
root@linux01:~# 

It is possible during normal operations that the named(8) dæmon on linux01.example.com could abort and the rest of the server would otherwise continue to function as normal (that is, single service failure, not entire server failure). As linux02.example.com will have a backup copy of the zones anyway, linux01.example.com should use linux02.example.com as its secondary DNS server.

On linux01.example.com, create and/or modify /etc/resolv.conf. Populate it with the following:


search example.com
nameserver 127.0.0.1
nameserver 192.168.2.10

On linux01.example.com, check, and if necessary, modify /etc/nsswitch.conf to include the following "hosts" definition. This line already was in place for me, but it strictly does need to be present for you if it isn't:


## /etc/nsswitch.conf on linux01 & linux02

# --- Above output suppressed

hosts:          files dns

# --- Below output suppressed

Finally, test that linux01.example.com can resolve records from the DNS server:


root@linux01:~# dig linux02.example.com +short
192.168.2.10
root@linux01:~# dig -x 192.168.2.10 +short
linux02.example.com.
root@linux01:~# nslookup linux02.example.com
Server:         127.0.0.1
Address:        127.0.0.1#53

Name:   linux02.example.com
Address: 192.168.2.10

root@linux01:~# nslookup 192.168.2.10
Server:         127.0.0.1
Address:        127.0.0.1#53

10.2.168.192.in-addr.arpa       name = linux01.example.com.

root@linux01:~# 

Now, configure linux02.example.com as the slave server. First, modify /etc/bind/named.conf.local to include the following:


//// excerpt of named.conf.local on linux02

// --- Above output suppressed

zone "168.192.in-addr.arpa" {
   type slave;
   file "/var/lib/bind/db.168.192.in-addr.arpa";
   masters { 192.168.1.10; }; // the linux01 server
};

zone "example.com" {
   type slave;
   file "/var/lib/bind/db.example.com";
   masters { 192.168.1.10; }; // the linux01 server
};

// --- Below output suppressed

Take careful note of the placement of the slave zone files in /var/lib/bind, not in /etc/bind!

This change is for two reasons. First, /etc/bind is locked down with restrictive permissions so named(8) is not able to write any files there. named(8) on linux02.example.com cannot and should not write a transferred zone file there.

Second, the /var partition is intentionally designated for files that will grow over time. /var/lib/bind is the Debian chosen directory for named(8) to store such files.

Please resist the urge to change permissions to "fix" /etc/bind! I cannot stress this enough. It not only compromises the security on your RNDC key file, but also the dpkg package manager is likely to revert any change you made on /etc/bind the next time the bind9 package is upgraded.

If you require a single location for both servers to store their zone files, it would be better to move the local zone files on linux01.example.com to /var/lib/bind, rather than force a change to /etc/bind on linux02.example.com. Don't forget to update the paths for the zone files in linux01.example.com's /etc/bind/named.conf.local accordingly.

On linux02.example.com, run named-checkconf(1) to check the new configuration, as you did before for linux01.example.com. If the new configuration checks out, tell named(8) to reload by running the /etc/init.d/bind9 reload command. Also check that the dæmon didn't abort by running ps -ef|grep named|grep -v grep as was done before.

If the zone transfer from linux01.example.com was successful, you should have something like the following appear in /var/log/syslog on linux02.example.com:


# --- above output suppressed ---

Oct 3 20:37:11 linux02 named[1253]: transfer of '168
.192.in-addr.arpa/IN' from 192.168.1.10#53: connected
 using 192.168.2.10#35988
  --- output suppressed ---
Oct 3 20:37:11 linux02 named[1253]: transfer of '168
.192.in-addr.arpa/IN' from 192.168.1.10#53: Transfer 
completed: 1 messages, 12 records, 373 bytes, 0.001 
secs (373000 bytes/sec)
  --- output suppressed ---
Oct 3 20:37:12 linux02 named[1253]: transfer of 'exa
mple.com/IN' from 192.168.1.10#53: connected using 1
92.168.2.10#41155
  --- output suppressed ---
Oct 3 20:37:12 linux02 named[1253]: transfer of 'exa
mple.com/IN' from 192.168.1.10#53: Transfer complete
d: 1 messages, 12 records, 336 bytes, 0.001 secs (33
6000 bytes/sec)

# --- below output suppressed ---

On linux02.example.com, create and/or modify /etc/resolv.conf. Populate it with the following:


search example.com
nameserver 127.0.0.1
nameserver 192.168.1.10

This is the only device on the network that will ever have linux02.example.com as its primary DNS server. It's done for performance reasons, on the assumption that linux01.example.com will fail first. Of course, you never can predict which server will fail first. However, if linux02.example.com happens to fail first, the workstations, in theory, won't notice it—DHCP tells them to query linux01.example.com before linux02.example.com.

Now, on linux02.example.com, check, and if necessary, modify /etc/nsswitch.conf to include the hosts: files dns in the same way performed previously. Check that dig(1) and nslookup(1) can resolve linux01.example.com in a similar manner as done before.

______________________

Stewart Walters is a Solutions Architect with more than 15 years' experience in the Information Technology industry. Amongst other industry certifications, he is a Senior Level Linux Professional (LPIC-3).

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Reply to comment | Linux Journal

visit the site's picture

Undeniably imagine that that you said. Your favourite justification appeared to
be at the net the simplest factor to have in mind of.
I say to you, I certainly get annoyed even as people consider issues that they plainly
do not recognise about. You controlled to hit the nail upon the highest
as well as outlined out the entire thing with no need side
effect , other folks can take a signal. Will likely
be again to get more. Thank you

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState