Suggested Solaris 2.7 and Solaris 2.8 Configurations for Large DNS Implementations Spanning Multiple Geographic Regions The following is a suggested configuration to get DNS BIND 8 or BIND 9 working in a very large site spanning multiple geographic regions running a centralized administration/staging server. This configuration should be tested in a non-production environment first before it is put into a production environment. How to set up a DNS Boss Staging / Multiple Primary Configuration "X" User Interface Web User Interface Administration Administration \ / \ / \ / \ / DNS Boss Staging DNS Primary \ \ DNS Client \ \ / \ \ / \ Production / \ DNS Boss Primary 1 --- DNS Client \ \ \ \ DNS Client \ / \ / \ / Production / DNS Boss Primary 2 --- DNS Client So why run multiple DNS primary servers and a separate Staging/Administration Server? Lets ask a few very important questions: QUESTION: Should the site DNS go down if somebody makes a mistake on their DNS maintenance? ANSWER: With the DNS Boss Staging Server setup, if somebody accidently tries to push bad data to all the DNS servers, it should only take down the the DNS Boss Staging Server DNS, but not the Production DNS Boss Primary DNS Servers. DNS Boss does a huge amount of checking and simplification to verify the correct creation of all DNS data. If however, something slips through that causes a fatal error in the restart of BIND, then the DNS Boss Staging Server will not push the DNS data to the Production DNS Boss Servers. DNS Boss looks at the return status code for the restart of your version of BIND and will only push data to the Production DNS Servers if it sees a successful restart of BIND. The DNS Boss staging server also automatically pings the Production DNS Servers before it attempts to replicate to verify that they are up to prevent pushes from hanging. QUESTION: Should the different DNS servers for the same DNS domain be out of sync? ANSWER: The DNS Boss Staging Server synchronizes the data on all Production DNS servers by pushing the exact data from the Staging Server to the Production Servers. QUESTION: What if there is a power blackout at the site where the main DNS Primary is located? Shouldn't the Production DNS servers located at other geographic locations still be able to do updates and modifications? ANSWER: With the DNS Boss Staging Server setup, if there were an extended power blackout where the main DNS primary was located, a remote DNS Boss Production DNS Primary located on the other side of the world could still do updates, or even take over as the DNS Boss Staging DNS Server. There are at least 2 different ways to implement the Staging DNS Server setup. A) For Internal DNS located behind a secure firewall On the Staging DNS Boss Primary, edit the backup_primaries_list file. Example: stagingdns# vi /opt/DNSBoss/etc/backup_primaries_list 203.13.127.16 On the Production DNS Primary Server ns1# vi /etc/default/login #CONSOLE=/dev/console ns1# vi /etc/hosts 205.73.190.67 stagingdns ns1# vi /.rhosts Then on the Staging DNS Server, bring up DNS Boss and do an load a DNS domain, and do an: 'Update this domain' and you should notice a slight delay as the primary pushes the data to the Production DNS Primary. Go to the Production DNS Primary and see if the DNS data is there. It should be the exact same data as the Staging DNS Server. B) For a secure version of the above mentioned setup for replicating DNS Boss Primary Servers across firewalls, email: support@dnsboss.com for the DNS Boss Secure Replication Kit. Please include contact information including: name, phone, company address, and how you intend to use DNS Boss at your company. Installation Instructions/Example for the DNS Boss Secure Primary Replication Mechanism On the DNS Boss Master Primary Server: ______________________________________ stagingdns# cd /opt/DNSBoss/lib/security/bin stagingdns# ./install_dnsboss_secure_master For the DNS Boss Slave Primary Server: ______________________________________ ns1# cd /opt/DNSBoss/lib/security/bin ns1# ./install_dnsboss_secure_slave ns1# cd /.ssh ns1# ftp stagingdns ftp> cd /.ssh ftp> get authorized_keys ftp> quit ns1# /opt/DNSBoss/bin/S99DNSBoss_SECURE If you want this to startup at boot time. ns1# cp /opt/DNSBoss/bin/S99DNSBoss_SECURE /etc/rc2.d On the DNS Boss Master Primary Server: ______________________________________ This only needs to be done once. stagingdns# /opt/DNSBoss/lib/security/src/ssh/bin/ssh stagingdns Add the IP of ns1 to /opt/DNSBoss/etc/backup_primaries_list stagingdns# vi /opt/DNSBoss/etc/backup_primaries_list 203.13.127.16 Now you should be able to do secure replication of the DNS Boss data from the DNS Boss Master Primary to a DNS Boss Slave Primary. stagingdns# /opt/DNSBoss/bin/dnsboss 'Load DNS Domain' and 'Update'. After the Update completes, you should see the same data on ns1. Simulated disaster and recovery. Here is a suggested test to simulate a disaster that should be performed so you know what to do when a real disaster hits. Shutdown your master DNS Boss primary, and one of your Production DNS Boss Primary DNS servers. Example stagingdns# init 0 ns1# init 0 and turn them both off. This will simulate a catastrophic disaster in 1 or more geographic regions. Go to your your surviving Production DNS Primary, and add or delete some hosts, and: 'Update this domain'. This should work, and the fact that 2 out of your 3 DNS primarys are down should not be significantly noticed by the DNS clients. The real advantage of doing this is that you can carry on your business by adding or deleting new DNS hosts, even while the other DNS primarys servers are being maintained. This would not be true if you were running a Primary to Secondary configuration. You would not be able to make updates.
